I feel like part of the problem is that management wants staff that can do a wide range of tasks when it ends up creating a staff that can’t specialize in a small group of tasks.
I’ve seen plenty of times where people can operate well as a cog on a big machine, but fall apart when they have to work in roles that require a variety of skillsets. Larger engineering companies can typically create enough work for people to specialize in smaller tasks than smaller engineering companies.
I’m so sick of this “moving fast” mindset. The result of which is my newsletter being full of security hole and hacked.
What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
Ah, really? Are you sure that’s what matters?
Moving fast doesn’t have to mean poor workmanship.
To make an analogy, if you want to be able to make a cup of coffee fast, you need to make sure that the coffee beans, the water, and the brewer are all near each other, that there is electricity and that the water is running. These are all things that enable you to move fast, but they don’t decrease quality, if anything they increase quality because you aren’t wasting time and effort tackling obstacles unrelated to brewing.
Which is in fact the point of the article. That you should make sure you have a good development environment, with support systems and processes, so that you can work effectively even if your developers are not savants. Rather than trying to hire people who are good enough to do a decent job even in the worst environments.