12 factors that make it difficult for programmers to work

 
3r3-31. No one will demand from the developer that he write the code without access to the computer, but many companies believe that it should somehow work without the ability to fully use their thinking capabilities. And this is about as unreal. 3r3197.  
3r3197.  
3r3144. 12 factors that make it difficult for programmers to work 3r3197.  
3r3197.  
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! 3r3197.  
3r3197.  
If someone doubts whether it is worth spending money and effort on it, it is enough to remember how much programmers are paid. Even a performance gain of 10% is a lot of money! 3r3197.  
3r3197.  
3r3191. 1) Meetings and other distractions 3r3192. 3r3197.  
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. 3r3197.  
3r3197.  
3r3331. “The more often I get distracted when I try to start a task, the more time begins to pass between attempts. If I'm jerking all morning, it's no wonder that the day turned out to be unproductive. ”- Anonymous developer with Reddit
3r3197.  
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 is expecting 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. 3r3197.  
3r3197.  
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”. 3r3197.  
3r3197.  
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 gauging at the very beginning of the day or, say, right before lunch, so as not to unnecessarily distract people from work. 3r3197.  
3r3197.  
3r3191. 2) Carping to trivia
3r3197.  
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, such an 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. 3r3197.  
3r3197.  
3r3191. 3) The obscurity 3r3192. 3r3197.  
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. 3r3197.  
3r3197.  
Or another case: vague requirements for some part of the product. With such introductory developers, they simply begin to do what they themselves all imagine, and then the manager comes in with a more detailed description of the expected user behavior, and they have to start all over again. 3r3197.  
3r3197.  
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 that, and not this (despite the fact that no-one has negotiated the order), you can be sure that they will be fine with it. 3r3197.  
3r3197.  
3r3144. 3r3197.  
3r3197.  
3r3191. 4) Gull Managers
3r3197.  
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 cheat everything. “This is no good, and this too, and it does not look at all,” - and flew on. I have to 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 people have to work out the working mood for hours after that, and someone falls out of the flow for whole days. 3r3197.  
3r3197.  
3r3191. 5) Theft of laurels 3r3r2192. 3r3197.  
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. 3r3197.  
3r3197.  
3r3191. 6) Furnishings: noise, movement, design of the workspace
3r3197.  
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! 3r3197.  
3r3197.  
At the same time, 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 in such a way that managers constantly see what is on the screen, this creates both unnecessary stress and unnecessary reasons to distract developers from the business. 3r3197.  
3r3197.  
3r3191. 7) Offset project boundaries
3r3197.  
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. 3r3197.  
3r3197.  
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 starts when the product is already in development. 3r3197.  
3r3197.  
Take for example a simple function:
 
3r3197.  
3r3122.  
3r33130. First version (before implementation): the function is defined as “Display location map” 3r3131.  
3r33130. The second version (when the first iteration is almost finished): the description changes to “Display a 3D location map” 3r3131.  
3r33130. The third version (when the second iteration is almost finished): the description changes to “Display a 3D location map that the user could navigate” 3r3131.  
3r3197.  
3r3191. 8) The process of determining the capabilities of the product 3r3192. 3r3197.  
This may seem confusing at first glance, but in fact, everything is simple. If the people responsible for the product line up priorities 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 the motivation will collapse. We all want to feel that we leave some mark on the world, and this is especially important for developers! 3r3197.  
3r3197.  
3r3144. 3r3145.
3r3197.  
3r3197.  
3r3191. 9) Ignoring technical debt
3r3197.  
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 always remains out of the list of priorities, not only the productivity of employees, but also the quality of the product will suffer. 3r3197.  
3r3197.  
3r3191. 10) A variety of tools and equipment 3r3192. 3r3197.  
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 price 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). 3r3197.  
3r3197.  
3r3191. 11) Documentation in the style of "how" 3r3192. 3r3197.  
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 specimens like this here, from the article by Jeff Atwood:
 
3r3197.  
Did you understand that this code is generally doing? 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 found such a code fragment under the hood, it would not help you to understand the situation. 3r3197.  
3r3197.  
3r3191. 12) Extremely short deadlines
3r3197.  
The last point is tied to the tendencies of managers to ask developers to estimate how much time they need, then press 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 that they have subscribed to the appropriate deadline and it should be considered a finally approved version that can be passed to the top management. 3r3197.  
3r3197.  
The developers, on the other hand, believe that such a deadline is complete insanity and it is impossible to meet it; there is a rift in the team and no one can concentrate. 3r3197.  
3r3197.  
3r3191. But is this only about developers? 3r3192. 3r3197.  
If you look at all these 12 points, you will notice that they are, for the most part, relevant to all those involved in the projects. Simply in the case of programmers, they are especially critical, since their work requires a deep immersion in the process. 3r3197.  
3r3197.  
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 imperative that you 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 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.
3r3202. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () ();
+ 0 -

Add comment