Top 12 Things That Destroy Developer Productivity

A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!

No one expects a programmer to get work done without access to a computer, but there are many companies that expect programmers to get work done without access to their mind. This is equally unrealistic.

So let’s deep dive into our list of 12 things that prevent your developers from getting “into the zone” and being productive. I will try to prioritize this list from most to least impactful. Feel free to comment!

If you’re wondering if all this is worth the investment, just consider the developer’s salaries. Even 10% more productivity is a LOT!

1) Interruptions & Meetings

Interruptions are the top productivity killer for developers, in my mind. Developers can’t easily go back to where they were right before an interruption. They need to get into the mindset for development and then slowly trace back to where they left off. This can easily take more than 30 minutes. And the more interruptions, the more frustration, the less quality work, the more bugs.

“The more times you trip me up while I’m trying to get started, the longer between each time I’m going to try. If you fill my morning with interupttions and don't be surprised when the day is unproductive.” - a Developer on Reddit. 

What about meetings? The only difference between a meeting and an interruption is that a meeting is a planned interruption, which makes it even worse. Developers can’t progress on a task if they know that they will have an interruption while working on it. So if they have a meeting in one or two hours, they will not be able to progress on anything, as most engineering tasks take more time.

As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”

How can this be avoided? This part is well documented; you have no excuse. Hold short status meetings at the very start of the day or just before lunch, for example, to avoid unnecessary interruptions.

2) Micro-management

Of the different types of managers, micro-managers might be the worst in terms of the developers’ productivity. Sure, micro-managers tend to have more meetings and unplanned interruptions. But it’s not only that. They show a lack of trust, and by doing so, you feel they constantly undermine your skills and your ability to get things done. Any motivation a developer had between interruptions will be just gone at that point. The impact goes beyond productivity. Micro-managers might be the first reason for developers to leave, or at the very least, to change teams.

3) Vagueness

There are many ways to illustrate vagueness. Bug reports like “It’s broken, fix it!” don’t have enough information for developers to work off of. By the way, having a bug report template can help in that case.

Or unclear specification on a feature, in which case developers will start implementing what feels right to them, before they have to start again from scratch once the manager better details the expected behavior.

Unclear prioritization also belongs in this category. The time that a developer spends wondering if they are working on the right task can so easily be avoided. And if ever they get a comment from the manager asking why they worked on this particular task (while priorities were not defined)…well, you get it, a lot of frustration... 

4) Seagull Management

Have you ever heard of it? It happens when managers are totally uninvolved in the work, but… they just swoop down once in a while to shit all over everything. “This is wrong, and this, and this looks bad,” etc., before flying away again. I have to admit I loved the image, but unfortunately, this happens more often than we would like it to. This behavior is deeply frustrating to developers; they won’t be able to get back in the zone in the next few hours, and sometimes not even for days.

5) Credit Greediness

Have you ever had a manager or other developer who took all the credit for the work you have done in the past weeks? Developers value competence above all. Taking the credit for someone else is taking the other’s competence for yourself and removing it from him or her. This is pretty high up on my list, as I feel it creates so much tension that it just destroys the whole developers’ productivity for quite a while.

6) Environment: Noises, Motion, Workspace Design...

This might seem strange to non-programmers, but the environment in which developers work has an important impact on their activities. For instance, having some white noise helps them focus better. That’s why so many of us put headsets on! I actually just discovered RainyMood. 

Similarly, if the workspace is designed to have as much motion as possible, that won’t help them focus! Or having the desktop computer screens oriented in such a way that they are highly visible to the managers…well, that creates some extra stress and even more opportunities to be interrupted.

7) Scope Creepiness

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled.

Scope creep turns relatively simple requests into horribly complex and time-consuming monsters! And most of the time it happens during development! For instance, for a simple feature:

• Version 1 (before implementation): feature is “Show a map of the location”
•  Version 2 (when version 1 almost finished): feature is changed to “Show a 3D map of the location”
•  Version 3 (when version 2 almost finished): feature again changed to “Show a 3D map of the location that the user can fly through”

8) Product Definition Process

So this one might seem strange at first glance, but is actually pretty easy to understand. If a product team defines its team’s priorities without ever validating (through customer feedback or any other means) the interest of the corresponding features, and the developers see that most features are eventually just not used, they will feel that what they do is useless and will lose their motivation. We all want to feel impactful, and that may be even more important to developers!

9) Lack of Consideration to Technical Debt

Technical debt is a deliberate decision to implement not-the-best solution or write not-the-best code to release software faster. Taking on some technical debt is inevitable and can increase speed in software development in the short run. However, in the long run, it contributes to system complexity, which slows the developers down. Non-programmers often underestimate the loss of productivity and are tempted to always move forward, and that becomes an issue. But if refactoring is never part of the priorities, it will not only impact productivity but also product quality.

10) Tool Multiplicity & Hardware

Developers use many tools to program, push and merge their code every day. The more automation, the better. It goes without saying that if you use “ancient” tools, this will impact your productivity. Similarly, having a big screen vs only a laptop can have an impact. Given the cost of hardware and the developer’s salary, having just a 5% productivity gain is definitely worth any investment on that point! Just give the tools and hardware that your developer team prefers (individually for hardware, but as a group for the tools).

11) “How” Documentation

When learning how to code, we were told to comment early and often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers incorrectly interpret this to mean that they must comment every single line of code, which is why we often see code like this (from Jeff Atwood’s post on “Coding Without Comments”):

r = n / 2; // Set r to n divided by 2

// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)

}

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it. If there were a bug in the program and you stumbled across this code, you wouldn’t know where to begin.

12) Impossibly Tight Deadlines

This last one is linked to the tendency of managers to ask developers for estimates, then push them to lower those estimates as much as possible, and then magically consider them as deadlines! Managers will even consider that, as the developers themselves “decided” on the estimate, they committed to the deadlines, and therefore the deadlines should be considered valid enough to be shared to upper management.

Not surprisingly, developers feel that those deadlines are unreasonable and arbitrarily tight; this creates tension and an inability to focus.

How are all those things unique to developers?

If you look at all 12 things, they are actually pretty common to most other project-based jobs. It’s just that the impact of each of these is even more important for developers, as they need deep focus to progress on their tasks.

If you recognize some points mentioned above within your company, it might be interesting to address them with your developers. Talk to them; find out if these are an issue and how it can be resolved. Whatever they say, the most important thing is to trust their feedback and insights. And while today’s technology is very different from 30 years ago, the lesson is still the same. You can’t ignore the human factor when you consider team productivity. Iterate on your processes, environment and work habits with your team, and let them guide you on how to have the highest productivity and impact.