12 Things that Destroy Software Developer's Productivity

Breaks and meetings

The break is the main killer of developer productivity. Returning to an abandoned task can take a very long time. The more interruptions, the more difficult it is to concentrate on work again. The result is more bugs.
Meetings are the same break, even worse. The developer cannot concentrate normally if he knows that after an hour or two the workflow will be interrupted. He will not even begin a serious task, as he certainly will not have time to complete it.
One meeting can blow up an entire day, breaking it into two parts, each of which is too small for any difficult task.
A short planning session at the beginning of the day or before lunch would help get rid of unnecessary breaks.

Micromanagement

Of all managers, micromanagers for the productivity of developers are the worst. They arrange many meetings, unplanned breaks, but this is not the worst. Micromanagers do not trust you, undermine your skills and ability to work, kill motivation. What productivity can we talk about here? Very often it’s micromanagers that cause developers to leave and change teams.

Uncertainty

Uncertainties can be very different.
For example, incomprehensible error messages like “it's broken!”, “Fix!”. Information is clearly not enough, it takes time to figure it out. By the way, having a bug report template could help here.
The specification of a new function may be uncertain. Sometimes developers begin to implement what they think is right, and then the manager reports that they thought of something completely different and they need to redo everything from scratch.
This also includes fuzzy prioritization. Burning tasks should be performed first, but only if the developer knows about it. Otherwise, he may do something else. Disappointments cannot be avoided here.

Seagull management

Have you heard about seagull management - a special approach in which managers are completely not involved in the work of a programmer? They just come from time to time and criticize everything around. “Everything is wrong, it looks bad” and so on. And then they just fly away fervently, leaving behind an upset developer who cannot return to a normal rhythm for a long time. Unfortunately, this happens more often than we would like.

Merit appropriation

Has it ever happened that someone else has arrogated to himself all the merits and praises for some work that you have done? This is a terribly stressful and insulting moment that completely kills all your productivity for a long time.

Working Environment

This refers to environmental factors such as noise, movement, design of the room and your workplace.
A comfortable environment is very important for programmers. For example, some just need background white noise — a pant of a computer, a buzz of cars outside a window, the sound of rain, music, while others prefer to work in silence.
The constant running around makes it very difficult to concentrate on work, and if your computer screen is perfectly viewed by managers, it is seriously annoying. An uncomfortable environment is the reason for low productivity.

Project Creep

Creep - uncontrolled changes in the project. This happens when the initial definition of goals isn’t clear, incorrectly prepared documentation or lack of proper control.
Simple tasks become complex, the development process drags on, productivity decreases.
Here is a simple example of a function creep:

• It all starts with the first definition of functionality - "Show location on the map"
• When the implementation is almost complete, a clarification comes: now you need to "Show location on a 3D map"
• You are angry, but you are also doing this task. However, they now require you to "Show the location on a 3D map through which the user can fly"

Product definition process

How can product definitions affect developer productivity?
If a team builds its work without checking (for example, through customer reviews) interest in existing functionality, a situation may arise when a number of functions are simply not used. As a result, developers are keenly aware of the futility of their work, which leads to a loss of motivation.
We all want to feel needed, and this is especially important for programmers.

Lack of technical debt accounting

Technical debt is a deliberate and informed decision to implement some things in the worst possible way, in order to release the product as soon as possible. Sometimes this is inevitable and allows you to increase the speed of creating software in the short term. However, in general, technical debt complicates the system and slows down developers, so it needs to be addressed in a timely manner.
If you move forward all the time, not including code refactoring among the main priorities, there are big problems with the productivity and quality of the product.

Tools and equipment

Programmers use many different tools to automate routine work. If your work environment is outdated, does not cope with its tasks or complicates the process too much, productivity will decrease.
It is also more convenient for a programmer to work with a large monitor than with a small one, with a powerful computer, than with a constantly freezing one.
It would seem that these are trifles, but they can easily provide an increase (or drop) in productivity by a few percents.

“How?” Type documentation

When we begin to study programming, we are constantly reminded about the importance of the comments - “better is more than less”.
However, many programmers misunderstand this idea and begin to comment on literally every line.
It is difficult to work with comments that tell what actions are taking place, and not why they are happening. A more or less experienced programmer is able to understand how an assignment or a loop works, but it is impossible to guess what data is processed here without additional information. Errors that occur in such programs are quite difficult to fix.

Impossible Deadlines

This item is connected with the bad habit of managers to ask developers for temporary estimates of implementation, to achieve their maximum reduction, and then magically turn these estimates into tight deadlines. Managers love deadlines, see them even where they are not yet, and can sincerely believe that the developers installed them by themselves.
It is not surprising that programmers consider this formulation of the question unreasonable. This creates tension and makes it difficult to concentrate.

Let's take another look at the resulting list. All 12 productivity killers are ubiquitous - in different areas of human activity. They are not specific only to software development.

However, programmers need a deep focus to solve problems, so each of these factors can easily undermine their productivity. Of course, technology has advanced a lot, but the human factor cannot be ignored. The more comfortable it is for a programmer to create, the more effective development is.