Les caractéristiques que partagent, à mes yeux, les meilleurs développeurs

• Au fil de ses rencontres avec des développeurs très divers, l’auteur en est venu à réfléchir aux traits communs des meilleurs d’entre eux
• Ce texte est un recueil d’observations écrit pour inspirer les développeurs débutants ou ceux qui veulent progresser

Lire d’abord la documentation de référence

• Il est important de prendre l’habitude de consulter d’abord la documentation officielle plutôt que de chercher immédiatement sur Stack Overflow ou auprès d’un LLM
• Les documentations officielles d’Apache, de Python, de TOML, etc., sont en réalité souvent très bien rédigées
• Prendre l’habitude d’apprendre directement à partir des sources apporte énormément sur le long terme

Comprendre ses outils en profondeur

• Savoir « utiliser » un outil et le « comprendre » relèvent de deux niveaux très différents
• Quelqu’un qui connaît vraiment un outil peut expliquer chacun de ses paramètres
• Pour bien le comprendre, il faut en maîtriser :
  • l’histoire (pourquoi il a été créé)
  • le présent (qui le maintient)
  • les limites (dans quels cas il n’est pas adapté)
  • l’écosystème (outils, bibliothèques, etc. qui l’entourent)
• Si Kafka est l’un de vos outils principaux, il faut le connaître à un niveau bien supérieur à ce qu’on lit sur Reddit

Lire attentivement les messages d’erreur

• En les examinant avec soin, on y trouve souvent des indices
• Les meilleurs développeurs savent déduire un problème à partir de très peu d’informations
• Dans 80 % des cas, bien lire le message d’erreur suffit déjà à résoudre le problème

Savoir découper un problème en petites parties

• Se retrouver bloqué arrive à tout le monde, et savoir découper un problème est indispensable pour le résoudre
• Les personnes très expérimentées ou particulièrement fortes en résolution de problèmes y parviennent facilement
• Le cœur du métier de développeur consiste finalement à transformer un grand problème en une série de petits problèmes
• En résolvant méthodiquement des problèmes simples, on finit par résoudre l’ensemble

Manipuler le code sans crainte

• Les meilleurs développeurs n’ont pas peur de lire du code
• Ils ne disent pas « ce n’est pas mon domaine » : ils essaient, tout simplement, et apprennent
• Même face à une base de code qu’ils découvrent, ils deviennent souvent très vite les experts de l’équipe sur le sujet

Toujours aider les autres

• Un développeur qui aide les autres malgré un emploi du temps chargé est à la fois un bon coéquipier et un excellent professionnel
• La curiosité et l’esprit de coopération sont des qualités indispensables chez un bon développeur

Écrire

• Les développeurs d’exception s’expriment bien et savent mettre leurs idées par écrit
• Ils partagent leur réflexion à travers un blog, des conférences, des contributions open source, etc.
• La capacité à écrire est directement liée à la structure de la pensée
• Le code de ceux qui écrivent bien est structuré, clair et parfois même plein d’esprit

Ne jamais cesser d’apprendre

• Les développeurs vraiment remarquables continuent d’apprendre quel que soit leur âge
• Ils n’hésitent pas à essayer de nouveaux outils ou de nouveaux langages
• Ils ne suivent pas aveuglément les technologies du moment et savent analyser eux-mêmes leurs avantages et leurs limites
• Même jeune, on cesse de progresser dès qu’on se laisse enfermer dans des idées figées

Ne pas s’attacher au statut

• Un bon développeur cherche à apprendre de tout le monde, quel que soit son poste
• Il part du principe qu’il y a aussi quelque chose à apprendre d’un junior
• Les échanges avec des personnes qui ont un regard neuf sont une source d’inspiration

Construire sa réputation

• Les compétences comptent, mais le fait qu’elles soient connues compte aussi
• La réputation est un moyen d’élargir son influence
• On peut la construire de différentes façons :
  • créer ou déployer soi-même des services importants
  • développer des outils bien connus
  • contribuer à des projets open source réputés
  • écrire des livres souvent cités
• La réputation ne se bâtit pas du jour au lendemain : elle demande du temps et des efforts constants

Faire preuve de patience

• Il faut de la patience aussi bien avec les humains qu’avec les ordinateurs
• Les personnes autour de vous ne sont pas stupides ; il leur manque simplement des informations
• Sans patience, la frustration s’accumule vite et la collaboration devient difficile
• Résoudre des problèmes complexes demande de la concentration et de la persévérance

Ne pas accuser l’ordinateur

• Les meilleurs développeurs ne rejettent jamais la faute sur le système ou sur des facteurs externes
• Même un problème qui semble aléatoire a une cause logique
• Ce qui compte, c’est la volonté de creuser jusqu’au bout pour trouver la cause

Savoir dire « je ne sais pas »

• Il m’est déjà arrivé, en entretien, d’attendre délibérément le moment où un candidat dirait « je ne sais pas »
• Ce qui importe, ce n’est pas la réponse, mais l’attitude
• Les meilleurs candidats reconnaissent qu’ils ne savent pas, puis commencent à raisonner
• Admettre qu’on ne sait pas montre sa capacité à apprendre
• Mentir ou faire semblant de savoir a un effet négatif sur une équipe

Ne pas faire de suppositions

• Comme le dit la philosophie du PEP 20, en cas d’ambiguïté, il ne faut jamais supposer
• Les dangers des suppositions :
  • si l’on se trompe, cela devient un bug
  • même si l’on tombe juste, on risque de croire à une prémisse erronée et de créer plus tard d’autres problèmes
