Confessions d’un développeur logiciel : plus d’autocensure

• Pendant plusieurs mois, un développeur qui avait cessé d’écrire et de participer en ligne par peur explique qu’il a décidé d’arrêter de s’autocensurer et de reconnaître enfin ses lacunes techniques et personnelles qu’il n’arrivait pas à admettre
• Il reconnaît n’avoir pas compris le concept de polymorphisme pendant plus de dix ans, avoir perdu son niveau en SQL et avoir déployé la plupart de son code sans tests automatisés
• En essayant de suivre l’évolution de la stack technique de son entreprise, il a abandonné l’apprentissage de C# et de Blazor, continue de préférer Ruby sans pouvoir l’utiliser professionnellement, et décrit le poids psychologique ressenti en sachant que ses managers et collègues lisent son blog
• Il raconte avoir subi du cyberharcèlement après avoir soumis une PR rédigée avec de l’IA, partage son ressenti sincère sur le travail à distance et son opinion franche sur l’inutilité de processus de développement sur mesure dans une organisation
• Il conclut en promettant de laisser tomber la peur et de poursuivre, sans plus d’autocensure, l’apprentissage continu et l’écriture en public

---

Début : pourquoi j’ai décidé d’arrêter la peur et l’autocensure

• Depuis avril, il y a eu une période où j’avais trop peur pour publier quoi que ce soit, au point de couper totalement les réseaux sociaux, les agrégateurs d’actualités et les forums
  • J’ai fini par sentir que je ne pouvais pas continuer ainsi, et j’ai décidé de recommencer à écrire malgré la peur
• J’ai longtemps tout fait pour cacher mes lacunes de base, mais j’ai fini par voir qu’en réalité beaucoup de développeurs travaillent avec des trous de connaissances comparables
  • Ma manière d’apprendre jusqu’ici ressemblait à un myxomycète qui grossit uniquement dans les zones qu’il utilise, tandis que le reste des connaissances se desséchait
• Récemment, j’ai recommencé à reconstruire ces bases, et en reformulant ce que j’apprends à l’écrit et à l’oral, la capacité à reconnaître tranquillement que “je ne sais pas” commence à s’installer
• En ressentant directement que l’on peut réapprendre les fondamentaux, j’ai acquis la conviction qu’il n’est jamais trop tard

Plus de dix ans sans vraiment comprendre le polymorphisme

• Depuis 2012, je pensais écrire du code orienté objet, mais j’ai dû reconnaître que jusqu’à il y a encore un an, je ne comprenais pas vraiment le polymorphisme
  • J’ai dû faire face au fait que le code que j’écrivais jusqu’ici relevait moins de l’orienté objet que de la programmation structurée
  • L’idée de remplacer des conditions par des classes pour faire évoluer la conception ne m’était jamais venue
• En lisant Sandi Metz et des ressources de Martin Fowler, j’ai fini par comprendre le concept sur le tard, et il est devenu évident que j’étais passé à côté de beaucoup de choses

• Pourquoi il m’était difficile de révéler cela

  • J’ai souvent eu, en entretien d’embauche, la responsabilité d’évaluer la compréhension des concepts orientés objet, et révéler que je ne connaissais pas vraiment le polymorphisme m’a paru très lourd
  • Cela montrait au grand jour qu’au début de ma carrière, j’avais privilégié les outils plutôt que les principes, et il n’a pas été simple d’affronter le fait qu’avec un parcours non issu d’études en informatique, j’avais raté énormément de bases

L’expérience d’avoir oublié le SQL

• Il y a bien eu une époque où je suivais des livres de SQL et résolvais des exercices, en écrivant avec aisance des JOIN et des sous-requêtes
• Puis, à force de travailler surtout côté front-end et de ne plus utiliser SQL du tout, j’ai fini par réaliser qu’une compétence entière avait disparu de ma mémoire
  • Les requêtes de base me reviennent, mais si je dois expliquer la différence entre left join et outer join, je dois rouvrir la documentation

