What I Learned From the 10 Most Common Frustrations of Developers
Stack Overflow’s Annual Developer Survey has turned up a list of what most frustrates software developers.
This list tells me something important about the nature of software engineering in 2024, and something important we can learn from the collective opinions of software engineers.
Let’s crack on!
The List
I’m going to give the list for Individual Contributors, as I feel that people managers should not have too much to complain about in terms of technical frustrations.
Amount of technical debt
Complexity of tech stack for build
Complexity of tech stack for development
Reliability of tools/systems used in work
Tracking my work
Patching/updating core components
Number of software tools in use
Showing my contributions
Maintaining the security of the code being produced
Maintaining the security of systems/platforms used in the work
Breaking Down the Frustrations
Amount of technical debt
Tech debt builds up over time. It isn’t something where you can simply turn the tap off and it just stops, since a side-effect of creating new software is generating tech debt.
I’m working in an environment where tech debt isn’t really worked on. Sure, we complain about the impact of tech debt, but nobody is really working on it, we really work around it. That isn’t the way things should be but I guarantee you — this company culture is more prevalent than you might expect. Developers are happy to complain about tech debt but how many are prepared to bite the bullet and fix it as they go along?
Complexity of tech stack for build
The good old days where you could run make and it just worked never happened.
The problem is that virtualization, CI and a plethora of platforms provide another layer of config and things that can go wrong. It’s not easy to train new juniors to get all these things working and all the commands that should make it *just work*.
We’re all spread so thin these that it is a wonder we can get anything done at all.
Complexity of tech stack for development
Can we just stop adding more frameworks as the solution to everything?
Every new tool is something else to maintain.
A lack of vision from management can contribute to this problem, if you’ve ever had a boss “Just use a third-party framework for that, it’s tested” followed by another “third-party framework? We should do this ourselves” will have sympathy with this.
Reliability of tools/systems used in work
Test environments that don’t work when you need them? We switch ours off at 6 pm and weekends so we aren’t spending unnecessary money.
So, when you’re up against a deadline you’re really up against a deadline.
Tracking my work
Jira. I think we all have issues with Jira. We’re all frustrated, aren’t we?
Patching/updating core components
Updating core components is like defusing a bomb, but you have no idea how. So, you’ll just pick a wire and hope that the bomb *goes away* and nothing happens in terms of side effects.
This is why nobody in my team keeps our dependencies up to date.
Number of software tools in use
What does what again? In a world where developers insist on using a GUI in order to use GIT we have created a world where the number of software tools to learn is pretty much limitless.
Showing my contributions
When did software development become about making sure that everyone else knows what you’ve done?
I hate this. I’ve colleagues who just echo what I say to make it look like they know what they are talking about, it’s just a real shame they don’t. They’re the same people who document work that isn’t theirs so they *own* it, and when there’s an issue come to the original author for help.
Can’t we all just do a demo here and there, and value the work of everybody in the team?
Maintaining security of code being produced
Oops, forgot.
Maintaining security of systems/platforms used in work
Oops, that’s different from the code, isn’t it? Does anyone have the password for the CI? Just ping it over on Slack.
What The List Tells Us
In a sense I find it reassuring that many software developers encounter the same issues and find them frustrating. However, there is something deeper we can learn from this list.
The Individualistic Nature of Software Development
If we are complaining about tech debt and developer build times we really are frustrated by problems at the level of the individual developer.
This demonstrates a mindset that isn’t helpful to creating great software, and that is software developers are so focused on their individual tasks they overlook the issues that impact the whole system.
At my current company, we are siloed to such an extent that we spend days of effort finger-pointing at each other rather than solving the problem. It’s your fault, it’s not my fault battles are not helpful when designing and implementing complex software.
The Persistent Struggle With Technical Debt
Technical Debt seems to be a consistent frustration for software developers. Arguably tech debt is growing in step with the complexity of modern software development.
It’s not something many software development shops seem to think about. Simplicity takes work and can take more time (initially) than an ill-thought-out design.
I’d love to be able to sit down with the whole development team and work out solutions to problems, but we are in a situation where the system is designed, and software developers are told to “just” implement it. I shouldn’t be shocked that this produces outcomes that are sub-optimal for all concerned.
What We Can Learn
It is a good idea for everyone to work together and push the best possible code we can. Things are going to be good, then bad. It’s up to us to make sure that it doesn’t just get worse.
Wouldn’t that be a great thing?
Conclusion
Frustrations ambush us all in our software development journey.
What if we addressed those frustrations head-on and worked to improve productivity, reduce burnout and create great software as a team? Just a thought.