October 31, 2018 at 07:4612 factors that prevent programmers from working
- Transfer
No one will require the developer to write code without access to a computer, but many companies believe that he must somehow work without the ability to fully utilize his mental capabilities. And this is about as unrealistic.
And so let's go through a list of twelve things that prevent developers from entering a stream state and delivering maximum productivity. I will try to move from the most key things to the less significant. Suggest your options and comments!
If someone doubts whether it is worth spending money and effort on this, it is enough to remember how much the programmers are paid. Even a 10% increase in productivity is a lot in cash!
In my opinion, distracting the developer is the surest way to kill his productivity in the bud. He cannot simply take and continue from the place where he was interrupted. First he needs to get involved in the process again, and then go through the whole chain of thoughts until 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 this list can be continued.
Well, what about the meeting? Their only difference from other distractions is that they are planned in advance. And that only makes the situation worse. It is difficult for a programmer to advance in solving a problem if he expects an interruption 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 of the engineering tasks take more time.
As Paul Graham said: “One meeting can kill half a day: time is divided into two periods, for which you can’t do anything serious.”
How to avoid this state of affairs? Everything has been painted on this for a long time, so there are no excuses. You just need to put the planers at the very beginning of the day or, say, just before dinner, so that you do not need to distract people from work without need.
Of all the varieties of managers, those who intervene for any reason, perhaps the worst impact on employee productivity. Of course, this is also affected by the fact that this particular type is especially inclined to organize a bunch of meetings and demand the attention of developers for unforeseen reasons. 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 call into question their professional skills. Even if the programmer still has some motivation to work despite endless interruptions, such an attitude will completely discourage her. The consequences are not limited to one drop in performance. Intrusive managers especially often force employees to leave the company, or at least the team.
Lack of clarity can be illustrated by many different examples. For example, a bug report in the spirit of “It doesn’t work, fix it!” Obviously does not give developers all the information they need to work. By the way, in this particular case, the introduction of a template for bug reports may help.
Or another case: vague requirements for some part of the product. With such introductory developers simply begin to do as they themselves imagine it, and then a manager comes with a more detailed description of the expected user behavior, and they all have to start all over again.
Indistinctly set priorities belong to the same category. Programmers spend a lot of time racking their brains on what they should start with, although avoiding this would be very simple. Well, if they ever have to report to the manager why they are engaged in this and not this (despite the fact that no one stipulated the order), you can be sure that this will make them great.
Ever heard of this? There are managers who do not participate in the workflow at all ... except for those moments when they suddenly decide to dive at someone and make a mistake. “This is no good, and this too, but it does not look at all,” and flew on. I must admit, 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 then have to work out a working mood for hours, and someone drops out of the stream for whole days.
Has it ever happened to you that one of the managers or other programmers attributed to himself what you struggled for several weeks? Developers put their professionalism above all else. To steal other people's merits is like 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, which can for a long time “drop” the performance of the entire team.
It may seem strange to people from other professions, but for programmers, the environment decides a lot in the course of work. Say the white noise — the buzz of the air conditioner, the buzz of cars and trucks from the street — helps them focus better. That is why many of us work with 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 the person, then this will have the opposite effect. And if, in addition, monitors are installed in such a way that managers constantly see what is on the screen, this creates unnecessary stress and unnecessary reasons to distract developers from 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 were not monitored in the process.
Due to the displacement of borders, relatively simple queries grow into confused monsters that eat up a lot of time! And in most cases this begins when the product is already in development.
Take for example a simple function:
It may seem incomprehensible at first glance, but in fact, everything is simple. If the people in charge of the product prioritize without testing their hypotheses (through feedback or in any other way) about the audience’s interest in certain opportunities, and the developers see that these opportunities are simply not being 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 are leaving some mark on the world, and this is especially important for developers!
Technical duty is a conscious decision to allow certain stretch in choosing solutions and writing code in order to roll out the product faster. A certain amount of technical debt arises in any project inevitably and can help with deadlines over short distances. However, in the long run, it increases the complexity of the system and thereby slows down developers. People far from programming often underestimate the impact of these processes on productivity and require moving forward non-stop - in this situation problems begin to arise. If refactoring always remains outside the priority list, not only the productivity of employees, but also the quality of the product will suffer.
Developers daily use many tools for writing, pushing and merging code. The more they manage to automate processes, the better. It goes without saying that ancient tools will have a direct impact on performance. It also decides a lot of what the work is being done on - on one laptop or also on an additional screen. If we compare iron prices with the salaries of programmers, then even a 5% increase in productivity will definitely pay off all the costs! You just need to provide the team with the equipment and tools that they prefer to use (for equipment, the solution should be individual, for tools - collective).
In the process of teaching programming, we all learned that you need to start adding comments to the code as soon as possible and as often as possible. The idea was that it would be better if there were too many comments than not enough. Unfortunately, many people misunderstood this and decided that every line needed explanation. That's why we have samples like this one, from Jeff Atwood's article “Code without comment”: Do you understand that this code does in general? So I didn’t understand anything. The problem is that a lot is said here about how everything works, but not a word about why this is needed. If we assume that a bug occurred in the program and you found such a code fragment under the hood, it would not have helped you figure out the situation.
The last point is tied to the tendency of managers to ask developers to roughly estimate how much time they will need, then press on them to underestimate this estimate, and then magically equate the final date with the deadline! At the same time, managers even believe that since the developers “set the deadlines themselves”, it means they signed up for the corresponding deadline and it should be considered a finally approved option that can be transferred to senior management.
The developers believe that such a deadline is complete madness and it is impossible to keep within it; There is discord in the team and no one can concentrate.
If you look at all these 12 points, you will notice that they are, for the most part, relevant for everyone involved in projects. It's just that 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 the points mentioned are typical for your company, it would be nice to go along this list with the team of developers, build a dialogue with them, find out where the problems arise and how best to solve them. Whatever they say, it is extremely important to take this feedback and comments seriously. Over the past thirty, a lot has changed in terms of technology, but the basic principle of teamwork remains the same: when discussing performance, 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 a list of twelve things that prevent developers from entering a stream state and delivering maximum productivity. I will try to move from the most key things to the less significant. Suggest your options and comments!
If someone doubts whether it is worth spending money and effort on this, it is enough to remember how much the programmers are paid. Even a 10% increase in productivity is a lot in cash!
1) Meetings and other distractions
In my opinion, distracting the developer is the surest way to kill his productivity in the bud. He cannot simply take and continue from the place where he was interrupted. First he needs to get involved in the process again, and then go through the whole chain of thoughts until 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 this list can be continued.
“The more often I get distracted when I try to start a task, the more time begins to elapse between attempts. If I’ve been pulled all morning, there’s nothing to be surprised that the day turned out to be unproductive ”- Anonymous developer with Reddit
Well, what about the meeting? Their only difference from other distractions is that they are planned in advance. And that only makes the situation worse. It is difficult for a programmer to advance in solving a problem if he expects an interruption 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 of the engineering tasks take more time.
As Paul Graham said: “One meeting can kill half a day: time is divided into two periods, for which you can’t do anything serious.”
How to avoid this state of affairs? Everything has been painted on this for a long time, so there are no excuses. You just need to put the planers at the very beginning of the day or, say, just before dinner, so that you do not need to distract people from work without need.
2) nitpicking
Of all the varieties of managers, those who intervene for any reason, perhaps the worst impact on employee productivity. Of course, this is also affected by the fact that this particular type is especially inclined to organize a bunch of meetings and demand the attention of developers for unforeseen reasons. 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 call into question their professional skills. Even if the programmer still has some motivation to work despite endless interruptions, such an attitude will completely discourage her. The consequences are not limited to one drop in performance. Intrusive managers especially often force employees to leave the company, or at least the team.
3) Unclear
Lack of clarity can be illustrated by many different examples. For example, a bug report in the spirit of “It doesn’t work, fix it!” Obviously does not give developers all the information they need to work. By the way, in this particular case, the introduction of a template for bug reports may help.
Or another case: vague requirements for some part of the product. With such introductory developers simply begin to do as they themselves imagine it, and then a manager comes with a more detailed description of the expected user behavior, and they all have to start all over again.
Indistinctly set priorities belong to the same category. Programmers spend a lot of time racking their brains on what they should start with, although avoiding this would be very simple. Well, if they ever have to report to the manager why they are engaged in this and not this (despite the fact that no one stipulated the order), you can be sure that this will make them great.
4) Seagull managers
Ever heard of this? There are managers who do not participate in the workflow at all ... except for those moments when they suddenly decide to dive at someone and make a mistake. “This is no good, and this too, but it does not look at all,” and flew on. I must admit, 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 then have to work out a working mood for hours, and someone drops out of the stream for whole days.
5) Theft of Laurels
Has it ever happened to you that one of the managers or other programmers attributed to himself what you struggled for several weeks? Developers put their professionalism above all else. To steal other people's merits is like 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, which can for a long time “drop” the performance of the entire team.
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 the white noise — the buzz of the air conditioner, the buzz of cars and trucks from the street — helps them focus better. That is why many of us work with 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 the person, then this will have the opposite effect. And if, in addition, monitors are installed in such a way that managers constantly see what is on the screen, this creates unnecessary stress and unnecessary reasons to distract developers from business.
7) Offset 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 were not monitored in the process.
Due to the displacement of borders, relatively simple queries grow into confused monsters that eat up a lot of time! And in most cases this begins when the product is already in development.
Take for example a simple function:
- 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"
- Third version (when the second iteration is almost finished): the description changes to “Display a 3D location map on which the user could move”
8) Product Feature Determination Process
It may seem incomprehensible at first glance, but in fact, everything is simple. If the people in charge of the product prioritize without testing their hypotheses (through feedback or in any other way) about the audience’s interest in certain opportunities, and the developers see that these opportunities are simply not being 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 are leaving some mark on the world, and this is especially important for developers!
9) Ignoring technical debt
Technical duty is a conscious decision to allow certain stretch in choosing solutions and writing code in order to roll out the product faster. A certain amount of technical debt arises in any project inevitably and can help with deadlines over short distances. However, in the long run, it increases the complexity of the system and thereby slows down developers. People far from programming often underestimate the impact of these processes on productivity and require moving forward non-stop - in this situation problems begin to arise. If refactoring always remains outside the priority list, not only the productivity of employees, but also the quality of the product will suffer.
10) A variety of tools and equipment
Developers daily use many tools for writing, pushing and merging code. The more they manage to automate processes, the better. It goes without saying that ancient tools will have a direct impact on performance. It also decides a lot of what the work is being done on - on one laptop or also on an additional screen. If we compare iron prices with the salaries of programmers, then even a 5% increase in productivity will definitely pay off all the costs! You just need to provide the team with the equipment and tools that they prefer to use (for equipment, the solution should be individual, for tools - collective).
11) How-to documentation
In the process of teaching programming, we all learned that you need to start adding comments to the code as soon as possible and as often as possible. The idea was that it would be better if there were too many comments than not enough. Unfortunately, many people misunderstood this and decided that every line needed explanation. That's why we have samples like this one, from Jeff Atwood's article “Code without comment”: Do you understand that this code does in general? So I didn’t understand anything. The problem is that a lot is said here about how everything works, but not a word about why this is needed. If we assume that a bug occurred in the program and you found such a code fragment under the hood, it would not have helped you figure out the situation.
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)
}12) Extremely tight deadlines
The last point is tied to the tendency of managers to ask developers to roughly estimate how much time they will need, then press on them to underestimate this estimate, and then magically equate the final date with the deadline! At the same time, managers even believe that since the developers “set the deadlines themselves”, it means they signed up for the corresponding deadline and it should be considered a finally approved option that can be transferred to senior management.
The developers believe that such a deadline is complete madness and it is impossible to keep within it; There is discord in the team and no one can concentrate.
But is it only about developers?
If you look at all these 12 points, you will notice that they are, for the most part, relevant for everyone involved in projects. It's just that 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 the points mentioned are typical for your company, it would be nice to go along this list with the team of developers, build a dialogue with them, find out where the problems arise and how best to solve them. Whatever they say, it is extremely important to take this feedback and comments seriously. Over the past thirty, a lot has changed in terms of technology, but the basic principle of teamwork remains the same: when discussing performance, 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.