Staying Sharp in Software Development

This is my fifth year writing software. As I continue my development in the trade, I find myself spending more and more time interacting with people who’s level of contribution now exceeds that of an “individual contributor”. They are much too talented to be writing any more code, so their superiors would like to say. Their time would be much better spent discussing the problems that some given software is trying to solve, and ideally, never write any to begin with. In those cases where software is needed, they spend their efforts scaffolding out initial solutions, architecting the patterns for others to fill in with details. I would argue that these all play a part in a successful version of the software development life cycle.

I have no issue going on the record by publicly stating that I have no interest in being a member of this group. In fact, I’ll go as far as saying that the only way to stay truly sharp in the ever-evolving world of software development is to periodically reset your career to that of a junior hire every couple of years. Any analogy that you might construct to convince me otherwise is likely to apply poorly to writing software. We are not generals in a war, where “boots on the ground” can’t be wasted on the likes of our best and brightest. Oftentimes, there isn’t a clean way to truly solve (or even understand) a problem without becoming the entry-level developer who invariably gets tasked with that whole “details” part of the process. I find it odd that we leave our best and brightest to identify the obvious parts of the problem, while leaving the costliest, most error prone mistakes to be made by those who are in the prime of their mistake-making part of their careers.

For an example, take the common case: business software. At the highest, highest levels, there is a need for some payroll system to be put in place for a new company. For someone at a director level, there is a tax issue preventing them with going through a typical payroll servicing company. For an architect, there are tax disadvantages by using pre-fabricated payroll software, so it’ll need to be coded in house. At this point, much of the hard work is done, in a sense. The only thing left is to actually make that list of exceedingly more detailed requirements into the most detailed requirements — computer software. Compare this with something like research, where those at the highest levels decide there is a practical business need to build self-driving cars. A director discovers that the technologies behind this don’t exist yet, or at best, are new, unvetted, and rough. Where do you begin with those requirements? No amount of architecting can suddenly make computer vision easier. Those are hard details, and they must be orchestrated in a way that makes sense when conforming to something as massive and complex as the motor roadway laws of California.

A great developer will be able to see the forest through the trees, while running through it with a group of four people. Obviously, you can’t do it forever, but again, many analogies fail here. It’s a lot like hunting, except the barrier to exit is much, much lower. You can be a great hunter, and know where the biggest game tend to gather, but your insights will only take those doing the actual hunting so far. When you’re no longer the one stringing the bow, it’s easy to forget that the hardest part of hunting is “don’t miss”. If you find yourself suddenly supporting a village too large to do the hunting yourself anymore, it may be time to start designing better bows and arrows for them to use.

What do you have to lose in a skill like software development? Your ability to type? Your eyesight? Those things last for seventy years or more in a healthy citizen living in a first-world country. The only major loss you face as a real threat is your ability to stay active in a world that is dominated by the new technologies, authors, tools and workflows that can too easily slip from your grasp as you become too senior of a developer.