Courbes de développement du programmeur et un peu sur l'effet Dunning - Krueger

Il existe deux façons principales de devenir des cadres supérieurs dans les entreprises informatiques:

1. Gestion - lorsqu'un chef de projet commence à gérer d'autres gestionnaires.
2. Tekhnarsky - lorsqu'un développeur commence à gérer d'autres développeurs et le nombre d'employés qu'il gère augmente.

La première voie est plus naturelle, car elle implique le développement des qualités de base d'un manager à mesure qu'il grandit. En fait, le manager reste le manager, ne devenant un spécialiste qu'à un niveau supérieur.

La deuxième voie est plus longue et ne garantit pas le succès, car elle est contraire à l'essence du programmeur introverti. Cependant, sur cette voie, je voudrais me concentrer sur et partager mon expérience et mes connaissances.

Attention, spoiler.

1. Tous les noms sont fictifs
2. La narration concerne davantage le développement personnalisé.
3. Les compétences, et en particulier les compétences générales, sont difficiles à évaluer formellement, tous les graphiques de cet article sont conditionnels et reflètent mon opinion personnelle

Le début du chemin du programmeur

Nous sommes donc au tout début du chemin du programmeur.

Rencontre: Nikolai (nom changé). Nikolai est un jeune programmeur, il étudie bien à l'université et a déjà essayé d'écrire des sites Web simples. Il est entré en studio pour le poste de front-end de juin, il a été mis sur un projet qui a été écrit pendant deux ans en utilisant la version 1.5 du framework Angular moderne. Le garçon de Kolya ne travaillait pas avec lui, mais il a vu un signe dollar familier, et il a déjà réussi à écrire quelques plug-ins pour jQuery. Ce fait a encouragé Nicholas, mais les camarades supérieurs lui ont dit que ce n'était pas du tout jQuery, et, en général, vous devez écrire une directive ici, mais ici deux filtres doivent être effectués. Nikolay est déprimé, mais est déterminé à rejoindre ce projet.

Et maintenant un an s'est écoulé, Nikolai écrit magistralement des directives et ne passe pas une journée sans un nouveau module. Kohl à cheval, l'optimisme lui est ajouté par le fait qu'il y a six mois un jeune June a été planté sur lui pour un projet, et il ne sait même pas ce qu'est la directive. Chiot! Nikolai s'est lié d'amitié avec des camarades plus âgés et seul un homme de 30 ans dans le coin est toujours insatisfait de quelque chose.


En fait, sur les graphiques, nous voyons les compétences techniques pour le projet et toutes les compétences de Nicholas qu'il a. Puisque c'est son premier projet, en fait c'est tout ce que Nikolai sait. Après un certain temps, il se rend chez les patrons et demande deux sacs d'argent - après tout, il crée habilement des directives sur le projet, et en général, il considère qu'il laisse deux fois plus de commentaires dans MR que l'homme de 30 ans. De toute évidence, il est meilleur que son chef d'équipe. Il reçoit un refus tout à fait raisonnable à ce sujet et commence à chercher un nouvel emploi, peut-être qu'il envisage de passer à un autre projet ou à une autre équipe. Dans tous les cas, il est confronté à une situation où les connaissances nouvellement acquises ne sont plus pertinentes et il a besoin d'apprendre davantage.


Il s’agit de la première crise de Nikolai, «L’effet du premier projet».

Dans un nouvel endroit, Nikolai se voit confier un projet sur Angular 5, eh bien, il écrit habilement des directives! Mais là, il voit du jeu! Quoi d'autre TypeScript? Que sont les RxJ et les threads? Les camarades plus âgés se moquent de lui et l'homme de 30 ans jette des regards méchants. J'ai vu un grand nombre de ces étoiles et beaucoup d'étoiles tombantes, lorsque le développeur s'est rendu compte qu'il se trouve qu'il ne sait toujours rien! Et le plus tôt cela se produit, le mieux c'est. C'est ce qu'on appelle le Dunning - Krueger Effect - une distorsion métacognitive, qui consiste dans le fait que les personnes ayant un faible niveau de qualification tirent des conclusions erronées, prennent des décisions infructueuses et sont en même temps incapables de reconnaître leurs erreurs en raison du faible niveau de leurs qualifications.

