Pourquoi la simple mise à niveau de votre codage ne fera pas de vous un meilleur développeur

Responsable technique Skyeng Kirill Rogovoy (flashhhh) donne une présentation lors de conférences dans laquelle 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 de Habra, je donne la parole à Kirill.

Le mythe d'un bon développeur est qu'il :

1. Écrit du code propre
2. Connaît beaucoup de technologies
3. Tâches de codage plus rapides
4. Connaît un tas d'algorithmes et de modèles de conception
5. Peut refactoriser n'importe quel code en utilisant Clean Code
6. Ne perd pas de temps sur des tâches non liées à la programmation
7. 100% maître de votre technologie préférée

C'est ainsi que les RH voient les candidats idéaux et, par conséquent, les postes vacants ressemblent également à cela.

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 de produits, c'est-à-dire des entreprises avec leur propre produit, sans sous-traitance ; dans l'externalisation, tout peut être très différent ;
2) si vous êtes junior, alors tous les conseils ne seront pas applicables, et si j'étais vous, je me concentrerais sur la programmation pour l'instant.

Bon développeur : réalité

1 : Code meilleur que la moyenne

Un bon développeur sait comment créer une architecture sympa, écrire du code sympa et ne pas créer trop de bugs ; En général, il fait mieux que la moyenne, mais il ne fait pas partie du top 1% des spécialistes. La plupart des développeurs les plus cool que je connaisse ne sont pas de très bons codeurs : ils sont excellents dans ce qu'ils font, mais ils ne peuvent rien faire de super-extraordinaire.

2 : Résout les problèmes plutôt que d’en créer

Imaginons que nous devions intégrer un service externe dans le projet. Nous recevons les spécifications techniques, regardons la documentation, voyons que quelque chose y est obsolète, comprenons que nous devons passer des paramètres supplémentaires, faire quelques ajustements, essayer de tout implémenter d'une manière ou d'une autre et faire fonctionner correctement une méthode tordue, enfin, après quelques de jours nous comprenons que nous ne pouvons pas continuer comme ça. Le comportement standard d'un développeur dans cette situation est de revenir aux affaires et de dire : « J'ai fait ceci et cela, celui-ci ne fonctionne pas comme ça, et celui-là ne fonctionne pas du tout, alors va le découvrir par toi-même. » Une entreprise a un problème : vous devez vous plonger dans ce qui s'est passé, communiquer avec quelqu'un et essayer de le résoudre d'une manière ou d'une autre. Le téléphone cassé commence : « tu lui dis, je lui enverrai un texto, regarde ce qu'ils ont répondu. »

Un bon développeur, confronté à une telle situation, trouvera lui-même des contacts, le contactera au téléphone, discutera du problème, et si rien ne fonctionne, il rassemblera les bonnes personnes, expliquera tout et proposera des alternatives (très probablement, il y en a un autre service externe avec un meilleur support). Un tel développeur voit un problème commercial et le résout. Sa tâche est terminée lorsqu'il résout un problème commercial, et non lorsqu'il rencontre quelque chose.

3 : Essaie de déployer un minimum d’efforts pour obtenir un maximum de résultats, même si cela implique d’écrire avec des béquilles

Le développement de logiciels dans les entreprises de produits constitue presque toujours le poste de dépense le plus important : 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 souhaite consacrer le minimum de son temps coûteux à obtenir le maximum de profit pour l'employeur.

Il y a ici deux extrêmes. La première est que vous pouvez généralement résoudre tous les problèmes avec une béquille, sans vous soucier de l'architecture, sans refactoring, etc. Nous savons tous comment cela se termine habituellement : rien ne fonctionne, nous réécrivons le projet à partir de zéro. Une autre situation est celle où une personne essaie de proposer une architecture idéale pour chaque bouton, en consacrant une heure à la tâche et quatre à la refactorisation. Le résultat d'un tel travail semble excellent, mais le problème est que du côté des entreprises, il faut dix heures pour terminer un bouton, dans le premier comme dans le deuxième cas, simplement pour des raisons différentes.

