Top 5 annoying moments in the work of the programmer
In the process of working, being a programmer, at different periods I have repeatedly encountered a number of problems. Largely due to the misunderstanding of the programmer’s work by clients and managers. I want to collect the most annoying moments that make work unbearable and spoil all the pleasure, and explanations to novice managers in accessible language, how not to be a burden in the eyes of the developer.
As a rule, they distract from the work with a question, knock them off the stream. They ask to name the date when neither the task nor the requirements is known, only one sentence. And so persistently, that, in order to get off, you call an approximate term.
To the manager: understand that the programmer is building in his head a model of the future system. One sentence cannot simulate the application. And only your fault, if you do not bother to clarify the TK (this is your work, by the way) at the customer, and you want to immediately call him the time (and price). Because the estimate from the ceiling is impossible - sort of how to answer the question "how long will it take to paint a room of unknown area?".
')
According to research, the development time of real systems in most cases is always longer than planned. Largely due to changes in the process of work that no one laid. And then, the term given without TK cannot be considered as a term at all. And pushing for this term, the manager demotivates me as a programmer. When not doing his job and his shoals knocks on me.
To the manager: nothing is more demotivating than the accusation of incompetence and lies. Try to give an exact specification and beat the task into simple pieces, in which the programmer will be happy to help (if you ask well). Then you can more accurately manage the timing.
The work of the programmer can be compared with the work of the artist. The programmer focuses as much as possible on the task, as an artist - on all the details of the object, and holds a very complex picture in mind. According to research , at least 15 minutes is required to return to the state of “flow” when distracted. Therefore, distraction is very annoying - there is an excellent article “Do not wake a programmer” (a useful article for a programmer on a topic is how to work in a stream ). And especially - a distraction to someone else's code that no one likes.
Manager: try to build work so that in the morning to give tasks, and in the evening to take the finished result. During the day, ensure maximum silence for the programmer so as not to distract him. This will work for you - as the work efficiency will be much higher than if you constantly pull. By the way, the free schedule also motivates people - trusting them, you show respect, and people appreciate it.
A slender acyclic ideal dependency graph always breaks with a new “business requirement”. And the more dirty and ugly code, the less I like it, as a programmer. And the less you want to work with him, especially when they do not give to rewrite normally. And over time, the govnod becomes so much that any changes are made by hardcode and hacks. And once the project just rot, and it becomes easier to rewrite from scratch, which causes horror and rabies of managers.
To the manager: working on the code during the constant changes and improvements of the project is somewhat similar to the game “knock back”. A tower of wooden sticks is being built, and the sticks at the base are taken out one by one. The main task is not to overturn the tower. So, when making changes, it takes time for the project not to collapse like a tower, so that its structure is resistant to new changes. Let's take a day to week to refactor, no less, otherwise one day the project will have to be rewritten from scratch, which is usually expensive, impossible and is the result of your fault.
First, I do not like layout. This is a special job, and it should be done by professionals who possess perseverance. In general, I respect the maker-ups - to be able to impose so that everywhere was the same, this skill and very cool. Just hands to this do not lie. But secondly, as a programmer, I am always enraged when the manager climbs into my environment and tries to prove to me that I am wrong, that I should not typeset on divas and typesetter, but on extJS, because he read about this on Habré, understanding only 10% of the words and remembering the name of the JS library.
To a manager: a programmer is a programmer, you don’t need to give him extra work, for example, cut a layout in Photoshop (many, like me, have Linux in general). A good programmer will cope with any task, but he respects himself and will not do the work of others, especially when he is not a professional. Because we value our result, our code, we are responsible for the quality and do not want to get on. Therefore, it is better to hire a specialist, the benefit of many of them.
And second, do not try to be clever in what you do not understand. To control programmers, grow yourself Timlid, whom you will trust, and delegate to him technical issues.
Add in the comments what infuriates you in the work of your managers, and try to make a manual, so that there is where to give a link to RTFM.
Manager: respect the work of their programmers. Remember, the programmer is also a person,% username%.
Upd.: The article describes, in fact, the anti-patterns of interaction between the manager and the programmer. Of course, an adequate manager does not behave this way, and an adequate programmer will sooner or later meet a good manager. I believe in it. :)
1. And how much will this section take (given a single-line TK)?
As a rule, they distract from the work with a question, knock them off the stream. They ask to name the date when neither the task nor the requirements is known, only one sentence. And so persistently, that, in order to get off, you call an approximate term.
To the manager: understand that the programmer is building in his head a model of the future system. One sentence cannot simulate the application. And only your fault, if you do not bother to clarify the TK (this is your work, by the way) at the customer, and you want to immediately call him the time (and price). Because the estimate from the ceiling is impossible - sort of how to answer the question "how long will it take to paint a room of unknown area?".
')
2. You promised to do it in two days, and a week passed! (wash the brain according to the term of paragraph 1)
According to research, the development time of real systems in most cases is always longer than planned. Largely due to changes in the process of work that no one laid. And then, the term given without TK cannot be considered as a term at all. And pushing for this term, the manager demotivates me as a programmer. When not doing his job and his shoals knocks on me.
To the manager: nothing is more demotivating than the accusation of incompetence and lies. Try to give an exact specification and beat the task into simple pieces, in which the programmer will be happy to help (if you ask well). Then you can more accurately manage the timing.
3. Look urgently, here you need to make a sign in an hour! (throws a link to someone else's code)
The work of the programmer can be compared with the work of the artist. The programmer focuses as much as possible on the task, as an artist - on all the details of the object, and holds a very complex picture in mind. According to research , at least 15 minutes is required to return to the state of “flow” when distracted. Therefore, distraction is very annoying - there is an excellent article “Do not wake a programmer” (a useful article for a programmer on a topic is how to work in a stream ). And especially - a distraction to someone else's code that no one likes.
Manager: try to build work so that in the morning to give tasks, and in the evening to take the finished result. During the day, ensure maximum silence for the programmer so as not to distract him. This will work for you - as the work efficiency will be much higher than if you constantly pull. By the way, the free schedule also motivates people - trusting them, you show respect, and people appreciate it.
4. No refactoring, I need it today!
A slender acyclic ideal dependency graph always breaks with a new “business requirement”. And the more dirty and ugly code, the less I like it, as a programmer. And the less you want to work with him, especially when they do not give to rewrite normally. And over time, the govnod becomes so much that any changes are made by hardcode and hacks. And once the project just rot, and it becomes easier to rewrite from scratch, which causes horror and rabies of managers.
To the manager: working on the code during the constant changes and improvements of the project is somewhat similar to the game “knock back”. A tower of wooden sticks is being built, and the sticks at the base are taken out one by one. The main task is not to overturn the tower. So, when making changes, it takes time for the project not to collapse like a tower, so that its structure is resistant to new changes. Let's take a day to week to refactor, no less, otherwise one day the project will have to be rewritten from scratch, which is usually expensive, impossible and is the result of your fault.
5. Make it quick, please, and better on extJS.
First, I do not like layout. This is a special job, and it should be done by professionals who possess perseverance. In general, I respect the maker-ups - to be able to impose so that everywhere was the same, this skill and very cool. Just hands to this do not lie. But secondly, as a programmer, I am always enraged when the manager climbs into my environment and tries to prove to me that I am wrong, that I should not typeset on divas and typesetter, but on extJS, because he read about this on Habré, understanding only 10% of the words and remembering the name of the JS library.
To a manager: a programmer is a programmer, you don’t need to give him extra work, for example, cut a layout in Photoshop (many, like me, have Linux in general). A good programmer will cope with any task, but he respects himself and will not do the work of others, especially when he is not a professional. Because we value our result, our code, we are responsible for the quality and do not want to get on. Therefore, it is better to hire a specialist, the benefit of many of them.
And second, do not try to be clever in what you do not understand. To control programmers, grow yourself Timlid, whom you will trust, and delegate to him technical issues.
At last
Add in the comments what infuriates you in the work of your managers, and try to make a manual, so that there is where to give a link to RTFM.
Manager: respect the work of their programmers. Remember, the programmer is also a person,% username%.
Upd.: The article describes, in fact, the anti-patterns of interaction between the manager and the programmer. Of course, an adequate manager does not behave this way, and an adequate programmer will sooner or later meet a good manager. I believe in it. :)
Source: https://habr.com/ru/post/167451/
All Articles