June, qui a remplacé 3-4 projets en un an, est de loin préférable pour l'employeur à June, qui a siégé seul sur le même projet pendant un an, car il:

• Évalue objectivement leurs connaissances et leurs compétences.
• En constante évolution
• Communique davantage dans l'équipe
• Il comprend mieux le prix d'une erreur car il a vu plus de délais et de sorties.

Des collègues qui en étaient à ce stade souhaiteraient ce qui suit:

• Ne perdez pas courage lorsque vous échouez
• Pour constamment apprendre et apprendre de nouvelles bibliothèques et technologies
• Ne joue pas

Junior → Moyen → Senior

Eh bien, quelques années se sont écoulées et que voyons-nous?

Nikolay a déjà maîtrisé plusieurs frameworks et s'est rendu compte que les frameworks ne sont qu'un outil pour résoudre des problèmes spécifiques. Il supporte le fait qu'il ne sait pas tout, mais en même temps il essaie de se développer tout le temps. À un moment donné, il s'approche du jeune chef d'équipe de 33 ans et dit: Écoutez, Petya (le nom a changé), quelques dzhuns sont venus vers nous, ils ne savent rien et font lentement des tâches sur le projet. Permettez-moi de leur donner quelques conférences ou master classes afin qu'ils puissent rapidement rejoindre notre travail. Et c'est à ce moment que Nikolai passe au niveau supérieur.

Maintenant, il y a une division en Junior, Middle, Senior. Middle pense que pour devenir Signor, il doit maîtriser un nouveau langage de programmation et resserrer son équipement. Ce n'est pas tout à fait vrai. À l'aube du développement national, il y avait un poste similaire à celui de Signor, elle s'appelait programmeur principal - un tel spécialiste non seulement en sait beaucoup, mais dirige également des projets ou une équipe. Le signataire ne peut pas devenir sans compétences générales appropriées.

Nikolay a appris à trouver des approches pour tous les membres de l'équipe, il développe et développe constamment le reste. Il a déjà vu les "stars du premier projet", mais il est beaucoup plus à l'aise de travailler avec les mêmes professionnels que lui. Après tout, ils comprennent que le succès du projet est le succès de tous et que la crevaison d'un membre de l'équipe affecte en fin de compte tous ses participants.

À ce stade, deux façons sont possibles: être un simple interprète, ne pas forcer et résoudre des tâches; la seconde est de se développer en direction d'un programmeur de premier plan, de prendre des responsabilités et de l'initiative.

À ce stade du développement du programmeur, l'équipe et la direction apprécient ses qualités:

• Responsabilité
• Fiabilité
• Sociabilité
• Proactivité

Où vaut-il la peine de se développer?

• Compréhension approfondie des technologies qu'il utilise
• Élargir les horizons
• Prendre la responsabilité des projets et des personnes

De plus, les compétences du dernier paragraphe doivent être pompées s'il veut se développer le long de la courbe jusqu'à la tête. S'il n'est pas intéressé, nous pouvons nous concentrer sur les compétences d'un spécialiste technique.

Crise technologique

À un moment donné, Nikolai est horrifié de réaliser que personne n'écrit déjà en JS, et la plupart de ses connaissances ne sont nécessaires à personne. C'est ainsi que la crise technologique s'installe. J'ai trouvé une telle crise avec les applications de bureau. Un peu plus tard, les codeurs n'étaient plus nécessaires à personne - les rendus frontaux ont commencé à être requis partout. Ensuite, PHP est devenu brusquement démodé, et les développeurs JS sont devenus nécessaires sur le marché.


Il existe trois solutions:

1. Se recycler pour une nouvelle pile
2. Devenez meilleur dans l'ancien et saisissez les dernières commandes. Le même Delphi est toujours en demande dans des cercles étroits avec une énorme quantité de code hérité
3. Quitter en gestion avec les compétences appropriées

