Techlead Skyeng Kirill Rogovoy ( flashhhh ) prend la parole lors de conférences au cours desquelles il parle des compétences que tout bon développeur doit développer pour devenir le meilleur. Je lui ai demandé de partager cette histoire avec les lecteurs d'Habra, je passe le mot à Cyril.
Le mythe d'un bon développeur dit qu'il:
- Écrit du code propre
- Connaît beaucoup de technologie
- Tâches de codage plus rapides
- Connaît un tas d'algorithmes et de modèles de conception
- Peut refactoriser n'importe quel code à l'aide de Clean Code
- Ne perd pas de temps sur des tâches non programmatiques
- 100% maître de votre technologie préférée
C'est ainsi que les RH voient les candidats idéaux, et les postes vacants, respectivement, ressemblent également à ceci.
Mais mon expérience montre que ce n'est pas très vrai.
Tout d'abord, deux avertissements importants:
1) Mon expérience concerne les équipes produit, c'est-à-dire les entreprises avec leur produit, pas l'externalisation; l'externalisation peut être très différente;
2) si vous êtes un junior, tous les conseils ne seront pas applicables, et je continuerais à me concentrer sur la programmation à votre place.
Bon développeur: la réalité
1: le codite est meilleur que la moyenne
Un bon développeur sait comment créer une architecture sympa, écrire du code sympa et ne pas faire trop de bugs; en général, tout va mieux pour lui que la moyenne, mais il n'est pas dans le top 1% des spécialistes. La plupart des développeurs les plus cool que je connaisse ne sont pas des codeurs aussi géniaux: ils connaissent bien leur domaine, mais ils ne peuvent rien faire de super-super.
2: Résout les problèmes, pas les crée
Imaginez que nous devons intégrer un service externe dans un projet. Nous obtenons des savoirs traditionnels, regardons les quais, voyons que quelque chose est obsolète, nous comprenons que nous devons passer des paramètres supplémentaires, béquiller quelque chose, essayer de l'implémenter et faire fonctionner correctement une sorte de méthode de courbe, enfin, après quelques jours, nous comprenons que plus il est impossible. Le comportement standard du développeur dans cette situation est de reprendre ses activités et de dire: "J'ai fait ceci et cela, cela ne fonctionne pas comme ça, et cela ne fonctionnera pas du tout, en général, allez le découvrir vous-même." L'entreprise a un problème: vous devez vous plonger dans ce qui s'est passé, communiquer avec quelqu'un, essayer de le résoudre d'une manière ou d'une autre. Le téléphone cassé commence: "vous lui dites, je vais lui écrire, regardez ce qu'ils ont répondu".
Un bon développeur, face à une telle situation, trouvera lui-même les contacts, radiera, téléphonera, discutera du problème, et si tout le reste échoue, il rassemblera les bonnes personnes, expliquera tout et proposera des alternatives (très probablement, il existe un autre service externe avec un meilleur support). Un tel développeur voit un problème commercial et le résout. Sa tâche a été close quand il a résolu le problème des affaires, et non quand il est tombé sur quelque chose.
3: Essaie de dépenser un minimum d'efforts, d'obtenir des résultats maximaux, même si vous devez écrire des béquilles
Le développement de logiciels dans les épiceries représente presque toujours la plus grosse dépense: les développeurs coûtent cher. Et un bon développeur comprend qu'une entreprise veut obtenir le maximum d'argent en dépensant le minimum. Pour l'aider, un bon développeur veut dépenser le minimum de son temps cher pour obtenir le maximum de profit pour l'employeur.
Deux extrêmes se posent ici. La première est qu'il est possible de résoudre tous les problèmes dans une béquille, de ne pas se soucier de l'architecture, de ne pas refactoriser, etc. Nous savons tous comment cela se termine généralement: rien ne fonctionne, nous réécrivons le projet à partir de zéro. L'autre est lorsqu'une personne essaie de proposer une architecture idéale pour chaque bouton, passe une heure sur une tâche et quatre sur la refactorisation. Le résultat d'un tel travail semble excellent, mais le problème est qu'il faut dix heures pour le bouton du côté commercial, ce qui dans le premier, dans le second cas, simplement pour diverses raisons.
Un bon développeur peut équilibrer ces extrêmes. Il comprend le contexte et prend la meilleure décision: dans cette tâche, je vais scier une béquille, car il s'agit d'un code qui est touché une fois tous les six mois. Mais dans celui-ci, je suis confus et je ferai tout aussi correctement que possible, car une centaine de nouvelles fonctionnalités qui n'ont pas encore été développées dépendront de ce que je peux faire.
4. A son propre système de gestion d'entreprise, est capable d'élaborer des projets de toute complexité.
Travailler selon les principes de Getting Things Done - lorsque vous écrivez tout dans un système de texte, n'oubliez pas les accords, poussez tout le monde, apparaissez partout dans le temps, sachez ce qui est important, ce qui ne l'est pas pour le moment, vous ne perdez jamais de tâches. La caractéristique générale de ces personnes est que lorsque vous parvenez à un accord avec elles, vous ne vous inquiétez jamais qu'elles oublieront; et vous savez aussi qu'ils écrivent tous et ne poseront pas alors mille questions dont les réponses ont déjà été discutées.
5. Doute et clarifie toutes les conditions et introduction
Il y a également deux extrêmes ici. D'une part, vous pouvez être sceptique à l'égard de toutes les présentations. Avant vous, les gens ont proposé des solutions, et vous pensez que vous pouvez faire mieux et commencer à re-discuter de tout ce qui vous a précédé: design, solutions métier, architecture, etc. Cela passe beaucoup de temps à la fois le développeur et les autres, et affecte négativement la confiance au sein de l'entreprise: d'autres personnes ne veulent pas prendre de décisions car elles savent que ce type reviendra et tout casser. L'autre extrême est lorsqu'un développeur perçoit tout souhait d'introduction, de savoirs traditionnels et d'hôtel comme quelque chose de gravé dans la pierre, et n'ayant rencontré qu'un problème insoluble, il commence à se demander s'il s'y est engagé du tout. Un bon développeur ici trouve également un terrain d'entente: essayer de comprendre les décisions prises avec ou sans lui, avant que la tâche ne se développe. Que veut l'entreprise? Résout-on ses problèmes? Le concepteur du produit a trouvé une solution, mais est-ce que je comprends pourquoi cette solution fonctionnera? Pourquoi l'équipe dirigeante a-t-elle proposé une telle architecture? Si quelque chose n'est pas clair, alors vous devez aller demander. Au cours de cette clarification, un bon développeur peut voir une solution alternative qui n'a tout simplement pas vu le jour avant lui.
6. Améliore les processus et les personnes qui vous entourent.
Des tas de processus nous entourent - rassemblements quotidiens, réunions, scrams, ces révisions, révisions de code, etc. Un bon développeur se lèvera et dira: écoutez, nous allons discuter de la même chose chaque semaine, je ne comprends pas pourquoi, avec le même succès, vous pourriez passer cette heure sur "Contra". Ou: la troisième tâche consécutive, je ne peux pas entrer le code, rien n'est clair, l'architecture est pleine de trous; peut-être que notre code de révision est boiteux et que nous devons effectuer une refactorisation, procédons à une refactorisation mitap toutes les deux semaines. Ou lors d'une révision de code, une personne constate qu'un de ses collègues n'utilise pas un certain outil de manière suffisamment efficace, ce qui signifie que vous devez venir le dire plus tard. Un bon développeur a cet instinct, il fait de telles choses sur la machine.
7. Gère parfaitement les autres, même si ce n'est pas un manager
Cette compétence est bien liée au thème «résoudre, pas créer des problèmes». Souvent, rien n'est écrit sur la gestion dans le texte de la vacance à laquelle nous venons, mais ensuite, face à un problème indépendant de votre volonté, vous devez toujours gérer les autres d'une manière ou d'une autre, obtenir quelque chose d'eux, si vous avez oublié de pousser, assurez-vous qu'ils ont tous compris. Un bon développeur sait qui est intéressé par quoi, peut réunir une réunion avec ces personnes, rédiger des accords, les mettre à l'écart, leur rappeler le bon jour, s'assurer que tout est prêt, même s'il n'est pas personnellement directement responsable de cette tâche, mais son résultat dépend dès sa mise en œuvre.
8. Ne perçoit pas ses connaissances comme un dogme, constamment ouvert à la critique
Tout le monde peut se souvenir d'un collègue d'un travail précédent qui est incapable de transiger avec sa technologie, crie que tout le monde va brûler en enfer pour de mauvaises mutations. Un bon développeur, s'il travaille depuis 5, 10, 20 ans dans l'industrie, comprend que la moitié de ses connaissances est pourrie, et dans la moitié restante il n'en sait pas dix fois plus que ce qu'il sait. Et chaque fois que quelqu'un n'est pas d'accord avec lui et propose une alternative, ce n'est pas une attaque contre son ego, mais la possibilité d'apprendre quelque chose. Cela lui permet de grandir beaucoup plus vite que les autres.
Comparez mon idée d'un développeur idéal avec celle généralement acceptée:
Dans cette image, vous pouvez voir combien de points ci-dessus sont liés au code et combien ne le sont pas. Le développement dans une entreprise d'épicerie ne représente qu'un tiers de la programmation, les 2/3 restants ont peu à voir avec le code. Et bien que nous écrivions beaucoup de code, notre efficacité dépend fortement de ces deux tiers «sans rapport».
Spécialisation, généralisme et règle "80-20"
Lorsqu'une personne apprend à résoudre des problèmes étroits, elle apprend longtemps et durement, mais ensuite elle les résout facilement et simplement, mais n'a pas d'expertise dans des domaines connexes - c'est une spécialisation. Le généralisme, quant à lui, consiste à investir la moitié du temps de formation dans une zone de compétence propre et une autre moitié dans des domaines connexes. En conséquence, dans le premier cas, je fais une chose parfaitement, et le reste - mal, et dans le second - je fais tout plus ou moins bien.
La règle des 80-20 nous dit que 80% du résultat est obtenu grâce à 20% de l'effort. 80% des revenus sont apportés par 20% des clients, 80% des bénéfices sont générés par 20% des employés et ainsi de suite. En formation, cela signifie que nous obtenons 80% des connaissances dans les premiers 20% du temps passé.
Il y a une idée: les codeurs devraient seulement coder, les concepteurs devraient concevoir, les analystes devraient analyser et les gestionnaires devraient gérer. À mon avis, cette idée est toxique et ne fonctionne pas très bien. Ce n'est pas que tout le monde devrait être un soldat universel, c'est une question d'économie de ressources. Si un développeur est même un peu versé dans la gestion, la conception et l'analyse, il sera en mesure de résoudre de nombreux problèmes sans impliquer d'autres personnes. Si vous avez besoin de créer une fonctionnalité, puis de vérifier comment les utilisateurs travaillent avec dans un certain contexte, ce qui nécessitera deux requêtes SQL, alors c'est génial de ne pas perturber les analyses. Si vous avez besoin d'appuyer sur un bouton par analogie avec ceux existants, et que vous comprenez les principes généraux, vous pouvez le faire sans impliquer un concepteur, et la société vous en remerciera.
Total: vous pouvez passer 100% du temps à apprendre une certaine compétence à la limite, ou vous pouvez passer le même temps dans cinq domaines, en pompant 80% dans chacun. Suite à ce calcul naïf, nous pouvons acquérir quatre fois plus de compétences en même temps. C'est une exagération, mais cela illustre l'idée.
Les compétences adjacentes peuvent être formées non pas à 80%, mais à 30-50%. Après avoir passé 10 à 20 heures, vous pomperez sensiblement dans des domaines connexes, vous comprendrez beaucoup les processus qui s'y déroulent et deviendrez beaucoup plus autonome.
Dans l'écosystème informatique moderne, il est préférable d'avoir autant de compétences que possible et de ne pas être expert dans aucune d'entre elles. Parce que, d'une part, toutes ces compétences disparaissent rapidement, en particulier en ce qui concerne la programmation, et d'autre part, parce que 99% du temps, nous utilisons non seulement les compétences de base, mais certainement pas les plus sophistiquées, et cela suffit même en codage, même dans les entreprises sympas.
Enfin, la formation est un investissement et la diversification est importante dans les investissements.
Quoi enseigner
Alors quoi enseigner et comment? Un développeur typique d'une entreprise solide utilise régulièrement:
- la communication
- auto-organisation
- planification
- conception (généralement code)
- et parfois gestion, leadership, analyse de données, rédaction, embauche, mentorat et bien d'autres compétences
Et pratiquement aucune de ces compétences ne recoupe en aucune façon le code lui-même. Ils doivent être entraînés et pompés séparément, et si cela n'est pas fait, ils resteront à un niveau très bas, ce qui ne permettra pas de les utiliser efficacement.
Quels domaines méritent d'être développés?
Compétences générales - c'est tout ce qui ne s'applique pas aux pressions de boutons dans l'éditeur. C'est ainsi que nous écrivons des messages, comment nous nous comportons lors des réunions, comment nous communiquons avec nos collègues. Il semble que toutes les choses soient évidentes, mais très souvent elles sont sous-estimées.
Système d'auto-organisation. Pour moi, au cours de la dernière année, c'est devenu un sujet super important. Parmi tous les travailleurs informatiques sympas que je connais, c'est l'une des compétences les plus développées: ils sont super organisés, ils font toujours ce qu'ils disent, ils savent exactement ce qu'ils feront demain, dans une semaine, dans un mois. Il est nécessaire de construire autour de vous un système dans lequel toutes les affaires et toutes les questions sont enregistrées, cela facilite grandement le travail lui-même et aide grandement à interagir avec d'autres personnes. Selon mes sentiments, au cours de la dernière année, le développement dans cette direction m'a beaucoup plus pompé que le pompage des compétences techniques, j'ai commencé à faire beaucoup plus de travail par unité de temps.
Proactivité, ouverture d'esprit et planification. Les sujets sont très généraux et vitaux, ne sont pas propres à l'informatique, et tout le monde devrait les développer. La proactivité signifie ne pas attendre un signal pour agir. Vous êtes la source des événements, pas des réactions. Ouverture d'esprit - la capacité de se rapporter objectivement à toute nouvelle information, d'évaluer la situation indépendamment de leur propre vision du monde et de leurs vieilles habitudes. La planification est une vision claire de la façon dont la tâche d'aujourd'hui résout le problème pendant une semaine, un mois ou une année. Si vous voyez l'avenir au-delà d'une tâche spécifique, il est beaucoup plus facile de faire ce dont vous avez besoin et de ne pas avoir peur de réaliser avec le temps qu'il a été gaspillé. Cette compétence est particulièrement importante pour une carrière: pendant des années, vous pouvez réussir à obtenir des résultats, mais pas là où vous en avez besoin, et par conséquent perdre tous les bagages accumulés lorsqu'il devient clair que vous vous dirigez dans la mauvaise direction.
Tous les domaines liés au niveau de base. Chacun a ses propres domaines spécifiques, mais il est important de comprendre qu'en passant 10 à 20 heures de temps à pomper une sorte de compétence «étrangère», vous pouvez découvrir de nombreuses nouvelles opportunités et un terrain d'entente dans le travail quotidien, et ces heures peuvent suffire à fin de carrière.
Que lire
Il y a beaucoup de livres sur l'auto-organisation, c'est une industrie entière où des gars obscurs écrivent des collections de conseils et collectent des formations. Cependant, il n'est pas clair ce qu'ils ont accompli dans la vie. Par conséquent, il est important de mettre des filtres sur les auteurs, pour voir qui ils sont et ce qu'ils ont derrière eux. Quatre livres ont surtout influencé mon développement et mes perspectives, tous d'une manière ou d'une autre liés au pompage des compétences décrites ci-dessus.
1. Dale Carnegie «Comment se faire des amis et influencer les gens» . Un livre culte sur les compétences générales, s'il n'est pas clair par où commencer, le choisir est une option gagnant-gagnant. Il est construit sur des exemples, faciles à lire, ne nécessite pas beaucoup d'efforts pour comprendre ce qui a été lu, et les compétences acquises peuvent être immédiatement appliquées. En général, le livre révèle le sujet de la communication avec les gens.
2. Stephen R. Covey, «7 compétences de personnes hautement efficaces» . Un mélange de différentes compétences, de la proactivité aux compétences générales, en mettant l'accent sur la création de synergies, lorsque vous devez transformer une petite équipe en une force énorme. Facile à lire.
3. Les principes de Ray Dalio . Il dévoile les thèmes de l'ouverture d'esprit et de la proactivité, à partir de l'histoire de l'entreprise construite par l'auteur, qu'il a dirigée pendant 40 ans. Beaucoup d'exemples de vie durement gagnés, de grands spectacles à quel point une personne peut être lésée et dépendante, comment s'en débarrasser.
4. David Allen "Comment mettre les choses en ordre" . Lecture requise pour apprendre l'auto-organisation. La lecture n'est pas si simple, mais elle fournit un ensemble exhaustif d'outils pour organiser la vie et le travail, examine en détail tous les aspects, vous aide à décider de ce dont vous avez besoin. Avec son aide, j'ai construit mon système, ce qui me permet de toujours faire le plus important, sans oublier le reste.
Vous devez comprendre que la lecture ne suffit pas. Vous pouvez même avaler un livre par semaine, mais l'effet restera pendant plusieurs jours, puis tout reviendra à sa place. Les livres doivent être utilisés comme une source de conseil qui est immédiatement testée dans la pratique. Si cela n'est pas fait, alors tout ce qu'ils donneront, c'est une certaine expansion des horizons.