• Pourquoi il m’était difficile de l’admettre

  • Quand j’étais plus jeune, je croyais que même après des années, les faits et les compétences revenaient en mémoire avec un simple petit indice
  • Je ressens maintenant que cette capacité ne reste pas intacte, et le fait que SQL ait été la première compétence à disparaître complètement de ma mémoire m’a fortement marqué
  • Il n’a pas été facile d’écrire publiquement sur le vieillissement et l’évolution du fonctionnement de la mémoire

La réalité d’avoir développé sans tests automatisés

• Je reconnais que plus de 95 % du code que j’ai livré fonctionne en production sans tests automatisés
  • Au début de ma carrière, je n’avais jamais été exposé à la notion de test, et à l’époque d’Ember, il n’était pas simple de bien exploiter les outils de test
• Ces derniers temps, je travaille souvent sur du legacy code, et je n’ai pas assez de temps pour préparer le terrain afin de rendre le code testable
  • Je n’ai pu ajouter des tests que dans des sous-systèmes développés plus récemment

• Pourquoi il m’était difficile de révéler cela

  • J’avais le sentiment que cet aveu était le plus dommageable pour ma carrière
  • Selon les critères d’Uncle Bob, faire tourner du code sans tests peut relever d’une attitude jugée non éthique, et affronter l’écart entre cette norme et ma réalité me faisait peur
  • Je pensais que si cela devenait public, cela pourrait jouer contre moi dans les recrutements, au point de retarder l’écriture même de mes notes d’apprentissage

Pourquoi je n’ai pas appris Blazor

• Quand l’entreprise a décidé de passer d’Angular à Blazor, j’étais la seule personne de l’équipe sans expérience en C#, et j’ai commencé à étudier en urgence pour rattraper mon retard
• Quelques mois plus tard, la décision de migration a été annulée, et toute ma motivation d’apprentissage a disparu d’un coup : je n’ai même pas terminé le livre
• À l’origine, C# et .NET n’étaient pas des technologies que j’avais envie d’utiliser dans mes side projects ; j’étudiais uniquement pour le travail, et cela s’est révélé tel quel

• Pourquoi il m’était difficile d’écrire cela

  • Dans un article précédent, j’avais explicitement promis une suite, et écrire autre chose sans avoir tenu cette promesse est devenu de plus en plus inconfortable
  • Comme mes billets sur Blazor avaient eu beaucoup de vues, j’avais peur qu’admettre ce changement de direction ressemble à une défaite

L’envie d’utiliser davantage Ruby

• Ruby reste aujourd’hui encore le langage avec lequel je suis le plus à l’aise et que je trouve le plus agréable ; c’est naturellement celui vers lequel je me tourne pour des exemples, de l’open source, des katas et des hackathons
• Pourtant, depuis 2013, je n’ai pas été payé une seule fois pour écrire du Ruby, et au travail j’utilise des langages comme TypeScript
• J’apprécie tellement les collègues avec qui j’ai travaillé dans plusieurs entreprises que j’ai continué à faire des compromis sur le langage pour choisir les personnes
• J’aimerais consacrer mes soirées et mes week-ends à Ruby, mais entre d’autres obligations et d’autres objectifs d’apprentissage, j’ai en réalité très peu de temps pour en faire suffisamment

• Pourquoi il m’était difficile de le dire

  • Mon manager et mon CTO lisent ce blog, et j’avais peur que dire que je veux faire plus de Ruby soit interprété comme un signal de départ
  • Je ne voulais pas non plus donner l’image de quelqu’un qui cherche à imposer au travail un langage qu’il ne maîtrise pas encore dans ce contexte

Le cyberharcèlement fait encore mal, même à l’âge adulte

• Après avoir soumis à un projet open source un petit patch généré avec un LLM et partagé cette expérience sur un forum en ligne,
  j’ai vu déferler des attaques personnelles du type incompétent, répugnant, dangereux
• Les attaques ont dépassé le site pour s’étendre à d’autres sites web, aux e-mails, aux SMS et aux appels téléphoniques, me donnant très concrètement le sentiment de ne plus être en sécurité
• J’ai demandé aux administrateurs du forum de retirer mon nom réel, mais davantage de PII ont au contraire été ajoutées à mon profil,
  et je me suis retrouvé avec une mention mensongère permanente affirmant que j’avais inventé l’histoire des prises de contact externes
