Five mistakes that I made as lead developer
Lead developer - knowingly "leading". This phrase was heard at one of the conferences on IT-management and caused a question: why is it “not in vain”? It was this question that pushed me to write this article.
Evaluating my experience, I can say that the main characteristics of the lead developer can be reduced to 3 points:
')
In addition to writing code (remains the primary responsibility), the facilitator participates in selecting the team and developing it in the right direction, searching for technical solutions to urgent or upcoming problems, monitoring the security and integrity of the system, and regularly bans insane ideas from managers or other developers.
One of its strongest sides is a holistic picture of the world, in which it is precisely defined what is good and what is bad. This allows you to quickly make decisions and without hesitation to implement them. This confidence is infectious and allows you to gain credibility in the eyes of managers who are not so simple and clear. Indeed, besides technical “better”, “more reliable” and “faster”, all kinds of “customer will not want” appear at the management level, “the investor will not appreciate” and various “Vasya will be offended”. When the manager hears "no, you only need to do this here, because 1, 2 and 3" - he sighs with relief. The choice becomes obvious and responsibility falls from his shoulders.
Just over a year ago, I finally left the position of lead developer and decided to make a small retrospective of my most annoying mistakes. So:
I had a case about three years ago. In addition to my colleagues who received tasks directly from the manager, a developer came to us in one of my projects, and I already set tasks for him. To immerse him in the work, I spent 3 days with him for 14 hours in a row, telling and showing everything, making sure that he understood everything correctly. This brought a result, and then all the tasks were put directly directly with the solution: open such a module, add here and there such a function, connect this library, etc. ... In general, it works and immediately bears fruit, but :
After 9 months, I found myselfpregnant very tired of this mode of work, and the employee never rose to the required level of qualification.
It is more correct to set tasks at a high enough level so that the person himself searches for solutions and carries responsibility for them. To the question “how to do this?” One should always answer “What do you think? Any ideas? ”, Thus stimulating the work of thought in the right direction. The answer can be prompted, but only making sure that the person has already asked this question to himself and has conducted an analysis.
At some point, my manager liked one of the new high-profile technologies (no, not that sensational technology you thought about). Its implementation undermined the integrity of the system, created an unnecessary division of the fronts of work and generally slowed down the development speed forever. For me it was already obvious then, but the beautiful appearance of the demo and the desire to experiment took over the leadership, I was convinced by hook or by crook, and we implemented it. Understanding that this was a mistake came to management somewhere after a year and a half.
I concluded that you should treat your instinct with respect, trust it and protect it.
Deep down you understand why you feel that way. You need to be able to pull this understanding out of yourself, and then formulate arguments from it.
When you spend a huge amount of time with a computer and are passionate about what you are doing, you can generally forget that people are around too. They are not perfect, but everyone has a positive intention regarding what they do. This positive intention is important to see always and in everything. It helps to maintain a benevolent attitude in situations where a person makes a mistake. Constantly heard stories about how seniors without a drop of compassion to pieces carry the results of the efforts of their less experienced colleagues than plunge them into depression and deprive the motivation to work. After analyzing my experience, I realized that sometimes I allowed myself this, albeit without any extreme forms.
Speaking about toxicity, I would like to separately note that, in addition to too harsh criticism, there are other forms that may in one way or another negatively affect the desire to work with you. By itself, toxicity is very contagious and you can easily pick it up from your colleagues, so at some point I decided to practice the principle of “do not let evil go farther than yourself” (identify and suppress first of all in yourself) and made a list of manifestations that can be considered toxic (based on the TED report on the “7 deadly sins of communication” ):
Your manager has colleagues on the same level with him and above. They can be friends or foes. They cannot always like your legitimate influence on the decisions of a manager, and the decisions themselves do not always go along with their interests. When you are a programmer, you don’t pay any attention to it at all and don’t even think about it. As a rule, your supervisor will encapsulate you from these things as long as possible. At some point, you may find that people gracefully tingle you with the most unexpected and unobvious things, which are, at first glance, not at all related to your work. In general, you can live with this, but if your opponent is sophisticated, then you may very soon want to move to another office, work more from home or change jobs altogether.
You can avoid such situations if you consider in advance who else is interested in the project that you are implementing, what level of influence on this project, what goals are facing the interested party, what fears and hopes may arise in the process of work. Fears need to dispel, you can not leave them grow. Hope is necessary to justify. In general, the strategy is determined as follows:
This is common to all in one way or another, and your leader probably knows about it. However, sometimes he may underestimate the volume of work ahead and the speed of its implementation. It sounds banal, but it was precisely this that was repeatedly the reason why my manager was disappointed and I along with him. It is easy to recall several situations when I answered that we could do it in half a day, and then sat over the task all week together with the weekend. During this time, the task could lose relevance, or other, more important tasks could be done. I was greatly helped by the habit of not giving a rating right away. If the question is not hypothetical, but specific, then it is worth taking some time to build an assessment and it is desirable to take into account possible risks. After becoming acquainted with the assessment by three points, it became much easier for me to make a reasoned conclusion about the time required and, most importantly, the assessment itself became much more approximate to reality.
Summing up, I can say that the lead developer, willy-nilly, faces the horizon of a rather aggressive and unknown for him management environment. This place is becoming a new growth point, since the technical side of the work does not cause so many questions: infrastructure investments are made regularly, technical debt is extinguished in a timely manner, the architecture is developed harmoniously and competently. However, to effectively carry out your work (and sometimes just to “survive”), you need to quickly understand the basics of project and team management, analyze the main problems of your predecessors in similar positions, and try to avoid them or solve them in advance.
Evaluating my experience, I can say that the main characteristics of the lead developer can be reduced to 3 points:
')
- He thinks not only about his garden, but also about the whole garden (this is a key quality). Ready to build standards and monitor their implementation.
- He knows his language and framework perfectly, is well versed in architecture, has solid experience behind his shoulders. “Solidity” does not necessarily mean the time spent behind the keyboard, the quantity and quality of the written projects is important.
- He wants and can reasonably convey his opinion, defend it and seek a compromise if necessary.
In addition to writing code (remains the primary responsibility), the facilitator participates in selecting the team and developing it in the right direction, searching for technical solutions to urgent or upcoming problems, monitoring the security and integrity of the system, and regularly bans insane ideas from managers or other developers.
One of its strongest sides is a holistic picture of the world, in which it is precisely defined what is good and what is bad. This allows you to quickly make decisions and without hesitation to implement them. This confidence is infectious and allows you to gain credibility in the eyes of managers who are not so simple and clear. Indeed, besides technical “better”, “more reliable” and “faster”, all kinds of “customer will not want” appear at the management level, “the investor will not appreciate” and various “Vasya will be offended”. When the manager hears "no, you only need to do this here, because 1, 2 and 3" - he sighs with relief. The choice becomes obvious and responsibility falls from his shoulders.
Just over a year ago, I finally left the position of lead developer and decided to make a small retrospective of my most annoying mistakes. So:
Error number 1. Overmanagement
I had a case about three years ago. In addition to my colleagues who received tasks directly from the manager, a developer came to us in one of my projects, and I already set tasks for him. To immerse him in the work, I spent 3 days with him for 14 hours in a row, telling and showing everything, making sure that he understood everything correctly. This brought a result, and then all the tasks were put directly directly with the solution: open such a module, add here and there such a function, connect this library, etc. ... In general, it works and immediately bears fruit, but :
- It takes a lot of time to the detriment of your own tasks.
- Removes responsibility for the result from the employee. You said exactly what to do, which means that if it didn’t work, he will gladly inform you about it, they say, look for another solution.
- Wean employee to think and prevent him from developing
After 9 months, I found myself
It is more correct to set tasks at a high enough level so that the person himself searches for solutions and carries responsibility for them. To the question “how to do this?” One should always answer “What do you think? Any ideas? ”, Thus stimulating the work of thought in the right direction. The answer can be prompted, but only making sure that the person has already asked this question to himself and has conducted an analysis.
Error number 2. Concessions to the manager in the technical solution
At some point, my manager liked one of the new high-profile technologies (no, not that sensational technology you thought about). Its implementation undermined the integrity of the system, created an unnecessary division of the fronts of work and generally slowed down the development speed forever. For me it was already obvious then, but the beautiful appearance of the demo and the desire to experiment took over the leadership, I was convinced by hook or by crook, and we implemented it. Understanding that this was a mistake came to management somewhere after a year and a half.
I concluded that you should treat your instinct with respect, trust it and protect it.
Deep down you understand why you feel that way. You need to be able to pull this understanding out of yourself, and then formulate arguments from it.
Mistake number 3. Lack of empathy and toxicity
When you spend a huge amount of time with a computer and are passionate about what you are doing, you can generally forget that people are around too. They are not perfect, but everyone has a positive intention regarding what they do. This positive intention is important to see always and in everything. It helps to maintain a benevolent attitude in situations where a person makes a mistake. Constantly heard stories about how seniors without a drop of compassion to pieces carry the results of the efforts of their less experienced colleagues than plunge them into depression and deprive the motivation to work. After analyzing my experience, I realized that sometimes I allowed myself this, albeit without any extreme forms.
Speaking about toxicity, I would like to separately note that, in addition to too harsh criticism, there are other forms that may in one way or another negatively affect the desire to work with you. By itself, toxicity is very contagious and you can easily pick it up from your colleagues, so at some point I decided to practice the principle of “do not let evil go farther than yourself” (identify and suppress first of all in yourself) and made a list of manifestations that can be considered toxic (based on the TED report on the “7 deadly sins of communication” ):
- Gossip. Everyone wants to gossip a little sometimes, but on a large scale gossipers are disgusting
- Condemnation It is difficult to communicate with the person who condemns you. Especially if it is known that he will condemn in advance any act.
- Negativity. There are people who are not happy with anything at all and never.
- Nagging. Life complaints are permissible only in homeopathic quantities.
- Excuses. Discarding guilt, disclaimer.
- Embellishment. Constant exaggerations to which many people are inclined when they talk about projects, their experience, their knowledge. Any exaggerations over time tend to merge into a complete lie.
- Dogmatism. When the speaker does not share, where is a proven fact, and where his subjective opinion, and pours you a continuous stream, giving it entirely for the proven truth. The exact opposite of scientific debate.
Error number 4. Ignoring interested parties
Your manager has colleagues on the same level with him and above. They can be friends or foes. They cannot always like your legitimate influence on the decisions of a manager, and the decisions themselves do not always go along with their interests. When you are a programmer, you don’t pay any attention to it at all and don’t even think about it. As a rule, your supervisor will encapsulate you from these things as long as possible. At some point, you may find that people gracefully tingle you with the most unexpected and unobvious things, which are, at first glance, not at all related to your work. In general, you can live with this, but if your opponent is sophisticated, then you may very soon want to move to another office, work more from home or change jobs altogether.
You can avoid such situations if you consider in advance who else is interested in the project that you are implementing, what level of influence on this project, what goals are facing the interested party, what fears and hopes may arise in the process of work. Fears need to dispel, you can not leave them grow. Hope is necessary to justify. In general, the strategy is determined as follows:
- Low influence and low interest: you can allow yourself to do nothing
- Low impact and high interest: you need to be informed about changes, plans, etc.
- High impact and low interest: similar
- High influence and high interest: you need to work closely, even if you are in different departments and / or at different levels.
Error number 5. Revaluation of their capabilities
This is common to all in one way or another, and your leader probably knows about it. However, sometimes he may underestimate the volume of work ahead and the speed of its implementation. It sounds banal, but it was precisely this that was repeatedly the reason why my manager was disappointed and I along with him. It is easy to recall several situations when I answered that we could do it in half a day, and then sat over the task all week together with the weekend. During this time, the task could lose relevance, or other, more important tasks could be done. I was greatly helped by the habit of not giving a rating right away. If the question is not hypothetical, but specific, then it is worth taking some time to build an assessment and it is desirable to take into account possible risks. After becoming acquainted with the assessment by three points, it became much easier for me to make a reasoned conclusion about the time required and, most importantly, the assessment itself became much more approximate to reality.
Summary
Summing up, I can say that the lead developer, willy-nilly, faces the horizon of a rather aggressive and unknown for him management environment. This place is becoming a new growth point, since the technical side of the work does not cause so many questions: infrastructure investments are made regularly, technical debt is extinguished in a timely manner, the architecture is developed harmoniously and competently. However, to effectively carry out your work (and sometimes just to “survive”), you need to quickly understand the basics of project and team management, analyze the main problems of your predecessors in similar positions, and try to avoid them or solve them in advance.
Source: https://habr.com/ru/post/454306/
All Articles