12 factors that prevent programmers from working
No one would require a developer to write code without access to a computer, but many companies believe that he should somehow work without the ability to fully use his thinking abilities. And this is about as unreal.
And so let's go through the list of twelve things that prevent developers from entering a state of flow and deliver maximum productivity. I will try to move from the most key things to the less significant ones. Offer your options and comments!
')
If someone doubts whether it is worth spending money and energy on it, it is enough to remember how much programmers are paid. Even a performance gain of 10% is a lot of money!
In my opinion, distracting the developer is the surest way to kill his productivity at the root. He cannot simply take and continue from the place where he was interrupted. He needs to first re-engage in the process, and then still go through the entire chain of thought to the right moment - this alone can take half an hour or more. And the more such breaks happen, the more irritation accumulates, the lower the quality of work becomes, the more often bugs appear, and the list can be continued.
Well, meeting? Their only difference from other distractions is that they are planned in advance. And that makes the situation worse. It is difficult for a programmer to advance in solving a problem if he expects a break in work in advance. Therefore, if in an hour or two he has to go to the planning meeting, most likely he will not be able to do anything significant for any of his projects - after all, most engineering tasks take more time.
In the words of Paul Graham: “One meeting can kill half a day: time is divided into two periods, during which nothing serious can be done”.
How to avoid this state of affairs? On this account, everything has long been painted, so there is no excuse. You just need to put the planning at the very beginning of the day or, say, right before lunch, so as not to unnecessarily distract people from work.
Of all the types of managers, those who intervene for any reason, perhaps the worst effect on the productivity of employees. Of course, the fact that this type is especially inclined to organize a bunch of meetings and demand the attention of developers for unforeseen reasons also has an effect. But it's not only that. Such actions show a lack of trust, and as a result, people have a feeling that they are considered to be incapable of anything and question their professional skills. Even if the programmer still has some motivation to work despite endless interruptions, this attitude will discourage it completely. The consequences are not limited to a single drop in performance. Intrusive managers especially often force employees to leave the company or, at least, the team.
Insufficient clarity can be illustrated by many different examples. For example, a bug report in the spirit of "It does not work here, fix it!" Clearly does not give developers all the information necessary for the work. By the way, in this particular case, the introduction of a template for bug reports can help.
Or another case: vague requirements for some part of the product. With such introductory developers, they simply begin to do what they themselves all represent, and then the manager comes in with a more detailed description of the expected user behavior, and they have to start all over again.
Vague priorities are also in this category. Programmers spend a lot of time puzzling over where it would be better for them to start, although it would be very easy to avoid it. Well, if they ever have to report to the manager, why are they doing this, and not this (despite the fact that no-one has negotiated the order), you can be sure that they will be fine with it.
Ever heard of this? There are managers who do not participate in the work process at all ... except for those moments when they suddenly decide to dive on someone and crap everything. "This is no good, and this too, and it does not look at all," - and flew on. I have to admit that I like the comparison, but the phenomenon behind it is much more common than we would like. This behavior affects the developers very badly: many people have to work out the working mood for hours after that, and someone falls out of the flow for whole days.
Has it happened to you that some of the managers or other programmers ascribed to themselves the merits of what you have been fighting for several weeks? Developers put their professionalism above all. To steal other people's merits is the same as denying a person competence in order to inflate his own. I put this point high enough because I believe that such things lead to a very tense situation that can “drop” the performance of the whole team for a long time.
It may seem strange to people from other professions, but for programmers the environment decides a lot in the course of work. Say, white noise - the buzz of an air conditioner, the resounding rumble of cars and trucks from the street - helps them focus better. That is why many of us work in headphones! By the way, I recently discovered RainyMood - a great thing!
However, if the office is designed so that there is always some movement around a person, this will have the opposite effect. And if, moreover, the monitors are such that managers constantly see what is on the screen, this creates both extra stress and unnecessary reasons to distract developers from the business.
In project management, this term is used for situations where project volumes are growing uncontrollably. This usually happens when initially they were not strictly defined and documented or not tracked in the process.
Due to the displacement of borders, relatively simple requests grow into confused monsters that eat up a lot of time! And in most cases, it begins when the product is already in development.
Take for example a simple function:
This may seem confusing at first glance, but in fact, everything is simple. If the people responsible for the product prioritize, without testing their hypotheses (through feedback or in any other way) about the interest of the audience to these or other opportunities, and the developers see that these opportunities are simply not used, then they will have the feeling that their work does not make sense, and motivation will collapse. We all want to feel that we leave some mark on the world, and this is especially important for developers!
Technical debt is a conscious decision to allow certain stretches in the choice of solutions and writing code to roll out the product quickly. Some amount of technical debt arises in any project inevitably and can help with the terms at short distances. However, in the long run, it increases the complexity of the system and thereby slows down the developers. Far from programming, people often underestimate the impact of these processes on performance and require moving forward without interruption — in this situation problems begin to arise. If refactoring is always left out of the list of priorities, not only the productivity of employees, but also the quality of the product will suffer.
Developers use many tools each day to write, push, and merge code. The more they manage to automate processes, the better. It goes without saying that ancient tools will have a direct impact on the level of performance. Also much is decided by what the work is done on - on one laptop or also on an additional screen. If we compare the prices of iron with the salaries of programmers, then even a 5% increase in productivity will definitely pay off all costs! You just need to provide the team with the equipment and tools that they prefer to use (for the equipment, the solution should be individual, for tools - a collective one).
In the process of learning programming, we all learned that the comments to the code should be added as early as possible and as often as possible. The idea was that it’s better to have too many comments than not enough. Unfortunately, many misunderstood this and decided that each line needed explanations. That is why we have swatches like this here, from the article by Jeff Atwood "Code without comment":
Did you understand that the code is actually doing this? So I did not understand anything. The problem is that it says a lot about how everything works, but not a word about why it is needed. If we assume that a bug has arisen in the program and you have discovered such a code fragment under the hood, it would not help you to understand the situation.
The last point is tied to the managers' tendencies to ask the developers to estimate how much time they need, then to pressure them to underestimate this estimate, and then magically equate the final date to the deadline! At the same time, managers even believe that once the developers have “set the deadlines themselves," it means they have subscribed to the appropriate deadline and should be considered a finally approved version that can be passed on to the top management.
The developers, on the other hand, believe that such a deadline is complete insanity and it is impossible to keep within it; there is a rift in the team and no one can concentrate.
If you look at all these 12 points, you can see that they are, for the most part, relevant to all those involved in projects. Simply in the case of programmers, they are especially critical, since their work requires a deep immersion in the process.
If you notice that some of these points are typical for your company, it would be nice to go through this list together with the team of developers, build a dialogue with them, find out where problems arise and how best to solve them. Whatever they may say, it is extremely important to take this feedback and comments seriously. Over the past thirty in terms of technology, a lot has changed, but the basic principle of teamwork remains the same: speaking about productivity, it is necessary to take into account the human factor. Improve your work processes, environment, team habits and give them the opportunity to tell you how to achieve maximum productivity.
And so let's go through the list of twelve things that prevent developers from entering a state of flow and deliver maximum productivity. I will try to move from the most key things to the less significant ones. Offer your options and comments!
')
If someone doubts whether it is worth spending money and energy on it, it is enough to remember how much programmers are paid. Even a performance gain of 10% is a lot of money!
1) Meetings and other distractions
In my opinion, distracting the developer is the surest way to kill his productivity at the root. He cannot simply take and continue from the place where he was interrupted. He needs to first re-engage in the process, and then still go through the entire chain of thought to the right moment - this alone can take half an hour or more. And the more such breaks happen, the more irritation accumulates, the lower the quality of work becomes, the more often bugs appear, and the list can be continued.
“The more often I get distracted when I try to start a task, the more time starts to pass between attempts. If I’m jerking all morning, there’s nothing to be surprised that the day was unproductive. ”- Anonymous developer with Reddit
Well, meeting? Their only difference from other distractions is that they are planned in advance. And that makes the situation worse. It is difficult for a programmer to advance in solving a problem if he expects a break in work in advance. Therefore, if in an hour or two he has to go to the planning meeting, most likely he will not be able to do anything significant for any of his projects - after all, most engineering tasks take more time.
In the words of Paul Graham: “One meeting can kill half a day: time is divided into two periods, during which nothing serious can be done”.
How to avoid this state of affairs? On this account, everything has long been painted, so there is no excuse. You just need to put the planning at the very beginning of the day or, say, right before lunch, so as not to unnecessarily distract people from work.
2) Carping to trifles
Of all the types of managers, those who intervene for any reason, perhaps the worst effect on the productivity of employees. Of course, the fact that this type is especially inclined to organize a bunch of meetings and demand the attention of developers for unforeseen reasons also has an effect. But it's not only that. Such actions show a lack of trust, and as a result, people have a feeling that they are considered to be incapable of anything and question their professional skills. Even if the programmer still has some motivation to work despite endless interruptions, this attitude will discourage it completely. The consequences are not limited to a single drop in performance. Intrusive managers especially often force employees to leave the company or, at least, the team.
3) Vagueness
Insufficient clarity can be illustrated by many different examples. For example, a bug report in the spirit of "It does not work here, fix it!" Clearly does not give developers all the information necessary for the work. By the way, in this particular case, the introduction of a template for bug reports can help.
Or another case: vague requirements for some part of the product. With such introductory developers, they simply begin to do what they themselves all represent, and then the manager comes in with a more detailed description of the expected user behavior, and they have to start all over again.
Vague priorities are also in this category. Programmers spend a lot of time puzzling over where it would be better for them to start, although it would be very easy to avoid it. Well, if they ever have to report to the manager, why are they doing this, and not this (despite the fact that no-one has negotiated the order), you can be sure that they will be fine with it.
4) Gull Managers
Ever heard of this? There are managers who do not participate in the work process at all ... except for those moments when they suddenly decide to dive on someone and crap everything. "This is no good, and this too, and it does not look at all," - and flew on. I have to admit that I like the comparison, but the phenomenon behind it is much more common than we would like. This behavior affects the developers very badly: many people have to work out the working mood for hours after that, and someone falls out of the flow for whole days.
5) Theft of laurels
Has it happened to you that some of the managers or other programmers ascribed to themselves the merits of what you have been fighting for several weeks? Developers put their professionalism above all. To steal other people's merits is the same as denying a person competence in order to inflate his own. I put this point high enough because I believe that such things lead to a very tense situation that can “drop” the performance of the whole team for a long time.
6) Furnishings: noise, movement, design of the workspace ...
It may seem strange to people from other professions, but for programmers the environment decides a lot in the course of work. Say, white noise - the buzz of an air conditioner, the resounding rumble of cars and trucks from the street - helps them focus better. That is why many of us work in headphones! By the way, I recently discovered RainyMood - a great thing!
However, if the office is designed so that there is always some movement around a person, this will have the opposite effect. And if, moreover, the monitors are such that managers constantly see what is on the screen, this creates both extra stress and unnecessary reasons to distract developers from the business.
7) Shifting the project boundaries
In project management, this term is used for situations where project volumes are growing uncontrollably. This usually happens when initially they were not strictly defined and documented or not tracked in the process.
Due to the displacement of borders, relatively simple requests grow into confused monsters that eat up a lot of time! And in most cases, it begins when the product is already in development.
Take for example a simple function:
- The first version (before implementation): the function is defined as "Display location map"
- The second version (when the first iteration is almost finished): the description changes to “Display 3D location map”
- The third version (when the second iteration is almost complete): the description changes to “Display a 3D location map that the user could navigate”
8) The process of identifying product features
This may seem confusing at first glance, but in fact, everything is simple. If the people responsible for the product prioritize, without testing their hypotheses (through feedback or in any other way) about the interest of the audience to these or other opportunities, and the developers see that these opportunities are simply not used, then they will have the feeling that their work does not make sense, and motivation will collapse. We all want to feel that we leave some mark on the world, and this is especially important for developers!
9) Ignoring technical debt
Technical debt is a conscious decision to allow certain stretches in the choice of solutions and writing code to roll out the product quickly. Some amount of technical debt arises in any project inevitably and can help with the terms at short distances. However, in the long run, it increases the complexity of the system and thereby slows down the developers. Far from programming, people often underestimate the impact of these processes on performance and require moving forward without interruption — in this situation problems begin to arise. If refactoring is always left out of the list of priorities, not only the productivity of employees, but also the quality of the product will suffer.
10) A variety of tools and equipment
Developers use many tools each day to write, push, and merge code. The more they manage to automate processes, the better. It goes without saying that ancient tools will have a direct impact on the level of performance. Also much is decided by what the work is done on - on one laptop or also on an additional screen. If we compare the prices of iron with the salaries of programmers, then even a 5% increase in productivity will definitely pay off all costs! You just need to provide the team with the equipment and tools that they prefer to use (for the equipment, the solution should be individual, for tools - a collective one).
11) Documentation in the style of "how"
In the process of learning programming, we all learned that the comments to the code should be added as early as possible and as often as possible. The idea was that it’s better to have too many comments than not enough. Unfortunately, many misunderstood this and decided that each line needed explanations. That is why we have swatches like this here, from the article by Jeff Atwood "Code without comment":
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)
}Did you understand that the code is actually doing this? So I did not understand anything. The problem is that it says a lot about how everything works, but not a word about why it is needed. If we assume that a bug has arisen in the program and you have discovered such a code fragment under the hood, it would not help you to understand the situation.
12) Extremely short deadlines
The last point is tied to the managers' tendencies to ask the developers to estimate how much time they need, then to pressure them to underestimate this estimate, and then magically equate the final date to the deadline! At the same time, managers even believe that once the developers have “set the deadlines themselves," it means they have subscribed to the appropriate deadline and should be considered a finally approved version that can be passed on to the top management.
The developers, on the other hand, believe that such a deadline is complete insanity and it is impossible to keep within it; there is a rift in the team and no one can concentrate.
But is this just about developers?
If you look at all these 12 points, you can see that they are, for the most part, relevant to all those involved in projects. Simply in the case of programmers, they are especially critical, since their work requires a deep immersion in the process.
If you notice that some of these points are typical for your company, it would be nice to go through this list together with the team of developers, build a dialogue with them, find out where problems arise and how best to solve them. Whatever they may say, it is extremely important to take this feedback and comments seriously. Over the past thirty in terms of technology, a lot has changed, but the basic principle of teamwork remains the same: speaking about productivity, it is necessary to take into account the human factor. Improve your work processes, environment, team habits and give them the opportunity to tell you how to achieve maximum productivity.
Source: https://habr.com/ru/post/428293/
All Articles