Dans cet article, vous allez apprendre pourquoi les programmeurs sont mal compris, et comment communiquer avec eux pour travailler efficacement sur vos projets.
Pourquoi je peux vous en parler ? Parce que je suis développeur web pro depuis environ 10 ans, et que j’ai eu l’occasion de gérer plusieurs programmeurs.
 
Il faut bien comprendre que le cerveau d’un programmeur marche différemment de la plupart des gens.
Parce qu’écrire du code, c’est parler à la machine.
Et pour parler à la machine, il faut soi-même littéralement devenir un ordinateur. Pas 24h sur 24, mais au moins au moment où on va travailler.
Quand un programmeur travaille sur un gros projet, il faut en général une phase de 15-30 minutes pour qu’il « démarre ».
Ensuite, il sera dans un état de flow où il pourra travailler de manière efficace et avancer vite.
Pour démarrer, il a besoin se déconnecter du monde réel, commencer à penser comme un ordinateur et charger sa mémoire vive.
 
Il va devoir charger l’ensemble du code dans la partie « mémoire RAM » de son cerveau.
Je vais prendre un exemple.
Sur un projet comme LinkLead.io, j’ai littéralement des dizaines de fichiers différents qui contiennent du code.
Chacun a une fonction particulière (un fichier pour gérer les listes de prospects, une librairie pour deviner les emails, etc.)
Pour pouvoir entrer en état de flow, j’ai besoin d’avoir l’intégralité du projet en tête. J’ai besoin de savoir quel fichier contient telle ou telle fonction, et comment ils s’agencent entre eux.
Puis, quand je suis en état de flow, je peux me mettre à la place de l’ordinateur.
Je peux littéralement « voir » qu’une requête va appeler une fonction dans un fichier a, qui va faire un appel à un fichier b, etc. Je peux visualiser tout le code source s’exécuter dans ma tête.
Le problème, c’est qu’il faut faire un effort important pour rentrer dans cet « état de grâce ». Et que chaque interruption (même toute petite) risque de nous en sortir.
Beaucoup de programmeurs travaillent la nuit. Ils ont besoin de se déconnecter du monde réel pour être tranquille et rentrer dans le code. Et ça marche beaucoup mieux quand tout le monde dort.
(pour ma part, c’est plutôt très tôt le matin)
Donc quand on travaille avec des programmeurs, il y a plusieurs choses à savoir.
Déjà, vous l’avez peut être compris, interrompre un programmeur (pour lui poser une question, etc.) est la pire chose à faire.
Vous risquez de le sortir de son flow, et peut-être qu’il n’arrivera plus à y rentrer aujourd’hui. Une journée de perdue pour une petite question…
Si vous avez des questions ou des demandes, vous les notez dans un coin et vous attendez qu’il fasse une pause pour lui demander tout d’un coup. S’il se lève pour prendre un café ou discuter avec ses collègues, c’est le bon moment.
Deuxième point, les rendez-vous et réunions.
J’ai remarqué que j’avais beaucoup plus de mal à rentrer dans le code quand j’avais un rendez-vous à la fin de la journée. Aujourd’hui, j’évite les rendez-vous au maximum à cause de ça.
Comme je l’ai dit, il faut faire un effort important pour rentrer dans un état de flow, et aucun programmeur ne le fera pour seulement 1 heure ou 2. Il a besoin d’avoir du temps devant lui sans interruption pour pouvoir se déconnecter de la réalité.
Pire, si vous prévoyez une réunion au milieu de la journée (même si c’est juste 20 minutes), vous risquez de tuer complètement la productivité de votre programmeur. Il aura du mal à se mettre dans le code avant et après la réunion.
D’ailleurs, beaucoup de programmeurs vont vous demander de les laisser tranquille pour qu’ils puissent avancer. C’est à cause de tout ce que j’ai dit au-dessus. Sauf qu’il faut bien les garder « on track », savoir ce qu’ils font et où ils bloquent.
Ça m’est déjà arrivé de voir un programmeur partir complètement à la dérive, justement car je l’avais un peu trop « laissé tranquille ».
Une solution à ça, c’est de prévoir les réunions avec vos programmeurs avant qu’ils se mettent à travailler. Faire ça en premier le matin, par exemple (en méthodologie agile, ce serait le daily scrum meeting). Et traiter toutes vos questions et demandes.
Troisième point, les ajouts de fonctionnalité au dernier moment.
Le truc le plus énervant pour un programmeur, c’est un client qui demande à ajouter un bouton ou un champ texte au dernier moment.
C’est vrai, en général ça prend à peine 10 minutes. Le problème n’est pas là.
Le problème, c’est que la modification que vous demandez vient modifier l’ensemble du système.
À chaque fois que vous demandez une modification, il faut 10 minutes pour la faire et plusieurs heures pour repenser l’ensemble du système autour de cette modification.
Construire une application (comme LinkLead.io), c’est un peu comme construire une maison.
On doit penser l’ensemble du projet en un système cohérent.
Si un client nous demande au dernier moment de mettre un robinet dans la chambre ou des WC dans le salon, il faut repenser l’intégralité de la tuyauterie.
On peut mettre des tuyaux en carton en attendant et faire du bricolage, mais ça ne sera pas viable sur le long terme.
Il y a deux solutions à ça. La première, c’est de comprendre que chaque « petite » modification doit en fait amener votre programmeur à repenser l’ensemble du système (et c’est ce qu’un BON programmeur fera). Et qu’il faudra de toute façon y revenir plus tard.
La deuxième si vous n’avez pas le choix, c’est au moins d’implémenter un système de tests automatisés pour garantir la stabilité du système (et garantir qu’il n’y aura pas des fuites d’eau partout avec vos tuyaux en carton). Ça permettra de tenir sur le court-terme.
Donc pour résumer :
  • N’interrompez pas vos développeurs. Jamais. Si vous avez des questions, gardez les pour la prochaine pause et posez-les « en lot ». Au pire, gardez ça pour la prochaine réunion.
  • Si un programmeur vous demande de le « laisser tranquille », ne l’écoutez pas. Vous devez pouvoir suivre son travail, mais faites-le intelligemment (point suivant).
  • Prévoyez des réunions en premier le matin pour connaître l’avancement du projet et communiquer vos nouveaux besoins.
  • Si vous travaillez sur plusieurs projets à la fois, chaque changement de projet sera coûteux pour votre développeur. Groupez au maximum les tâches. Demandez-lui de traiter toutes les tâches du projet A avant de passer au projet B.
  • Si vous devez ajouter des nouvelles fonctionnalités au dernier moment, utilisez au moins des tests automatisés. Et prévoyez de revenir plus tard pour revoir le système complet autour de la nouvelle fonctionnalité (refactoring de code).
Si vous arrivez à faire tout ça, on sera très heureux de travailler avec vous, et tout se passera super bien.
À bientôt !
Julien.
ghghghgh

LEAVE A REPLY

Please enter your comment!
Please enter your name here