• J’ai fini par devoir désactiver mon compte et quitter le site

• Pourquoi il m’était difficile d’écrire cela

  • Ce harcèlement qui a duré plusieurs jours a été l’expérience en ligne la plus toxique que j’aie connue, et ses effets persistent encore
  • J’ai toujours peur qu’en racontant cette histoire, les harceleurs reviennent me chercher
  • Penser que les fausses informations laissées sur mon profil pourraient nuire à mon employabilité rendait la chose encore plus difficile à dire

Pourquoi je pense qu’une équipe SaaS n’a pas besoin d’un « processus spécial »

• L’industrie du logiciel dispose déjà de processus affinés depuis des décennies,
  et des approches comme Agile, Lean, Kanban ou XP constituent des cadres déjà éprouvés
• Il m’a donc semblé naturel de considérer qu’il valait mieux consacrer les capacités limitées d’une entreprise au développement du produit plutôt qu’à inventer un nouveau processus

• Pourquoi il m’était difficile d’exprimer cette idée

  • Quand j’écris, j’ai toujours tendance à partir de sujets que je connais bien, et ici le déclencheur avait été un processus de développement logiciel sur mesure proposé par un collègue de la même entreprise
    • J’avais peur que cela ressemble à un texte critiquant publiquement une personne précise ou son idée
  • J’envie chez des auteurs comme Kent Beck ou Martin Fowler la capacité à expliquer de meilleures façons de collaborer sans pour autant viser frontalement un collègue qui s’est trompé
    • J’ai le sentiment de ne pas encore avoir trouvé cet équilibre, ce qui m’a fait hésiter à écrire

Comment le travail à distance freine la collaboration réelle

• Le travail à distance résout beaucoup de problèmes, mais je n’arrive pas à me défaire de l’impression que le développement logiciel fonctionne mieux quand les gens partagent le même espace
• Les appels vidéo sont une communication à faible bande passante et à faible richesse sensorielle, et la perte de perception périphérique rend plus difficile le repérage des difficultés des collègues
• Demander de l’aide devient aussi plus coûteux, et les formes de réflexion spatiale avec tableaux blancs ou post-it se cassent facilement dans les outils en ligne
• Les conflits ont aussi tendance à s’aggraver plus vite, car il est plus facile de projeter une image d’ennemi sur une personne derrière un écran

• Pourquoi il m’était difficile d’écrire cela

  • Après le Covid, l’entreprise est devenue totalement à distance, ce qui m’a permis de mener une vie avec 27 acres de terrain et même une vache laitière pour la famille
  • Comme mon mode de vie rend difficile un retour en ville, dire que je ne préfère pas le travail à distance me donnait l’impression
    de nuire à mon image dans mon poste actuel comme dans tous les futurs emplois full remote auxquels je pourrais postuler

Et maintenant

• Avec ce texte, j’ai le sentiment d’avoir refait un premier pas pour dépasser la peur,
  et je compte continuer à travailler mes bases tout en écrivant ouvertement tout ce que j’apprends
• Pour les personnes qui ont vécu des expériences similaires, celles qui veulent aider, ou celles qui attendent le prochain billet,
  j’indique qu’elles peuvent suivre les nouvelles via Mastodon, RSS ou la mailing list

[GN⁺]

Avis Hacker News