Un bon développeur sait équilibrer entre ces extrêmes. Il comprend le contexte et prend la décision optimale : dans ce problème, je vais couper une béquille, car c'est du code qui est touché une fois tous les six mois. Mais dans celui-ci, je vais m'embêter et tout faire le plus correctement possible, car une centaine de nouvelles fonctionnalités qui restent à développer dépendront de ma réussite.

4. Possède son propre système de gestion d'entreprise et est capable de travailler sur des projets de toute complexité.

Travailler sur des principes Getting Things Done – lorsque vous écrivez toutes vos tâches dans une sorte de système de texte, n’oubliez aucun accord, poussez tout le monde, soyez présent partout à l’heure, sachez ce qui est important et 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 êtes d’accord sur quelque chose avec elles, vous ne craignez jamais qu’elles l’oublient ; et vous savez aussi qu'ils écrivent tout et ne poseront pas ensuite mille questions dont les réponses ont déjà été discutées.

5. Questions et clarifications sur les conditions et introductions

Ici aussi, il y a deux extrêmes. D’une part, vous pouvez être sceptique quant à toutes les informations introductives. Des gens avant vous ont proposé des solutions, mais vous pensez que vous pouvez faire mieux et commencez à rediscuter de tout ce qui vous a précédé : le design, les solutions commerciales, l'architecture, etc. Cela fait perdre beaucoup de temps au développeur et à son entourage et a un impact négatif sur la confiance au sein de l’entreprise : les autres ne veulent pas prendre de décisions car ils savent que ce type reviendra et tout cassera. L'autre extrême est lorsqu'un développeur perçoit les spécifications d'introduction, les spécifications techniques et les souhaits commerciaux comme quelque chose de gravé dans la pierre, et ce n'est que lorsqu'il est confronté à un problème insoluble qu'il commence à se demander s'il fait ce qu'il fait. Un bon développeur trouve également ici un juste milieu : il essaie de comprendre les décisions prises avant ou sans lui, avant que la tâche ne passe au développement. Que veulent les entreprises ? Sommes-nous en train de résoudre ses problèmes ? Le concepteur du produit a trouvé une solution, mais est-ce que je comprends pourquoi la solution fonctionnera ? Pourquoi le chef d’équipe a-t-il proposé cette architecture particulière ? Si quelque chose n’est pas clair, vous devez demander. Au cours de cette clarification, un bon développeur peut voir une solution alternative à laquelle personne n'avait tout simplement pensé auparavant.

6. Améliore les processus et les personnes autour de vous

De nombreux processus se déroulent autour de nous : réunions quotidiennes, rencontres, mêlées, révisions techniques, révisions de code, etc. Un bon développeur va se lever et dire : écoute, on se retrouve et on discute de la même chose chaque semaine, je ne comprends pas pourquoi, autant passer cette heure sur Contra. Ou : pour la troisième tâche consécutive je n'arrive pas à rentrer dans 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 le refactoriser, refactorisons la rencontre 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 qu'il doit revenir plus tard et donner des conseils. Un bon développeur a cet instinct : il fait ce genre de choses automatiquement.

7. Excellent pour gérer les autres, même si ce n'est pas un manager

Cette compétence s’inscrit bien dans le thème « résoudre plutôt que créer des problèmes ». Souvent, dans le texte du poste vacant pour lequel nous postulons, rien n'est écrit sur la gestion, mais alors, face à un problème indépendant de votre volonté, vous devez quand même gérer les autres d'une manière ou d'une autre, en tirer quelque chose, si vous j'ai oublié - poussez, assurez-vous qu'ils ont tout compris. Un bon développeur sait qui est intéressé par quoi, peut convoquer une réunion avec ces personnes, rédiger des accords, les envoyer à slack, leur rappeler le bon jour, s'assurer que tout est prêt, même s'il n'en est pas personnellement directement responsable. cette tâche, mais son résultat dépend de sa mise en œuvre.

8. Ne perçoit pas ses connaissances comme un dogme, est constamment ouvert à la critique

