Long live the analyst-programmer

“Getting things done means doing things you might not be interested in. No matter how sexy a project is, there are always boring tasks. Tedious tasks. Tasks that a less mature engineer may deem beneath their dignity or their job title.”

~ John Allspaw

Once upon a time, before we called ourselves agile, there lived a role called an analyst-programmer. The analyst-programmer was a generalist before generalists became cool: just as content to analyze a requirement as to write some code and implement it.

Along came agile software development and its disturbing trend towards having senior developers that are above anything but pure coding. Writing SQL scripts for reference data, analyzing what is actually required, configuring a CI build: these are all tedious tasks that take away from what the senior developer is supposedly entitled to do: just write code to meet explicit acceptance criteria. The senior developer expects a flock of paradevs to run around doing their analysis, writing their acceptance criteria, and finally testing the code that they write. Some even expect the paradev to read the acceptance criteria aloud to them, because reading themselves isn’t coding.

You’ll start to notice who these senior developers are when you hear them say things like “I get paid too much to do this”, or “why are you wasting my time having me do this?”.

One day I imagine a world where all software development roles are suitably generalist and humble, that instead of complaining that “I’m too good for this”, people in these roles simply get their hands dirty and get things done.