Somewhere along the way, we forgot about the skill of programming
“We’re Agile now, baby. Move fast and break things!”
“We measure our engineers by the impact they make!”
Somewhere along the way, in the midst of software agilification or the gold rush of software engineer salaries, we forgot about skill.
I’ve worked at large tech companies, startups, consulting firms, and even the government. These are all different environments with one key similarity: code quality is poor, especially recently.
Don’t get me wrong, there are areas of good code. Individual examples of true care and craftsmanship. But by and large, what I’m seeing now is people trying to get the product out as quickly as possible, ignoring the burden of support in 1, 2, 5, 10 years.
So what’s going on? I don’t know for sure, but my main theories are.
Distorted incentives associated with “influence”
In large technologies, it is customary to consider “impact” in evaluating an engineer’s work and making promotion decisions. Unfortunately, “impact” is almost always measured by what features you delivered, not how your code affected the long-term viability of the codebase.
If you’re looking to move up the ladder and want to be paid more money (nothing wrong with that), then it’s only logical that you’ll ship more features—even if the code you ship is of lower quality.
The pressure of the backologist
I don’t blame the agile methodology. But I partly blame Agile™. Right now, you are most likely in an Agile™ environment where you are overwhelmed with tasks. Should you focus on improving the quality of the feature you’re working on? Or should you tackle the other 17 tasks you have in this sprint?
More senior engineers may brush it off and say, “I need to spend more time getting this right.” But junior and middle developers? They have to keep up with the times so that they are not seen as “slow”.
Many of us now ship our products online. In some cases they are entirely web-based, while in others we can deliver patches over the Internet. In any case, we almost never ship physical CDs where we have to be damn sure the software works. We can afford to “move fast and break things.”
But it also means that we willingly allow shortcuts and untested code in our codebases. This gradually destroys the quality of the code base and one fine day we wake up and realize that everything is in complete chaos.
No one focuses on skill anymore
The last thing I want to say is that it feels like I haven’t talked about mastery at work in forever. Maybe I’ve just been in the wrong places every now and then.
Or maybe, and this is what I’m really afraid of, the people who are really focused on the craft of software development are retiring or just running away. Somewhere along the way, we forgot about programming skills.