Curves of the development of the programmer and a little about the effect of Dunning - Kruger
There are two main ways of becoming a top management in IT companies:
- Managerial - when the project manager begins to manage other managers.
- Technarsky - when a developer begins to manage other developers and the number of personnel managed by him increases.
The first way is more natural, since it implies the development of the basic qualities of a manager as he grows up. In fact, the manager remains the manager, only becomes a higher-level specialist.
The second path is longer and does not guarantee success, since it is contrary to the essence of the introvert programmer. However, in this way I would like to focus attention and share experience and knowledge.
- All names are fictional.
- The narrative relates more to customized development.
- Skills, and especially soft skills, are difficult to assess formally, all the graphs in this article are conditional and reflect my personal opinion
Beginning of the programmer's path
So, we are at the very beginning of the programmer's path.
Meet Nicholas (name changed). Nikolay is a young programmer, he studies well at the university and has already tried to write simple websites. He got a job in the studio for the post of a june-frontender, he was put on a project that has already been written for two years using the modern framework Angular 1.5. Kohl's boy did not work with him, but he saw a familiar dollar sign, and he had already managed to write a couple of plug-ins for jQuery. This fact encouraged Nicholas, but then the older comrades told him that it wasn’t jQuery at all, and, in general, we need to write a directive here, but here we need to make two filters. Nikolai is depressed, but he is determined to join this project.
And now a year has flown by, Nikolai masterfully writes directives and not a day goes by without a new module. Kohl on horseback, he is optimistic about the fact that half a year ago, a young joon was assigned to the project for him, and he doesn’t even know what the directive is. Puppy! Nikolai made friends with his older comrades, and only a 30-year-old old man in the corner is always dissatisfied with something.
Actually, on the graphs we see the technical skills for the project and all the skills of Nicholas that he has. Since this is his first project, in fact this is all that Nikolai knows. After some time, he goes to the authorities and asks for two bags of money - after all, he skillfully creates directives on the project, and in general, he found that he leaves twice more comments in MR than the 30-year-old man. Obviously, he is better than his team leader. It receives a quite reasonable refusal and begins to look for a new job, perhaps thinking about switching to another project or another team. In any case, he is faced with a situation where the knowledge he has just acquired becomes irrelevant and he needs to study further.
This - the first crisis of Nicholas "The effect of the first project."
At the new place, Nikolai is given a project on Angulyar 5, well, he masterfully writes directives! But there he sees some game! What other typeScript? What are RxJs and streams? The older comrades laugh at him, and the 30-year-old old man throws unkind glances. I saw a huge number of such stars and a lot of stargazing, when the developer realized that it turns out that he still does not know anything! And the sooner this happens, the better. This is called the Dunning-Kruger Effect — a metacognitive distortion, which is that people with a low level of qualification make erroneous conclusions, make unsuccessful decisions and are unable to realize their mistakes due to the low level of their qualifications.
June, who changed 3-4 projects per year, is much more preferable for an employer than June, who has been sitting alone on one project for a year, because he:
- Objectively evaluates your knowledge and skills.
- Constantly evolving
- Communicates more in a team
- He understands the price of a mistake more because he has seen more deadlines and releases.
To colleagues who have appeared at this stage, I would like to wish the following:
- Cheer up with failures
- Constantly study and learn new libraries and technologies
- Not star
Junior → Middle → Senior
Well, it took another couple of years and what do we see?
Nikolai has already mastered several frameworks and realized that frameworks are only a tool for solving specific problems. He accepted the fact that he does not know everything, but at the same time he tries to develop all the time. At some point he comes up to a young 33-year-old timlid and says: listen, Petya (the name is changed), several junas have come to us, they know nothing and are slowly doing tasks on the project. Let me give them a few lectures or workshops so that they more quickly join our work. And at this very moment Nikolai goes to the next level.
Now there is a division on Junior, Middle, Senior. Middle thinks that in order to become a Signor, he needs to master a new programming language and tighten up the hardware. This is not quite true. At the dawn of domestic development, there was a position similar to Signor, it was called Lead Programmer - such a specialist not only knows a lot, but also leads projects or a team. Without the appropriate software skills, Signor will not become.
Nikolay learned to find approaches to all team members, he is constantly developing and developing the rest. He has already seen the “star-stars of the first project”, but he is much more comfortable working with the same professionals as himself. After all, they understand that the success of the project is the success of everyone, and the puncture of one team member ultimately affects all of its participants.
At this stage, there are two possible ways: to be a simple performer, not to strain and solve the tasks; the second is to develop in the direction of the lead programmer, to take responsibility and initiative.
At this stage of the programmer’s development, the team and management value its qualities:
- A responsibility
Where to develop?
- In-depth understanding of the technologies that he uses
- Expansion of outlook
- Take responsibility for projects and people
Moreover, the skills from the last point must be pumped, if he wants to develop along the curve to the head. If he is not interested, then you can concentrate on the skills of a technical specialist.
At some point, Nikolai is horrified to realize that no one else is writing to JS, and most of his knowledge is not needed by anyone. That's how the technology crisis comes. I found such a crisis with desktop applications. A little later, just the maker-ups became useless to anyone — front-end vendors became needed everywhere. Then PHP has become sharply not fashionable, and JS developers are needed on the market.
There are three ways out:
- Relearn under the new stack
- Get better in the old and grab recent orders. The same Delphi is still in demand in narrow circles with a lot of legacy code
- Career management with appropriate skills
Strong specialists will always be needed, but, with a decrease in demand for a certain technology, competition between candidates increases. Custom development suffers to this extent more than the product. Having mastered a large grocery company, the developer may not be afraid of the age or obsolescence of his technology stack - he will be in demand while the product lives. According to my statistics, the average age of developers in food companies is higher than in studios.
TeamLead. Age crisis
Well, Nikolai changed the stack of technologies, and everything seems to be fine, but we see that new skills are being given more and more slowly, and the younger generation is grasping faster and faster.
Here comes the last crisis - the crisis of age.
Nikolay became one of those timblides whom he looked at a few years ago as if he were old men, always grumbling and disgruntled, but now he began to write less.
You might think that if you write less code, then you develop more slowly, and the guys who write it more, respectively, and develop faster, and they will soon catch up with you. I have met such a phobia with young specialists.
What could be the options here:
- If you work in a grocery company, then, probably, this is not so critical for you, and you can leave everything as is
- Go to training, for example, become a consultant, architect, etc.
- Taki go to management
Let's go to the curves
Satisfaction. It can not always be on top, quality projects do not always come across, and the ideal team is difficult to pick up and educate.
I am sure that, despite the drop in satisfaction, one must always remain human. I say that if the deadlines are on the project and everyone is running around in the soap, then an excess of nervousness will not help the cause. The team will be much more comfortable working with people who do not fail at critical moments.
Technical skills are relatively quickly acquired and are forgotten and become obsolete even faster when viewed from the side.
It turns out that the programmer has his peak of development, and then begins to "grow old", and at some point it is time for him to retire?
Yes and no. In fact, instead of one graphic, you can draw 3 (again, IMHO, as well as values).
- tech skills - this is knowledge in technology, programming language, framework. Do you remember that I wrote earlier that the team starts writing less code and more control? These skills have their peak at the moment of the greatest demand for the specialist in the role of coder.
- hard skills are a combination of knowledge and developer experience, over time their growth decreases due to the fact that old knowledge is already becoming obsolete and no longer in demand, but the dry residue remains useful.
- soft skills - these are the personal qualities that can not be counted, but which must be developed. These are qualities that are always important, but in varying degrees given to everyone from birth.
But let's add one more graph
value = (0,5*tech + 1*hard + 1,5*soft)/3
For the third time I repeat that this is my personal formula, and I derived the coefficients in more than 10 years of professional activity in the field of development.
The green graph reflects the totality of all the qualities of a specialist, and this is his total value.
Why are technical skills valued three times less than software skills? Remember the phrase “as a specialist he is good, but as a person — not very much” and those to whom she was applied. The head is more willing to choose a job seeker who you can always rely on than a job seeker who is suitable only for one single project, and then you need an eye over his eyes. Even Juna is easier to work with and develop more quickly in a team, where he will be helped and guided, rather than sought to substitute at the first opportunity.
Therefore, HRs in companies conduct screenings of candidates, including by software skills, before conducting a technical interview. A toxic employee may cause more harm to the company than a technically weak one. And if a technically weak employee has brought harm, then it is rather the fault of his manager. There is a golden rule: let's do the tasks by force, and if you want a person to grow up, then a little more difficult (just a little, and not in the form of an unbearable burden).
2 options for the development of the programmer
I described the option when the developer moves in the following way:
Junior → Middle → Senior → TeamLead? → Project manager? → Head Of * → Chief * Officer
But what to do if it fails or not?
The same formula works if you want to develop your software skills and become a manager: you can develop technical skills and be a sought-after specialist without having to move in the direction of management. But here we must understand that technical skills are obsolete: today you are a great programmer in Fortran, and tomorrow nobody needs you anymore.
TechLead vs TeamLead
In connection with the reproach from the readers for the fact that this topic was not disclosed in the article (I agree that it would be worth adding material), I will add the differences between the two types of leads.
TeamLead (option 1 from the previous chapter) is a technically literate specialist who manages the development team. For the employer, this option is more beneficial for several reasons:
- It is closer to the developers and can adequately assess them.
- The developers treat him better than the project manager.
- You can remove from the project or reduce the participation of the project manager (and he does not bring direct income)
- He can communicate with the client in terms of business, not technology.
- Combines the roles of TechLead and PM
TechLead (option 2 from the previous chapter) is a technician without a team management. In some cases, it is more technically savvy than TeamLead, but less interesting for an employer, because does not combine 2 roles.
Why a particular person is TechLead, not TeamLead:
- It can be very strong technically and should not be distracted, for example, it can participate in more projects.
- He is an introvert or a misanthrope, it is very difficult for him to communicate with people, and he - with him
- He loves programming very much and he is not interested in management tasks.
- PM does not want to share his responsibilities
- The company does not need TeamLead, and more technical specialists are required.
A competent leader, if necessary, both in timbredes and tehlides, will choose the right position for a specific employee (well, or try to), thereby making mutually beneficial cooperation more qualitative for both parties.
A technical leader or an architect is a programmer’s development who does not want and cannot develop as a manager, and this will be discussed further, however, in the absence of very complex projects, it is still less in demand for an employer than a team leader, and if you plant a team leader with equal technical skills and the availability of project managers, the employer in most cases will choose the team leader because of its universality.
Soft skills are very important for a specialist, they allow him to be in demand at those moments when his technological level is not very high, for example, when switching between projects, companies or technologies. Other things being equal, the manager will give preference to a specialist with more advanced software skills.
Moving from a developer to a manager (I mean by a manager rather than a product manager, but a manager, the same team leader combines managerial and technical roles) should be done if the software skills exceed the technical ones, and if the initiative comes from the developer himself.
Bad options that will not give good results:
- I want to become PM, because I love power, and they do nothing
- I want to become PM, because I am not in demand as a developer, but there is a PMA vacancy
- I do not want to be PM, but the manual makes
- I masterfully write directives and am ready to lead the development team.
If you don’t like or fail to manage, but the manager makes you, then it’s better to tell him immediately rather than overpower yourself, and then at some point break down and “fly off to code Bali”. Remember: if you like to write code, and not to lead, then write it.
If you can’t / don’t want to go to the managers, but you just don’t care about programming, then you can consider switching to coaches: sell your services as an architect, conduct your courses, etc.
If you want and like to lead a team of developers, then you should move in this direction and strive to eradicate the developer from yourself - this is the most difficult thing. We must try to delegate tasks, and not do them yourself. By the way, I recommend a great book How to graze cats, which contains advice to programmers who want to become leaders.