Developer productivity – 9 worst wreckers

1. Disturbances and meetings/online discussions

The incessant beeping of notifications from communication channels and e-mails are among the classic disturbers. To get back into the creative zone of the developer’s mind and continue where they were before the break may take up to 30 minutes. The more disturbances, the bigger the frustration, less quality work and more errors.

Solution: If you can’t turn off notifications for a few hours, only set notifications from channels that directly concern you.

The difference between a meeting and a disturbance is that the meeting is scheduled. The impact, however, is the same or perhaps even worse, because the developer knows he can’t fully immerse himself in the work. For example, one meeting around eleven o’clock will ensure that no major task is completed during the morning.

Solution: Short meetings right at the start of the workday, or just before lunch.

2. Vagueness

It not only delays but can disgust the developer to the point of considering leaving. Indication that something does not work is not a task! Bug report shall contain enough information for the developer to know how to address the issue. Otherwise, he wastes time by figuring things out and speculating.

3. Seagull management

Surely you have heard about it. These are managers who are not so involved in the project, but still arrive once in a while and “crap over” everything. Without sufficient information, they criticize everything: “This looks terrible. Fix it.” For developers, this type of behavior is very demotivating, and the work drive can be reduced for the next few days.

Solution: Only people who find out enough about the project should comment on it.

4. Credits

This happens quite often. Some other developer or manager takes credit for the work of a developer. This creates tension that destroys developer productivity for a long time.

5. Working environment

The productivity is affected by very many factors. For example, programmers love sounds that may disturb employees in other positions – a certain amount of white noise (loud air conditioning, sounds of passing cars and trucks…) helps them to concentrate better.

6. More tools and hardware

The programmers use tens of tools for programming, committing and merging every day. The more automation the better. But if the programmer uses some “legacy” tools, it may affect his productivity. Related to this is the quality and performance of the equipment, the option of a second monitor. This means that the investment will pay off. The better tools, the better the productivity.

7. The documentation says how but not why

Code commenting is a common practice that helps with later modifications and problems, especially when they have to be addressed by a different developer than the one who wrote the code originally. A common mistake, however, is that the comments are few, or they only describe what the code does, but few explain why.

r = n / 2; // Set r to n divided by 2
// repeat until r — (n/r) is greater or equal to t, while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r) }
}
If you were fixing a bug and saw this code, you would not know where to start.

8. Unreasonable deadlines

Everyone is struggling with unreasonably tight deadlines today, and developers even more so. Managers try to reduce the original estimates and consider the resulting estimate as a binding deadline. They take it as valid and share it with senior management. No wonder programmers feel that deadlines are disproportionate, creating stress that makes it difficult to concentrate.

Solution: Set realistic deadlines together with the developer

9. Contents creep

The contents creep (sometimes also the scatter of focus, requirements, functions and sometimes the include-all syndrome) in project management refers to uncontrolled changes in the scope of the project. This can happen if the project scope is not properly defined, documented or managed.

The contents creep transfers relatively simple requirements into terribly complex and time-consuming monsters! And this usually happens during development! A simple function example: Version 1 (before implementation): the function is “Display location map”Version 2 (when version 1 is almost done): the function morphs to “Display 3D location map”Version 3 (when version 2 is almost done): the function morphs to “Display 3D location map that the user can fly over”

If you want better productivity from your developer, talk to him. Ask what he struggles with the most and what impedes his work. The vast majority of problems can be solved. Although today’s technology is very different from that of 30 years ago, the lesson learned is still the same. When assessing the team productivity, the human factor cannot be ignored. Go through your processes, environment and work habits with your team and let them lead you to the highest productivity and effects.