L'équipe, les Devs et l'effet Tunnel
On parle d'équipe techniques, de la maturité d'une équipe technique, de culture tech, et de culture des entreprises tech, de culture des équipes de devs. Et surement pas de métro !
Salut 👋
Cela fait un peu longtemps que l'on a pas fait un article de fond.
Il se trouve que l'article "Développeurs, apprendre est notre métier" a même plus d'un an.
C'est pas pour autant qu'on ne s'est pas parlé. En un an, on s'est vu à des conférences, a des meetups, on a échangé des emails et des tweets. Ce qu'il y a d'intéressant avec ce type d'articles, c'est qu'il a donné lieu à beaucoup de conversations. Parce que dans le fond, il est en quelque sorte inachevé et chacun écrit la fin. Celui-ci à la même ambition 😀
On a aussi beaucoup travaillé, en fait. Chaque développeur qui s'inscrit sur JeChercheUnDev.fr est une nouvelle rencontre ! On a aussi passé beaucoup de temps à chercher vos jobs de rêve. Et en fait, comme chaque dev en a un différent, il nous faut rencontrer beaucoup d'entreprises. Plus de 1200 entreprises utilisent notre outil maintenant. D'ailleurs ça a beaucoup changé chez nous ! Il n'est plus nécessaire de s'inscrire pour découvrir son job de rêve. Tu peux déjà explorer plus de 200 entreprises qui te présentent leurs équipes, t'expliquent pourquoi travailler avec elles c'est fantastique. Et c'est au bout de tes doigts, il suffit de cliquer ici ⚡!
Et ce n'est qu'un début. Bientôt, beaucoup d'autres entreprises seront disponibles, on va ouvrir de nouveaux horizons, proposer de nouvelles fonctionnalités, beaucoup de choses excitantes arrivent ! Il est temps de fermer cette introduction.
Rencontrer ces entreprises, c'est aussi et surtout rencontrer les personnes et les équipes derrière la job description. Et j'ai pu observer une forme de biais, j'ai mis longtemps à trouver le mot à mettre dessus. Je suis assez convaincu qu'on l'a tous vu. Il transparait par des petites phrases ou des situations que vous allez reconnaitre.
Histoires d'effet Tunnel 📖
📖 Pour commencer, dans le processus de qualification d'un futur collaborateur pour votre équipe, vous allez probablement lui demander de produire un code et l'évaluer objectivement. Peut-être allez vous faire passer ce code dans votre usine logicielle pour qu'il en ressorte plein de non-conformité. Peut-être allez vous simplement faire un jugement. Le plus souvent vous allez trouver ce code sale. Évaluer un candidat sur sa capacité à indenter le code, c'est quand même bien incongru, et pourtant relativement courant ! On chasse les devs qui codent avec le cul. "J'ai récupéré le code d'un freelance, il était crade !", "ce Dev il a bossé dans notre équipe, il était mauvais".
Alors oui, il y a des Devs qui indentent super mal leur code. A la fin de la journée, on est quand même tous d'accord, le code bien indenté c'est mieux. Personne ne s'est jamais opposé violemment à la thèse "Le code, c'est mieux si les autres aussi peuvent le lire". C'est pour ça qu'on se pose des conventions. Et ces conventions peuvent même changer d'un projet à l'autre. Bien que je préfère les tabs, si j'intervient sur un projet legacy qui est indenté avec des espaces, je vais suivre la convention. Dans l'absolu, si un Dev n'est pas capable de s'adapter aux conventions de l'équipe, on aura le temps de le voir bien avant la fin de la période d'essai.
La majorité du code "sale" a été produit dans un mauvais contexte, pas par de mauvaise personnes.
📖 On m'a demandé une fois du feedback sur un ancien collaborateur. Franchement, tout le monde trouvait qu'il codait avec le cul, je n'ai pas vérifié moi-même, c'était admis dans l'équipe. Mais en même temps, il était en conflit plus ou moins ouvert avec le manager qui lui filait tous les projets pourris. Du coup, j'ai rien dit, je suis convaincu que dans une bonne boite, il codera bien.
📖 Une appli que j'ai repris pour une petite intervention utilisait les SharedPreferences comme une BDD. En discutant avec le mec par DM : "Oui, mais à la base c'était un prototype, ça devait pas aller en prod". Le dev qui est passé après faisait pas du code ouf. J'ai ensuite appris que c'était une dev russe payée 400€/mois pour bricoler doucement quand elle avait le temps et qu'on lui demandait principalement de rafistoler. Ça me parait logique finalement que le code soit pourri. Du coup, j'ai compris pourquoi le premier dev était parti du jour au lendemain et j'ai arrêté de collaborer avec ce client aussi.
📖 Une fois dans mon équipe, un de mes collègues avait codé un truc pas très canonique. Il avait surchargé une méthode du Controller du SDK iOS pour implémenter une feature et ça m'avait complètement chamboulé. C'était très offusquant. J'étais contrarié parce que j'avais dépassé le temps alloué à ma story. On a unanimement condamné cette pratique. C'était clairement manquer de recul. Le Dev qui avait fait cette implémentation, ça ne le choquait pas. Il y a moins de 6 mois il était dans une autre équipe (une entreprise à 3 lettres pour ne pas la citer), et les devs iOS faisaient tous ça. C'était pas du tout offusquant de fait, c'était même une convention.
📖 C'est aussi une chose qu'on retrouve dans les équipes qui ont fait des choix techniques un peu ésotériques. Par exemple, une équipe de devs qui fait du Go à fond depuis bientôt 1 an ou deux. Ils ne parlent que de ça, ils ne jurent que par ça. Et de fait, ils cherchent à embaucher des gens qui sont absolument aussi bon qu'eux sur le Go. Parce que forcément, tous les candidats qu'ils rencontrent sont assez néophytes. De fait, il y a plein de choses qui ne leur plaisent pas dans le code que peut produire quelqu'un de moins aguerri. En même temps, c'est légitime de vouloir travailler avec des gens qui nous tirent vers le haut. Il faut rester réaliste quand même. Des gens qui ont plus de deux ans d'expérience en Go sur Lille, y'en a pas beaucoup. Je pense qu'on peut rassembler tout le monde autour de deux appareils à raclette.
📖 Vous avez aussi surement entendu la phrase "Oui, mais il sera pas opérationnel tout de suite". C'est ce que dit le C(T/E)O d'une startup Ruby On Rails quand un chasseur lui présente un développeur junior alors qu'il cherche un "dev Rails avec au moins deux ans d'expérience".
Je ne veux pas ici, stigmatiser la communauté des développeurs Ruby. Cet exemple est également transposable avec le développeur Symfony, le développeur Spring Maven ou même le développeur DotNet et tout autre technologie (même javascript 🎃).
Si vous ouvrez un poste pour un développeur Ruby On Rails aujourd'hui ou si vous comptez le faire bientôt, voici un état des lieux pratique: il y a des entreprises avec des postes ouverts depuis plus de deux ans. Toutes les fiches de postes demandent au moins deux ans d'expérience. Si à l'époque où ces postes ont été ouverts, on avait embauché des juniors, ils auraient 2 ans d'expérience aujourd'hui, mais le poste est toujours vacant. C'est une bonne raison pour investir aujourd'hui ! Embauchez un junior et faites-le monter en compétence 👍
📖 On peut mentionner rapidement sur le proverbe que martelais mon prof à l'Université Québecoise : "L'ouvrier qui n'a dans sa trousse à outil qu'un marteau trouve que tous les problèmes ont des têtes de clous". C'est le cliché du développeur C qui code tout (java, python, javascript) comme si c'était du C, ou de l'équipe qui arrive à mettre un MongoDB pour résoudre tous les problèmes. Cliché transposable avec PostgreSQL ou MySQL.
📖 On a également tous entendus le discours : "On a pas les même contraintes, on a pas les même problématiques". Je pense que ce qui caractérise un ingénieur, c'est sa fascination pour l'over-engineering. Et ce n'est pas grave dans le fond. C'est toujours fascinant quand une équipe explique pourquoi elle a utilisé une bombe H pour écraser un moustique. (Lire en anglais ou en java)
📖 J'ai aussi entendu un Lead Dev Junior dans une PMEInnovante expliquer à son patron que ça fait deux semaines qu'ils font des tests, parce que les tests ça évite les bugs.
Je n'ai jamais entendu "Hier soir, on est passé sur Capital, heureusement qu'on avait fait des tests !"
C'est quoi la bonne statistique ?
Il y a 90% de chances pour qu'une Startup n'atteigne pas sa masse critique d'utilisateur ? Chiffre absolument pas vérifié, mais qui atteindra une sorte de consensus.
S'il y a 9 chances sur 10 pour que personne n'utilise ce soft, est-ce bien raisonnable de passer la moitié de son temps écrire et maintenir des tests ?
NB : Les tests c'est quand même utile. Si la recette avant mis en prod requiert 5 J/H, c'est dommage de pas automatiser un minimum avec des tests d'intégration anti-régression. Il faut pouvoir mettre en prod l'esprit serein !
Qu'est-ce que l'effet Tunnel ? ✍️
✍️ L'Effet Tunnel, en Physique Quantique, c'est ce moment où la fonction d'onde autorise, par réfraction, à ce qu'une partie infiniment petite de la matière de ma main passe au travers de la vitre lorsque je la pose dessus.
✍ ️Dans le monde #LeanStartup c'est un phénomène connu comme l'isolement par rapport à ces utilisateurs. Si tu fais une itération sans faire de validation, tu es surement dans un effet tunnel. Si ton produit n'a pas vu d'utilisateurs depuis longtemps, c'est surement un effet tunnel. Parfois, on fait même des expérimentations pour se convaincre qu'on est pas dans l'effet tunnel. L'effet tunnel, c'est un peu le Némésis de l'entrepreneur. Il serait tapis dans l'ombre, ou pas, on ne sait pas. Mais on sait que c'est à cause de lui si l'on rate le #MarketFit.
En pratique, tant qu'on a pas la possibilité de mesurer sa traction avec des chiffres relativement objectifs (traffic, nombre d'utilisateurs, CA), il y a vraiment beaucoup de chances pour qu'on soit dans un effet tunnel à proprement parler.
✍️ Si vous êtes à l'aise avec le Confirmation Bias. L'effet tunnel est relativement soit un subset, soit un complément du Confirmation Bias.
✍️ Dans la culture anglo-saxone, l'effet tunnel est souvent nommé Tunnel Vision, et Urban Dictionnary en a une définition simple, illustrée d'une citation très parlante :
“He isn’t even considering any of the other solutions to the problem because of his tunnel vision” — Tunnel Vision, Urban Dictionnary
On le retrouve même dans la culture Rap US. Je pose le lien ici tout spécialement pour Raphaël Thobie : https://www.youtube.com/watch?v=JzSUgOmP66Q
✍️ Comment ça se manifeste pour les développeurs ? C'est toute les fois où on a passé du temps à coder pour la beauté du code et que ça n'a pas apporté de valeur aux utilisateurs. NDLR : Il faut lire le passage suivant en chanson :
"Ça fait 6 semaines que je fais du refactoring et que j'ai pas mis en prod"
- Effet Tunnel !
-J'ai commencé cette feature, mais en fait le paquet npm est tout pourri, ça fonctionne pas et je mouline depuis 3 jours
- Effet Tunnel !"
✍️ Je ne dis pas que le refactoring est fondamentalement inutile. Ce qui est utile c'est du code qui marche en prod. Et du code sale qui marche en prod, a beaucoup de chances de se casser la figure et de pénaliser des utilisateurs. Le code en prod qui marche, et on sait pourquoi, c'est toujours mieux que le code qui marche, mais on sait pas trop pourquoi.
C'est aussi toutes les fois où on fait un choix technique par confort. En option, on peut essayer de trouver un besoin métier pour le justifier : "Vu la charge qu'on a, un Spring avec JPA c'était nécessaire, un Rails aurait jamais tenu !" (Et ça c'est du beau confimation bias). Ou pire, et j'épargne l'auteur de cette citation d'une mention : "On recode tout le serveur en Node, parce que le Laravel [qui est en prod] c'est lent (normal, il y a du Symfony dedans)".
This is BS 💩💩💩
Les remèdes à l'Effet Tunnel 💡
Beaucoup de Startups ou de petites entreprises n'ont pas vraiment de CTO. Elles ont au mieux un Lead Dev et un CEO. Un CTO dans l'absolu a pour coeur de métier le "People Management". Ce n'est pas forcément le meilleur codeur de l'équipe. Ce n'est pas le plus sénior et ne ce n'est pas non plus celui qui est au sommet d'une hiérarchie (comme si les autres devs étaient des mignons oeuvrant sous la baguette d'un CTO). Il prend par contre pas mal de responsabilités, ou du moins il assume des conséquences. C'est aussi quelqu'un qui a un rôle important dans le dialogue interne de l'entreprise et la stratégie. C'est souvent ce que l'on doit entendre derrière "Je cherche un CTO" : "Je cherche quelqu'un avec qui parler stratégie et produit, sans me noyer dans la technique et quelqu'un qui assume les conséquences des mauvais choix techniques.
En vrai, la majorité des entrepreneurs non-techniques peuvent très bien s'en sortir sans CTO, avec une recette simple, à base particulièrement de bienveillance et en mettant à disposition de l'équipe tech les outils pour se soustraire à l'effet tunnel.
💡 Ingrédient simple : Faites appel à un Expert. Un freelance ou un consultant qui va prendre le temps, rentrer dans le code, faire un mini-audit, un rapport d'étonnement. Si c'est une équipe de dev Android, tu peux demander à un GDE de venir faire une journée de formation/audit, où il passe du temps avec l'équipe. C'est pas forcément que vous ayez besoin d'un expert, mais au moins rajouter de l'exogène (qui vient de l'extérieur, qui est étranger) dans l'environnement c'est important !
💡 Faire en sorte que de temps en temps, un dev d'une autre boite vienne et s'assoit, ne serait-ce que 30 minutes pour regarder le code, échanger sur une problématique. Ça apporte encore une fois de l'exogène, un regard extérieur.
C’est aussi l’intérêt d’avoir ses locaux sur un pole, une zone d’activité. Avoir des locaux dans un IT Park, une zone d'activité ou un Hub comme Station F, si c’est pour en faire une tour d’Ivoire et y enfermer ses devs de peur de se les faire piquer, c’est contre-productif. C'est pourquoi des initiatives comme le Club_Tech sur Euratech apportent beaucoup de valeur !
💡 C'est aussi pour ça que les meetups et les conférences sont importantes. Aller une fois par an passer deux trois jours à Devoxx, Mix-IT pour les Lyonnais, TakeOff pour les plus acrobates, un des nombreux DevFest, ou pour voir comment les gens codent dans les autres boites c'est pas du luxe, c'est relativement incontournable !
L'Effet Tunnel, on est dedans aussi quand on a tendance rejeter toutes les recrues potentielles parce qu'elles sont trop néophytes. C'est pourtant peu compatible avec le Craftmanship. On devrait tous avoir en place le mentoring et les pratiques qui permettent à tout développeur de prendre en main les outils et technos de l'équipe. On veut tous travailler dans une équipe qui nous tire vers le haut. C'est même pour beaucoup un critère pour définir un job de rêve : "Est-ce que ce job va me faire progresser ? Est-ce qu'il me pousse à donner le meilleur de moi-même ?". Embaucher un Dev junior ou néophyte ça ne devrait pas être un problème. On a entendu Clément Delafargue, dans un plaidoyer pour les Microservices, dire : “Quelqu'un qui débarque chez nous, est capable de balancer du code en prod extrêmement rapidement”. A choisir, je préfère ça comme idéal !
Cela veut aussi dire qu'on doit se soigner du syndrome de l'imposteur pour candidater. Il ne faut pas croire que les experts ne veulent travailler qu'avec des experts. La majorité des "grosses pointures" que j'ai pu rencontrer sont particulièrement content de partager. Ils ont été néophytes aussi et apprendre a été une expérience fantastique pour eux. Transmettre et aider d'autres à apprendre est également un moyen efficace pour eux de maintenir et approfondir leur maitrise du sujet. C'est vraiment un Win-Win.
💡 : N'ayez pas peur de candidater à une annonce parce que vous êtes sous-qualifié. Si le marché est vraiment en pénurie, un dev avec 3 ans d'expérience doit pouvoir prendre un poste qui en affiche 6 en pré-requis.
Pour revenir aux pratiques Craftmanship, c'est aussi arriver à construire une ambiance où tout le monde se sent à l'aise pour poser une question, dire qu'il ne sait pas faire quelque-chose et demander à ce qu'on l'aide, où demander une code review parce qu'on cherche à progresser sur son code est une chose valorisée. En soit, c'est une forme de safe zone, où l'on a pas peur de se sentir vulnérable. Il n'y a pas de secret pour y arriver, c'est la responsabilité de tous, chaque détail compte, et chaque effort fait une différence.
L'effet tunnel, comme tous les biais, est toujours là. Il faut donc d'abord l'accepter. Une fois que c'est fait, on peut mieux le distinguer, le cerner et l'analyser. Si vous êtes capable de vous demander régulièrement "Est-ce qu'on serait pas dans un effet tunnel ?" et de prendre des mesures pour éviter le biais c'est déjà très bien. Par exemple, on essaye de ne pas entreprendre une fonctionnalité qu'on ne saurait pas mettre en prod le jour même. Déjà parce que dans le cas contraire, ça fait diverger la codebase de manière importante, mais aussi parce qu'il y a des chances pour que la fonctionnalité ne soit pas utile ou pertinente. Une fois qu'on voit qu'elle est utilisée, on prendra le temps de la réfactorer ou même on la repensera complètement. On est pas super rigoureux sur la question, mais quand on est bloqué sur une feature plus d'une journée, on a rapidement la sensation d'effet tunnel, et c'est bien.
Bon je dis pas que vous devriez faire ça demain dans votre équipe ! C'est notre sauce secrète : "On commence par la trottinette". J'imagine que l'effet tunnel a une forme différente en fonction du type d'équipe (SaaS, Editeur, service, DSI) et des tailles d'entreprises. Et donc des solutions et des bonnes pratiques différentes.
Je voudrais beaucoup connaitre vos expériences sur le sujet ! Est-ce que vous avez déjà ressenti cette situation d'effet tunnel ? Quels remèdes avez-vous trouvé ? Quelles sont vos pratiques anti-effet tunnel ? Vous pouvez commenter l'article pour partager ! ❤
Si tu as aimé ce contenu tu dois mitrailler le bouton Clap à gauche ! C'est nouveau sur Medium, maintenant tu peux clapper l'article un millier de fois si tu le veux.
Last thing. On a des choses très très chouettes à vous annoncer et vous aller adorer ! On vous en parlera en premier ici. Alors assurez-vous de bien suivre la publication.