• J’ai appris quelque chose d’un collègue très intelligent. Il n’a pas peur de ce qu’il ne sait pas et continue à poser des questions jusqu’à comprendre. J’ai trouvé impressionnantes la confiance et la patience nécessaires pour apprendre en public
• J’ai aimé l’humilité et l’honnêteté du texte. Il n’y a pas à avoir honte de ne pas savoir. Cela fait 37 ans que j’apprends, et je continue encore à découvrir de nouvelles choses.
  Moi aussi, je préfère travailler au bureau, mais cela ne signifie pas que je défends le RTO (retour au bureau). C’est simplement mon tempérament.
  On dirait que l’anxiété du secteur et le syndrome de l’imposteur rendent les gens agressifs. Si tout le monde était plus honnête, on se sentirait sans doute plus à l’aise.
  Et pour être honnête, je n’ai jamais écrit en Lisp ou en Haskell quelque chose de plus complexe que Fibonacci. Mon cerveau ne fonctionne tout simplement pas comme ça
  • Je ne suis pas d’accord avec ton avis sur le télétravail, mais comme tu l’as présenté comme une opinion personnelle, je n’y vois pas de problème.
    En revanche, le texte d’origine généralise sa propre expérience comme s’il s’agissait d’une vérité objective. Le recours à la deuxième personne, en particulier, m’a paru arrogant.
    La manière de le dire compte autant que le fond. Sur un sujet sensible comme le télétravail, il faut faire attention à la formulation.
    J’ai moi aussi dû télétravailler pour des raisons de santé familiale, donc le ton du texte m’a semblé léger et cela m’a mis en colère.
    Au final, avant de dire que les gens surréagissent, il faut d’abord réfléchir à l’effet que peuvent avoir ses propres mots
  • Moi non plus, avant de rejoindre un projet basé sur Lisp, je ne savais rien écrire au-delà de Fibonacci. À force d’en faire tous les jours, je m’y suis finalement habitué
  • Si on se fait attaquer quand on dit préférer le télétravail, c’est peut-être parce que les personnes qui ont gagné en liberté après le Covid ont l’impression d’être à nouveau contraintes. D’où, sans doute, cette forte réaction
  • En ce moment, les gourous du code sur YouTube affirment tous qu’ils ont raison sur tout. Quoi qu’on fasse, on a tort
• Chaque fois que j’entends parler de télétravail, l’époque d’IRC me manque. À l’époque, on collaborait déjà très bien à distance.
  Au lieu de conversations de couloir, on résolvait les problèmes dans le chat d’équipe, et tout le monde aidait activement.
  J’ai même l’impression qu’aujourd’hui, on utilise moins bien les outils qu’avant
  • Aujourd’hui, beaucoup de gens ont peur d’écrire dans les canaux publics. Avant, il y avait de l’anonymat, alors que maintenant tout repose davantage sur l’identité réelle, donc chacun est plus prudent.
    Avec la diminution des espaces où l’on peut parler anonymement, une culture où il devient difficile de s’exprimer librement s’est installée
  • Avant, quand on utilisait Slack au bureau, c’était bien plus efficace qu’aujourd’hui.
    Si ça coinçait, il suffisait d’aller voir la personne à côté ; maintenant, si ça échoue, ça s’arrête là
  • Le télétravail pendant le Covid n’était pas du vrai télétravail. C’était un état d’isolement, et ni la culture ni les processus n’étaient prêts.
    Du coup, les gens ont attribué leur solitude au télétravail
  • Je pense que la cause du changement tient moins à la démographie qu’à une évolution des personnalités. Avant, il y avait plus de « gamins bizarres », et ils n’avaient pas peur de poser des questions.
    Aujourd’hui, il y a davantage de personnes socialement plus calibrées, donc moins à l’aise avec la communication asynchrone
  • Corriger un bug par chat, ce n’est pas la même chose que « respirer le même air ».
    Comme la densité des signaux non verbaux est plus faible, il y a moins d’indices sociaux
• Même en étant dans le même secteur du SaaS, j’ai l’impression de vivre dans un tout autre monde.
  Beaucoup de développeurs suivent une trajectoire de carrière plus qu’un intérêt réel.
  J’ai réappris SQL à trois reprises. Comme la technologie change sans cesse, on ne peut pas tout retenir.
  Ce qui compte, ce n’est pas la syntaxe, mais la capacité à résoudre des problèmes et à collaborer.
  Je pense que l’IA aura du mal à remplacer cela
• 95 % du code que j’ai écrit avait une couverture de tests de 0 %. C’était pareil dans plusieurs pays et plusieurs entreprises. Je me demande si je suis le seul
  • Les tests automatisés sont un outil qui donne confiance quand on développe de manière répétée. Une fois qu’on y a goûté, on ne revient plus en arrière
  • J’étais dans un cas similaire, mais j’essaie de changer ça maintenant. Ajouter des tests plus tard dans un projet qui n’en a pas, c’est vraiment difficile
  • Les tests sont aussi parfois surestimés. Ils peuvent donner un faux sentiment de sécurité. Dans bien des cas, le langage lui-même n’est pas adapté aux tests
