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