Tout le monde se souvient d'un collègue d'un emploi précédent qui était incapable de faire des compromis sur sa technologie et criait que tout le monde brûlerait en enfer à cause de mauvaises mutations. Un bon développeur, s'il travaille 5, 10, 20 ans dans l'industrie, comprend que la moitié de ses connaissances sont pourries, et dans la moitié restante, il n'en sait pas dix fois plus qu'il n'en sait. Et chaque fois que quelqu’un n’est pas d’accord avec lui et lui propose une alternative, ce n’est pas une attaque contre son ego, mais une opportunité d’apprendre quelque chose. Cela lui permet de grandir beaucoup plus vite que son entourage.

Comparons mon idée d'un développeur idéal avec celle généralement acceptée :

Cette image montre combien des points décrits ci-dessus sont liés au code et combien ne le sont pas. Le développement dans une entreprise de produits ne représente qu'un tiers de la programmation, les 2/3 restants n'ont que peu à voir avec le code. Et même si nous écrivons beaucoup de code, notre efficacité dépend en grande partie de ces deux tiers « non pertinents ».

Spécialisation, généralisme et règle des 80-20

Lorsqu'une personne apprend à résoudre des problèmes précis, étudie longuement et durement, mais les résout ensuite facilement et simplement, mais n'a pas d'expertise dans des domaines connexes, il s'agit d'une spécialisation. Le généralisme, c’est lorsque la moitié du temps de formation est investie dans le domaine de sa propre compétence, et l’autre moitié dans des domaines connexes. Ainsi, 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 provient de 20 % d’effort. 80 % des revenus proviennent de 20 % des clients, 80 % des bénéfices proviennent de 20 % des salariés, etc. En enseignement, cela signifie que 80 % des connaissances sont acquises dans les premiers 20 % du temps passé.

Il y a une idée : les codeurs doivent uniquement coder, les concepteurs doivent uniquement concevoir, les analystes doivent analyser et les managers doivent uniquement gérer. À mon avis, cette idée est toxique et ne fonctionne pas très bien. Il ne s’agit pas pour tout le monde d’être un soldat universel, il s’agit plutôt d’économiser les ressources. Si un développeur comprend au moins un peu la gestion, la conception et l'analyse, il sera capable de résoudre de nombreux problèmes sans impliquer d'autres personnes. Si vous avez besoin de créer une sorte de fonctionnalité, puis de vérifier comment les utilisateurs l'utilisent dans un certain contexte, ce qui nécessitera deux requêtes SQL, alors c'est formidable de pouvoir ne pas distraire l'analyste avec cela. Si vous avez besoin d'intégrer un bouton par analogie avec des boutons existants et que vous comprenez les principes généraux, vous pouvez le faire sans impliquer un concepteur, et l'entreprise vous en remerciera.

Total : vous pouvez passer 100 % de votre temps à étudier une compétence jusqu'à la limite, ou vous pouvez passer le même temps dans cinq domaines, en progressant jusqu'à 80 % dans chacun. En suivant ce calcul naïf, nous pouvons acquérir quatre fois plus de compétences dans le même laps de temps. C'est une exagération, mais cela illustre l'idée.

Les compétences connexes peuvent être formées non pas à 80 %, mais à 30 à 50 %. Après avoir passé 10 à 20 heures, vous vous améliorerez sensiblement dans des domaines connexes, gagnerez en compréhension des processus qui s'y déroulent et deviendrez beaucoup plus autonome.

Dans l’écosystème informatique d’aujourd’hui, il est préférable d’avoir autant de compétences que possible et de n’être expert dans aucune d’entre elles. Parce que, d'une part, toutes ces compétences s'estompent rapidement, surtout lorsqu'il s'agit de 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 en des entreprises sympas.

Et enfin, la formation est un investissement, et la diversification est importante dans les investissements.

Quoi enseigner

Alors quoi enseigner et comment ? Un développeur type dans une entreprise solide utilise régulièrement :

• communication
• auto-organisation
• planification
• conception (généralement du code)
• et parfois gestion, leadership, analyse de données, rédaction, recrutement, mentorat et bien d'autres compétences

Et pratiquement aucune de ces compétences ne recoupe de quelque manière que ce soit le code lui-même. Ils doivent être enseignés et amélioré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 ?

1. Les soft skills sont tout ce qui ne concerne pas l'appui sur les 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. Tout cela semble évident, mais est très souvent sous-estimé.