• L’ambiance des gens autour de moi quand ils travaillent m’aide à me concentrer.
  Il y a un effet contagieux de la concentration. Travailler dans le même espace améliore la productivité
  • Je suis du même genre. Mais mon entreprise impose une politique de bureau propre, et c’est pénible. J’ai besoin d’un environnement personnalisé
  • Je ressens un effet similaire dans les cafés animés. La productivité des autres me stimule
  • C’est proche du concept de « body doubling » lié au TDAH
  • Moi aussi, je préfère travailler au bureau, mais avoir une pièce avec une porte est indispensable.
    La porte est le meilleur outil pour réguler collaboration et concentration.
    C’est un signal bien plus clair qu’un statut « away » en ligne
  • Mais tout le monde ne travaille pas bien dans ce type d’environnement.
    Faire venir de force quelqu’un au bureau pour favoriser la concentration d’une autre personne, c’est inhumain
• Ce texte est courageux. Mais il montre aussi très bien le problème qu’il y a à généraliser une expérience personnelle.
  Le télétravail n’est peut-être pas mauvais en soi ; c’est peut-être simplement l’expérience d’avoir travaillé dans une entreprise où le système de soutien est mauvais
• L’auteur est trop dur avec lui-même. Reconnaître qu’on ne sait pas quelque chose procure un sentiment de libération.
  Moi aussi, je dis souvent « je ne sais pas ». C’est une caractéristique des personnes avec une forte intelligence émotionnelle
  • Mon manager aimait que je dise « je ne sais pas ». L’honnêteté crée la confiance
  • Au travail, ça passe, mais en ligne, il est plus difficile de dire « je ne sais pas » à cause de la peur pour sa réputation
  • Lorsqu’on demande en entretien ce qu’est git rebase, je pense que la capacité à s’en servir réellement compte plus que les détails techniques
• J’ai aimé la franchise de l’auteur. J’ai vécu quelque chose de similaire moi aussi.
  En faisant du live coding en Kotlin, je me suis retrouvé embarrassé parce que je n’arrivais plus à me rappeler la syntaxe de switch.
  J’ai alors compris qu’on peut vite oublier même un langage qu’on utilise tous les jours
  • Moi aussi, je vais vérifier la syntaxe de switch presque à chaque fois. Si on ne s’en sert pas souvent, c’est normal d’oublier
  • Quand il y aura davantage de développeurs plus âgés, on sera peut-être plus indulgents envers ce genre de « moments d’oubli »
  • Tout le monde fait des erreurs. Même un supérieur peut oublier le raccourci clavier pour coller
  • Quand on ne l’utilise pas souvent, une compétence se dégrade vite, mais elle revient aussi rapidement dès qu’on la réutilise.
    Les concepts restent longtemps, mais les détails de syntaxe s’effacent vite
• Au début, je pensais que le texte parlerait de la disparition des développeurs à cause de l’IA.
  Mais en réalité, il décrit une atmosphère où il est déjà difficile ne serait-ce que d’exprimer cette inquiétude.
  Moi aussi, j’aime écrire du code avec Claude, mais j’ai en même temps peur.
  Si nous sommes la génération qui comprend le mieux la nature des changements à venir, alors nous devons en discuter
  • Le code produit par Claude ne sera pas meilleur que celui d’un humain. En revanche, il augmente la vitesse de production.
    Le problème, c’est que cela augmente peut-être seulement la productivité des personnes peu compétentes
  • Pendant encore quelques années, nous resterons les team leads d’agents IA.
    Mais si les entreprises commencent à utiliser l’IA comme manager, il y aura de moins en moins de place pour les développeurs humains.
    Il faut commencer dès maintenant à préparer une transition vers des rôles du type consultant en efficacité IA
  • Pour ma part, je compte simplement collaborer avec l’IA ou faire autre chose d’intéressant. La programmation n’est pas tout
  • Une entreprise avec une politique de « AI doomer », c’est une culture d’entreprise toxique. Il faut chercher un autre poste tout de suite