Des spécialistes solides seront toujours nécessaires, mais, avec une baisse de la demande pour une certaine technologie, la concurrence entre les candidats augmente. Le développement personnalisé souffre dans cette mesure plus que le développement de produits. Après s'être installé dans une grande entreprise d'épicerie, un développeur peut ne pas avoir peur de l'âge ou de l'obsolescence de sa pile technologique - il sera en demande pendant la durée de vie du produit. Selon mes statistiques, l'âge moyen des développeurs dans les entreprises alimentaires est plus élevé que dans les studios.

TeamLead. Crise de l'âge

Eh bien, Nikolay a changé la pile technologique, et tout semble aller bien, mais nous constatons que les nouvelles compétences sont données plus lentement et que la jeune génération rattrape son retard plus rapidement.


Voici la dernière crise - la crise de l'âge.

Nicholas est devenu l'un de ces chefs d'équipe qu'il considérait il y a plusieurs années comme des personnes âgées, toujours grognons et mécontents, mais maintenant il a commencé à écrire moins.
Vous pourriez penser que si vous écrivez moins de code, vous vous développerez plus lentement, et les gars qui écrivent plus se développeront plus rapidement, et ils vous rattraperont bientôt. J'ai rencontré une telle phobie chez les jeunes spécialistes.

Quelles options peut-il y avoir:

• Si vous travaillez dans une entreprise d'épicerie, ce n'est probablement pas si critique pour vous, et vous pouvez tout laisser tel quel
• Aller à la formation, par exemple, pour devenir consultant, architecte, etc.
• Taki va à la gestion

Passons aux courbes

Satisfaction. Il ne peut pas toujours être au top, les projets de haute qualité ne sont pas toujours trouvés et l'équipe idéale est difficile à sélectionner et à éduquer.



Je suis sûr que malgré la baisse de satisfaction, il faut toujours rester humain. Je dis que si les échéances du projet sont respectées et que tout le monde court dans le savon, alors trop de nervosité n'aidera pas l'affaire. L'équipe sera beaucoup plus à l'aise de travailler avec des gens qui ne vous laisseront pas tomber aux moments critiques.

Les compétences techniques sont acquises relativement rapidement et encore plus vite oubliées et deviennent obsolètes si elles sont vues de côté.


Il s'avère que le programmeur a atteint son apogée de développement, puis commence à «vieillir», et à un moment donné, il est temps pour lui de prendre sa retraite?

Oui et non. En fait, au lieu d'un seul graphique, vous pouvez dessiner 3 (à nouveau à mon humble avis, comme les valeurs).

• compétences techniques - ces connaissances concernent la technologie, le langage de programmation et le cadre. Vous souvenez-vous de ce que j'ai écrit plus tôt: le chef d'équipe commence à écrire moins de code et plus de contrôle? Ces compétences ont leur apogée précisément au moment de la plus forte demande pour un spécialiste dans le rôle de codeur.
• Les compétences techniques sont une combinaison des connaissances et de l'expérience des développeurs.Au fil du temps, leur croissance diminue en raison du fait que les anciennes connaissances deviennent déjà obsolètes et non demandées, mais ce sont les résidus secs qui restent utiles.
• les compétences générales sont précisément ces qualités personnelles qui ne peuvent pas être comptées, mais qui doivent être développées. Ce sont des qualités qui sont toujours importantes, mais à des degrés divers sont données à tout le monde dès la naissance.

Mais ajoutons un autre graphique

value = (0,5*tech + 1*hard + 1,5*soft)/3

, , 10 .
, .

, ? « , — » , . , , , , . , , .

HR- . , . , . : , , , ( , ).

2

, :

Junior → Middle → Senior → TeamLead? → Project manager? → Head Of * → Chief * Officer

?
, : . , : , .

TechLead vs TeamLead

       ,     (,   ),    .

TeamLead ( 1   ) — , .   :

1.        
2.   ,  
3.   (    )
4.       ,   .
5.   TechLead  PM

TechLead ( 2   ) — .     , TeamLead,   , ..     2 .
 — TechLead,   TeamLead:

1.   ,    , ,  
2.  — ,  ,   —  
3.   ,    
4. PM    
5.    TeamLead,  

,  ,  , (  ), .

 — ,        ,    , ,   , ,       ,     - .

, , , , , . , .

( , , ) , , .

, :

• , ,
• , ,
• ,

, , , , - « ». : , , .

/ , , : , ..

, — . , . , , , .