Five mistakes that I made as a lead developer

The lead developer is not in vain the "lead." This phrase was heard at a conference on IT management and raised a question, why, in fact, "not in vain"? It was this question that prompted me to write this article.

image

Assessing my experience, I can say that the main characteristics of a leading 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 own language and framework perfectly, is well versed in architecture, has a solid background of work behind him. “Solidity” does not necessarily mean time spent at the keyboard; the quantity and quality of written projects is important.
  • He wants and can reasonably convey his opinion, uphold it and seek a compromise if necessary.

In addition to writing code (remains the main responsibility), the facilitator participates in the selection of the team and its development in the right direction, the search for technical solutions to painful or impending problems, monitors the security and integrity of the system, and regularly banishes crazy ideas from managers or other developers.

One of its strengths is a holistic picture of the world, in which it is precisely determined what is good and what is bad. This allows you to quickly make decisions and without hesitation bring them to life. This confidence is contagious and allows you to gain credibility in the eyes of managers who are no longer so simple and clear. Indeed, besides the technical ones, “better”, “more reliable” and “faster”, at the management level there are all kinds of “the customer will not want”, “the investor will not appreciate” and all kinds of “Vasya will be offended”. When the manager hears "no, here it is only necessary to do this, because 1, 2 and 3" - he sighs with relief. The choice becomes obvious and responsibility falls from his shoulders.

A little over a year ago, I finally left the position of the leading developer and decided to make a small retrospective of my most annoying mistakes. So:

Mistake number 1. Overmanagement


I had a case about three years ago. In addition to my colleagues who received tasks directly from the manager, the developer came to us in one of my projects, and I already set the tasks for him. To immerse him in 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 yielded results, and then all the tasks were set directly with the solution: open such a module, add this and that function there, connect this library, etc. ... In general, it works and immediately bears fruit, but :

  • Time consuming to the detriment of your own tasks.
  • Removes responsibility for the result from the employee. You said what exactly to do, which means if it didn’t work, then he will happily inform you of this, saying that you are looking for another solution.
  • Weaning an employee from thinking and preventing him from developing

After 9 months, I found myself pregnant very tired of this mode of work, and the employee did not rise to the required level of qualification.

It is more correct to set tasks at a sufficiently high level so that the person himself will seek solutions and bear responsibility for them. To the question “how to do this?” One always needs to 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 himself has already asked this question and conducted an analysis.

Error number 2. Concessions to the head in the technical solution


At some point, my manager liked one of the new sensational technologies (no, not the sensational technology that 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, this was obvious even then, but the beautiful appearance of the demo and the desire to experiment took the upper hand over the leadership, convinced me by hook or by crook, and we implemented it. The understanding that this was a mistake reached the leadership somewhere after a year and a half.

I concluded that you need to respect your instincts, trust him and protect him.
Deep down, you understand why you feel this way. One must be able to pull this understanding out of oneself, and then formulate arguments from it.

Mistake number 3. Lack of empathy and toxicity


When you spend a huge amount of time with the computer and are passionate about what you are doing, you can generally forget that there are people around too. They are not perfect, but everyone has a positive intention about what they are doing. It is important to see this positive intention always and in everything. This helps to maintain a benevolent attitude in situations where a person makes a mistake. Stories are constantly heard about how seniors, without a drop of compassion, shatter the results of the efforts of their less experienced colleagues, than plunge them into despondency and deprive them of motivation to work. After analyzing my experience, I realized that I myself sometimes allowed this to myself, albeit without some extreme forms.

Speaking of toxicity, I would like to note separately that in addition to too harsh criticism, there are other forms that can, to one degree or another, negatively affect the desire to work with you. Toxicity itself is very contagious and you can easily pick it up from my colleagues, so at some point I decided to profess the principle of “do not let evil go beyond yourself” (identify and suppress it first of all in yourself) and compiled a list of manifestations that you can consider toxicity (based on the report on TED “7 deadly sins of communication” ):

  • Gossip. Everyone wants to gossip a little sometimes, but on a large scale, the gossips are disgusting
  • Conviction. It’s hard to communicate with someone who blames you. Especially if it is known that he will condemn any action in advance.
  • Negativity There are people who are not happy at all with anything and never.
  • Nagging. Complaints about life are permissible only in homeopathic quantities.
  • Excuses. Transfer of guilt, disclaimer.
  • Embellishment. The constant exaggeration that many people are prone to when they talk about projects, their experience, their knowledge. Any exaggeration over time tends to merge into continuous lies.
  • Dogmatism. When the speaker does not share where the verified fact is, and where is his subjective opinion, and floods you with a continuous stream, passing him off entirely as a proven truth. The exact opposite of scientific discussion.

Mistake number 4. Ignoring stakeholders


Your leader has colleagues at the same level with him and above. They can be friends or foes. They may not always like your legal influence on the decisions of the leader, 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. Typically, your supervisor will encapsulate you from these things as long as possible. At some point, you may find that you are gracefully tingled with the most unexpected and unobvious things by people who, who at first glance have nothing to do with your work. In general, you can live with this, but if the opponent is sophisticated, then it is quite possible that you will very soon want to move to another office, work more from home or even change jobs.
You can avoid such situations if you take into account in advance who else is interested in the project that you are implementing, what level of influence on this project, what goals the stakeholder faces, what fears and hopes may arise during the work. Fears must be dispelled; one cannot leave them to grow. Hopes need to be justified. In general, a strategy is defined in the following way:

  • Low impact and low interest: you can afford to do nothing
  • Low impact and high interest: you need to be informed of changes, plans, etc.
  • High impact and low interest: similar
  • High influence and high interest: you need to work hard, even if you are in different departments and / or at different levels.

Mistake number 5. Overestimating your capabilities


This is common to everyone in one way or another, and your manager most likely knows about it. However, sometimes he can also underestimate the amount of work ahead and the speed of its implementation. This sounds corny, but that was repeatedly the reason why my manager was disappointed and I along with him. One can easily recall several situations where I replied that we can do this in half a day, and then sat on a task all week along with the weekend. During this time, the task could lose relevance, or other, more important tasks could be done. The habit of not giving an assessment right away helped me a lot. If the question is not hypothetical, but specific, then it is worth taking some time to build the assessment and it is advisable to take into account possible risks. After exploring the three-point rating It has become much easier for me to draw a reasoned conclusion about the necessary time spent and, most importantly, the assessment itself has become much closer to reality.

Summary


Summing up, I can say that the lead developer willfully faces the horizon of a rather aggressive and unknown management environment. This place is becoming a new growth point, since the technical side of the work raises not so many questions: investments in infrastructure are made regularly, technical debt is repaid in a timely manner, the architecture is developing harmoniously and competently. However, for the effective implementation of their work (and sometimes just to “survive”), it is necessary to quickly understand the basics of project and team management, analyze the main problems of their predecessors in similar positions, and try to avoid them or solve them in advance.

Also popular now: