Developers are 80% Typists. Here’s What Must Change
Photo by Luca Bravo on Unsplash
Ask the proverbial “man” in the street what a software developer does all day and they’ll likely answer “they write code”. They have the basic job down pat, but if you’ve ever worked as a developer, you know the truth.
Coding is just part of a software engineer’s job, and much more is expected besides. So, when Amazon claimed that developers spend an average of an hour a day coding this passed without much comment. So, are developers really spending most of their time (as Amazon claims) learning codebases, writing and reviewing documentation, testing, managing deployments, troubleshooting issues or finding and fixing vulnerabilities — most of which can be boiled down to simple typing tasks?
Let’s find out. I’m going to break down the problem and discuss what needs to change.
What Are Developers Doing
This isn’t just about developers being lazy. It’s also not just about developers at Amazon not performing, since software.com has reported similar findings.
A developer’s day is spread across many activities, such as planning, documentation, meetings, and collaboration.
Learning Codebases
Navigating someone else’s spaghetti code feels less like coding and more like archaeology. How we implement proper onboarding instead of throwing new devs into the void and hoping they swim rather than sink?
Documentation
Writing endless documentation is the lifeblood of good software. The problem is that much of it is just rephrasing code in plain English for people who will ignore it anyway. Low-quality documentation takes too much time
Testing and Debugging
A critical part of the job, sure, but the repetitive, manual nature of these tasks could often be avoided with better processes and tools. A little bit of automation would go far.
Meetings, Meetings, Meetings
Stand-ups, retros, sprint planning, and quick syncs take up valuable time. Developers spend more time talking about work than actually doing it. As developers we know that each time we get distracted it takes a long time to get back into the flow of development, and this time comes right out of the day. What a waste of life.
Deployment and Troubleshooting
Managing deployments and fixing issues in production eats away at the time that could otherwise be spent building new features and squashing those production bugs.
Why This Is Broken
The real issue isn’t that developers do these things, it’s that they have to and this comes at the expense of delivering things of value. The modern software development lifecycle is riddled with inefficiencies. In some companies, there is redundancy and waste (I would have a standup right before sprint planning, with a 15-minute gap of course). In other cases, there are just bad processes (notably I’ve needed to copy the details of JIRA tickets into a content management system for a release — why?).
Sometimes broken processes are seen as necessary evils rather than fixable symptoms of systemic problems.
Over-reliance on Human Effort
Why are we still manually testing every edge case when automated testing exists?
Why does deployment still feel like diffusing a bomb, without documentation (in my case)?
Too much relies on human intervention, and not enough time and effort are spent in automation and making things easier in the long term.
Poor Tools and Processes
The tools are there, but teams often don’t invest in learning or implementing them properly.
We moved documentation from our content management system into the project, and then back again a few months later. At no point did we audit what we have and think about improving the process.
Bloated Agile Processes
Agile, in theory, is great.
Agile involves hours of unnecessary meetings and arbitrary deadlines.
I’m familiar with the latter version. We spend standup meetings arguing over solutions and never have refined tickets ready for development. It never changes.
What Needs to Change
Here’s the good news: it doesn’t have to be this way. Developers don’t need to be stuck as glorified typists, let’s be the change we wish to see.
Automate the Tedious
AI and automation tools like Amazon’s Q Developer are a step in the right direction. Automating documentation, testing, and even parts of debugging can give developers back hours of their day.
Streamline Processes
Agile is a means to an end, not an end in itself. Teams should ruthlessly cut anything that doesn’t add value. A two-hour sprint retrospective is a waste if it doesn’t lead to actionable improvements, so if it’s not working cut it out entirely.
Focus on Developer Experience
If onboarding new hires feels like throwing them into a pit of snakes, do something about it. Invest in clean codebases, proper documentation, and tools that make work easier. Even develop a proper onboarding process with time allocated to get used to the codebase and the various tools in use at your company.
Shift the Culture
Management needs to recognize that developers aren’t just code monkeys. Measure performance by outcomes, like the impact of the features shipped. Perhaps introduce 360° reviews to see how developers are seen by their peers.
Can AI Fix This Mess?
AI isn’t a silver bullet. I have nightmares thinking that AI is actually going to contribute to more poor processes being forced onto programmers.
Yet there is an opportunity here. Could we limit the amount of tedious work that developers do rather than getting to the heart of making things better? AI is the tool that might just help developers focus on the creative, impactful work they signed up for.
Conclusion
If we’re going to spend 80% of our day not coding, it better be worth it.
Developers aren’t typists, but it feels like it with the low-quality repetitive work we are expected to churn out day by day. We are wasting our (and our companies) time. It’s time the tech world stood up and addressed the inefficiencies that make development feel like a grind. If that requires and uses AI, so be it.