• Si vous n’êtes pas sûr :
  • posez des questions
  • lisez la documentation
  • utilisez des outils de débogage
  • cherchez des éléments concrets

Garder les choses simples

• Les gens intelligents écrivent du code intelligent ; les grands professionnels écrivent du code simple
• Un code simple est bien plus avantageux pour la maintenance
• La vraie compétence consiste à savoir distinguer les situations où la complexité est nécessaire de celles où elle ne l’est pas

Réflexion de conclusion

• Ce texte n’est pas une checklist, et l’excellence en ingénierie n’est pas une compétition
• En revanche, ne vous racontez pas que vous pouvez éviter les tâches difficiles
• Il n’existe pas de raccourci pour devenir un excellent développeur

[dduha]

Merci pour ce très bon article !!

[openman]

Je trouve du réconfort dans l’idée que cet article n’est pas une checklist, et du courage dans l’idée qu’il n’existe pas de raccourci.

[geekbini]

Si l’on comprend les projets de l’entreprise,
quel que soit le domaine dans lequel on devient développeur senior,
qu’il s’agisse de firmware, d’applications ou du web,
on atteint apparemment un niveau où l’on peut analyser les logs de débogage du web, des applications ou du firmware
et déboguer en comprenant comment le problème s’est produit.

[softer]

Je me souviens du comportement que j'avais cru deviner pendant l'entretien.

[wogns3623]

Personnellement, j’accorde aussi beaucoup d’importance au fait de « toujours réfléchir à ce que je suis en train de construire ».

[wogns3623]

Il y avait donc un bon terme : « Critical Thinking ».

[lighteach]

Cela m’a vraiment beaucoup aidé. Merci pour cet excellent article.

[kylian]

Alors, il suffit de demander à un LLM de lire la documentation officielle !

[dudlf016]

Lisez la documentation officielle, bon sang.

[kandk]

On dit que ce n’est pas une checklist, mais je vais quand même en faire ma propre checklist.

[haejuk99]

Je suis tout à fait d’accord sur le fait qu’il faut absolument consulter la documentation officielle.

[aer0700]

Quand on commence à enseigner le code, j’ai l’impression que l’aptitude à devenir programmeur se révèle d’abord dans la capacité — ou non — à lire attentivement les messages d’erreur.

[postinsight]

.... Les gens qui n’ont pas cette compréhension de base — reconnaître que les erreurs et les bugs existent toujours — sont des imposteurs.

[roxie]

Les phrases sont trop difficiles..

[postinsight]

Sur le Web.

[coremaker]

Ce ne sont pas tous les points, mais la plupart parlent probablement à beaucoup de monde.

[GN⁺]

Commentaire Hacker News

• Ne pas faire de suppositions est ce qu’il y a de plus important dans le métier

  • A développé ses capacités de résolution de problèmes dans la fabrication de semi-conducteurs, où le coût d’une hypothèse erronée est très élevé
  • Il faut toujours comprendre à 100 % la cause racine
  • La raison d’éviter des stacks techniques atypiques est qu’elles entravent l’analyse de la cause racine
  • Résoudre précisément les problèmes est le moyen le plus rapide de se bâtir une réputation

• Lorsqu’il s’agit de quelque chose de nouveau, il aime faire un peu de conjecture avant de lire en profondeur la documentation de référence

  • Quand il apprend un nouveau langage ou une nouvelle API, il fait des hypothèses via des tutoriels puis lit la documentation de référence
  • Il préfère les langages et IDE qui prennent en charge des fonctionnalités comme Intellisense

• Il vaut mieux consulter directement les sources plutôt que de dépendre de Stack Overflow ou des LLM

  • Comme un livre de mathématiques, c’est difficile au début, mais on finit par comprendre avec le temps
  • Les docs Rust sur docs.rs, hoogle pour Haskell et la référence C++ sont d’excellentes ressources de référence

• Les meilleurs développeurs communiquent et apprennent avec des personnes de tous les niveaux

  • Les nouvelles personnes apportent un regard neuf, et les obstacles du passé ont peut-être disparu
  • Il faut vérifier périodiquement pourquoi les règles existent

• Bien utiliser Stack Overflow peut être d’une grande aide

  • Les LLM sont utiles pour analyser des événements en temps réel ou pour l’automatisation, mais ils ne peuvent pas remplacer les programmeurs
  • Une fois le sujet compris grâce aux LLM, il vaut mieux consulter la documentation officielle

• Les meilleurs programmeurs peuvent obtenir d’excellents résultats même sans formation en informatique

  • Il existe des cas de personnes non issues de la filière qui ont appris la programmation et progressé rapidement

• Au-delà de la programmation, la communication avec le domaine métier est aussi importante

  • Il faut prendre en compte divers éléments au-delà de la programmation

• Lire et comprendre les messages d’erreur aide beaucoup à résoudre les problèmes

  • En utilisant asdf pour gérer les versions de Python, Go et NodeJS, il a été possible de résoudre des problèmes grâce aux messages d’erreur

[postinsight]

Qu’est-ce que asdf ? Il faut regarder les avertissements.

[postinsight]

Eh bien, il me semble qu’avoir l’attitude de ne jamais vouloir devenir le meilleur absolu est préférable. Écrire, aider… parmi les gens qui font ça...