Earth-shattering project ideas. Resumes. Things in between.
This page is meant to address human and organizational topics, not build technical accumen. There are more questions than answers; more anecdotes than data; more allegories than instructions.
Extremely short version: I’ve been programming in one form or another since 1979, although I didn’t get an actual job in the field until some time in the 90s. I’ve tracked the progress of software engineering as a discipline in various ways, but to supplement my own exposure I also talk this stuff over with friends and relatives in the industry.
More about me in another document. Or you could look in my resume.
Some say specialization is for insects. I say that’s way oversimplified. (Heinlein’s list of competencies consists mostly of specialties!) In the course of a full life, one might hope to learn many skills to a not-catastrophically-bad level, but the reality is that long-term focus creates and sharpens your very particular set of skills. Skills for which you can become very well paid, as Liam Neeson was when he popularized the phrase.
And anyway, insects aren’t such a bad example for some things. They were here before us, and they’ll be here after we’re gone.
The chief difference between developers and bees is that bees get their behavioral choices from a combination of genetics and pheromones, whereas developers are driven by culture, opportunity, and training. You might wonder where interest went missing on that list. I say it’s not. Interest is an emergent property, more a consequence of the other three.
Both bees and developers go through phases of different types of contributions and growth. There is variation among individuals, and not everyone finishes all phases of the adventure, but the broad arc from novice to expert to – either guru or manager – is going to have a lot of thematic similarities.
In respect of direct job responsibilities, we can at least consider these questions:
By far, the most mature and effective professional-development pipeline I’ve ever seen was in the US Navy. And for good reason! Thanks to countless generations of human warfare, the modern militaries of the world have figured a few things out. Among these are:
Since training is such a staggeringly-important part of military life, our military has figured out how to do it extremely well across a vast array of subjects. It’s impossible to collapse that down to a few glib bullet points, but a few key ideas might be:
Our industry has a strange history of fettishizing the individual. For example, several decades back (say, from around 1975 to around 1995 or 2005) it was trendy to to compare the productivity of average to excellent developers, as if this was some sort of inbred characteristic you had to select for. Depending on where you look, you can find 10x, 28x, or larger multipliers. You can find tales of negative developer productivity at the low end: people who’s contributions were allegedly worse than useless. Fred Brooks advocates finding and nurturing great developers in his book. Variously Apple, Microsoft, and specific notable people (but for some reason never the Hollerith Tabulating Machine Company) have been credited with this idea that you have to hire only first-rate people, lest your second-rate people hire third-rate people. This is a disturbingly-conceited idea with narcissistic overtones.
I say the whole topic is naught but an elitist garbage excuse for our collective failure to organize a proper guild of programming.
In 2018, I watched several of the western-conference final basketball games between the Houston Rockets and Golden State Warriors. There was no question: by all statistics the Rockets had the best players. And yet they lost four games of six.
Why?
There is much to basketball that I’ll never be privy to, but I like to think I extracted some insight into how things went so consistently in favor of Golden State:
Let that percolate in your brain for a few minutes.
Great players, like great developers, are reasonably talented people who’ve also put in the years of work to become highly skilled and conditioned. By all appearances, during the rise of personal computing in the 70s through the 90s, that was often happening before students got to university. Therefore, we weren’t actually comparing great to average, but rather experienced to novice, in consequence of opportunity that simply didn’t exist in times past. (Also, there were some inauspicious biases created and reinforced around the same time.)
On one point Brooks is right: Process can raise the floor, but not the ceiling, of what can be accomplished. And genius is a genuine phenomenon: No level of mathematical training or education can prepare the average person to make contributions on the scale of Newton, Leibniz, Gauss, Ramanujan, Brahmagupta, or al-Khwarizmi.
I don’t care.
A thousand times more great mathematical knowledge came not from the great Fermat himself, but the zillions of merely pretty-darn-good mathematicians who devoted themselves to the field, possibly inspired by the prospect of chipping away at his last great conjecture.
(The fact it has finally been solved does not diminish the point.)
Specialization is not for insects. Specialization is for large numbers. Ants and honey bees famously come in large numbers; thence castes and roles. The humble mud wasp lives a solitary lifestyle and does everything necessary for survival. Both are perfectly valid but incompatible lifestyles. You simply cannot run a large organization the same way you would a small one; and neither the reverse: chaos would be your best-case scenario either way.
People like to focus on the company or department as the organization under study. But equally if not more important is the profession as a rapidly growing confederation. Specialization is the inevitable result.
To quote Casey Stengel, “good pitching will always stop good hitting, and vice-versa.”
I distantly recall reading accounts of an adversarial (or worse: conspiratorical) relationships arising between separate QA departments and main-line development. The canonical example? Management declares a bug bonus, so a coder and a tester conspire to write themselves a Winnebago.
One approach to managing that relationship is to make QA and development be the same people, wearing different hats at different times. That’s essentially the case for making developers write their own tests. You could also do this with pairs of programmers who trade roles periodically.
Another approach puts ordinary developers in charge of unit tests, and QA/Test engineers in charge of integration testing. I can imagine some friction over the exact line between the two, but if you’ve played your CIPO cards right I think it would work out OK most of the time.
At this point, I suspect the DEVOPS crowd have about the right idea:
A greater discussion of pair programming: