[kjellsbells]

A less generous take on this post is that an elite engineering team drove a perfectly competent developer out of the company by minimizing the perceived value of their contribution. I don't think that was good management, if so.

Fred Brooks, in the Mythical Man Month, identified the value of "toolmakers" to the "surgeons" many years ago. I think that model applies here too.

Seems to me that a better path would have been to ask the developer in question to lead the automation project, and generally push them over time to look for, and implement, improvements across the development chain that increase efficiency. The elite devs get to keep on doing what they do, but now the whole boat is lifted, and the dev gets to put some real wins on their resume.

[kragen]

i agree with all of this except for the 'perfectly competent' part. a programmer who advocates hiring someone else because they're too busy doing routine work instead of automating it is not a 'perfectly competent developer'; they're what this article terms a 'technician'

(actual technicians, however, for example in electronics or chemistry labs, are generally not doing routine and predictable work; they spend a lot of their time debugging why things have failed, which is the opposite extreme, and they tend to automate as much of their work as they can. so i'm not convinced the choice of term is correct)

neither toolmakers nor surgeons in brooks's model were doing routine, predictable work. (but his model also hasn't been very successful, so possibly it wasn't a good model)

i like smaug's term 'toil'. so maybe we should say 'software engineers should not toil too much' instead of talking about what they should or shouldn't be

[Gabriel439]

Author here: we didn't lay them off. They left of their own accord.

[rideontime]

The parent comment didn't claim you did?

[Gabriel439]

Oh whoops, I misread. Never mind me, then

[swader999]

Thanks for your article. Decent ideas in it.

[Gabriel439]

you're welcome!

[dogleash]

Defending yourself by clarifying you didn't do X, when the suggestion was that you did Y, always looks more sus than not saying anything at all.

[giantg2]

I agree. Firing is at least more honest (or there's a lawsuit if it isn't). Being pushed out sucks. I know because it's happening to me right now for bullshit reasons (the complaint is that my throughput is inconsistent but yet my average throughput is better than the other dev of my level on the team, and I'm involved in more above and beyond work). Being pushed out is very stressful and has negative mental and physical effects, especially if you have specific disabilities (I do).

[steveBK123]

Exactly. I usually don't stick around when a team enters that phase, but sometimes it takes a 6-12 months to exit.

I've been on teams where management very clearly tries to do a good team/bad team split.

This looks like hiring some space cadets to build the "strategic solution" that will magically fix every problem with the existing system (despite being managed by the same senior management).

The existing team is told to just keep the lights on / the new thing is going to be so much better / just give it another year or five.

There's not a lot of upside to staying around because you either end up fired at the end if the space cadets succeed, or if the space cadets fail you end up holding the bag of rescuing them in X years post strategic platform failure. And sometimes a secret third thing - the company being run this poorly ends up having to do RIFs and you end up fired randomly anyway.