2. Système d'auto-organisation. Pour moi personnellement, c’est devenu un sujet extrêmement important au cours de l’année écoulée. Parmi tous les informaticiens 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 facilite grandement l'interaction avec les autres. Je pense qu'au cours de l'année écoulée, le développement dans cette direction m'a amélioré bien plus que l'amélioration de mes compétences techniques : j'ai commencé à faire beaucoup plus de travail par unité de temps.

3. Proactif, ouvert d'esprit et planifié. Les sujets sont très généraux et vitaux, pas propres à l'informatique, et chacun devrait les développer. La proactivité signifie ne pas attendre un signal pour agir. Vous êtes la source des événements, pas les réactions à ceux-ci. L’ouverture d’esprit est la capacité de traiter toute nouvelle information de manière objective, d’évaluer la situation indépendamment de sa propre vision du monde et de ses anciennes habitudes. La planification est une vision claire de la façon dont la tâche d’aujourd’hui résout le problème pour la semaine, le mois, l’année. Si vous envisagez 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 vous rendre compte au fil du temps que cela a été gaspillé. Cette compétence est particulièrement importante pour une carrière : vous pouvez réussir à obtenir des résultats pendant des années, mais au mauvais endroit, et éventuellement perdre tout le bagage accumulé lorsqu'il devient clair que vous alliez dans la mauvaise direction.

4. Tous les domaines liés au niveau de base. Chacun a ses propres domaines spécifiques, mais il est important de comprendre qu'en consacrant 10 à 20 heures à améliorer certaines compétences « étrangères », vous pouvez découvrir de nombreuses nouvelles opportunités et points de contact dans votre travail quotidien, et ces heures peuvent suffire jusqu'à la fin de la carrière.

Quoi lire

Il existe de nombreux livres sur l’auto-organisation, c’est toute une industrie où des types étranges écrivent des recueils de conseils et rassemblent des formations. Dans le même temps, on ne sait pas exactement ce qu’ils ont eux-mêmes accompli dans la vie. Il est donc important de filtrer les auteurs, de regarder qui ils sont et ce qu’ils ont derrière eux. Mon développement et mes perspectives ont été plus influencés par quatre livres, tous liés d'une manière ou d'une autre à l'amélioration des compétences décrites ci-dessus.

1. Dale Carnegie « Comment se faire des amis et influencer les gens ». Un livre culte sur les soft skills, si vous ne savez pas par où commencer, le choisir est une option gagnant-gagnant. Il est construit sur des exemples, est facile à lire, ne nécessite pas beaucoup d'efforts pour comprendre ce que vous lisez et les compétences acquises peuvent être appliquées immédiatement. Dans l'ensemble, le livre couvre le thème de la communication avec les gens.

2. Stephen R. Covey « 7 habitudes des personnes très efficaces ». Un mélange de différentes compétences, de la proactivité aux soft skills, avec un accent sur la création de synergie lorsque vous devez transformer une petite équipe en une grande force. C'est aussi facile à lire.

3. Ray Dalio "Principes". Révèle des thèmes d'ouverture d'esprit et de proactivité, basés sur l'histoire de l'entreprise que l'auteur a bâtie et qu'il a dirigée pendant 40 ans. De nombreux exemples durement gagnés de la vie montrent à quel point une personne peut avoir des préjugés et être dépendante et comment s'en débarrasser.

4. David Allen, « Faire avancer les choses ». Lecture obligatoire pour apprendre l'auto-organisation. Ce n'est pas si facile à lire, mais il fournit un ensemble complet d'outils pour organiser la vie et les affaires, examine tous les aspects en détail et vous aide à décider exactement de ce dont vous avez besoin. Avec son aide, j'ai construit mon propre système qui me permet de toujours faire les choses les plus importantes sans oublier le reste.

Vous devez comprendre que lire ne suffit pas. Vous pouvez avaler au moins un livre par semaine, mais l'effet durera plusieurs jours, puis tout reviendra à sa place. Les livres doivent être utilisés comme une source de conseils immédiatement testés dans la pratique. Si vous ne le faites pas, tout ce qu’ils vous apporteront, c’est un élargissement de vos horizons.

Source: habr.com