Un mindset pour aller plus vite [YouTube]

Aujourd’hui, on va parler mindset. Comment aller plus vite en tant que développeur, comment accélérer dans tout ce que tu fais ! De la moindre fonction au projet entier !

Et de façon exceptionnelle, on change un peu ! On change de format puisque le contenu que je te propose est sous la forme de vidéo YouTube. J’y ait passé beaucoup de temps et je lui ai donnée beaucoup d’amour, j’espère que ça va te plaire.

Attends, c’est quoi ce bordel ?

Alors, le blog ne switch pas sur YouTube. En tous cas, pas pour le moment. C’est juste pour changer un peu de temps en temps et en ajout des articles. Je comprends que beaucoup aiment le format texte.

Moi aussi j’aime le format texte, il ne va pas disparaître du tout. D’ailleurs, retour au format texte des lundi prochain.

En attendant, voici le transcript entier de la vidéo si vraiment t’es allergique au vidéo. Je tiens à dire quand même que ce texte n’est pas censé être lu, mais écouté via la vidéo ! C’est toi qui vois 😉

Transcript

Introduction

Salut à tous, je suis un dev, et cette vidéo n’était pas censée exister !

Aujourd’hui, on va parler de comment aller plus vite en tant que développeur. Comment accélérer dans tout ce que tu fais, que ça soit un petit projet comme la moindre petite fonction. L’astuce d’aujourd’hui c’est plus qu’une simple astuce en fait on est carrément sur du mindset !

Ça va te servir en permanence et ça va te servir pour tout, absolument tout, de maintenant à tout jamais. C’est vraiment vraiment pas mal ! Mais avant ça, il faut que je raconte une histoire.

Hackaton en enfer

C’est une histoire qui s’est passée il y a quelques années, c’était pendant un hackaton de développeurs. Je sais pas si tu vois ce que c’est un hackaton ?

Un hackaton c’est quand il y a des équipes de développeurs qui se réunissent à un endroit et qui travaillent toutes sur des projets différents. À la fin du hackaton, tout le monde présente ces projets et tout le monde vote pour toutes les autres équipes. L’équipe avec le plus de votes gagne des prix.

Et le truc « drôle » là-dedans c’est que t’es en équipe avec d’autres développeurs et tu as très peu de temps pour faire une idée, ça va vite et c’est super impressionnant. Le but d’un hackaton c’est d’aller vite, retiens ça parce que ça va être important.

Et donc je me retrouve à être assigné dans une équipe avec deux devs, un chef de projet et un tech lead. Un teach lead qui avait un boulard tellement gros, il passait plus les portes . Un ego surdimensionné mais de l’espace ! Et très vite et nous a dit, de façon claire et précise, qui allait décider de tout. On a choisi ni le sujet, ni la techno, ni l’architecture … On savait même pas si on allait pouvoir coder sur nos machines ou pas !

Il nous présente son projet et le truc c’est star wars. Un truc infaisable dans le contexte et le temps imparti d’un hackaton. Sans rentrer dans les détails, c’est quelque chose qui allait écouter tous les logs et les métriques de l’entreprise, qui a laissé les compilés pour trouver des patterns pour faire des projections dans le futur pour essayer de prédire des pannes dans le futur. Le bordel on a deux doigts de l’intelligence artificielle.

Déjà un, ça existe déjà, et deux on ne fait pas ça pendant un hackaton. Faut savoir qu’on a 24 heures devant nous. Il voulait tout refaire ! Du coup je suis allé le voir à la fin de la première réunion.

– « On est d’accord que l’on va faire entre 5 et 10% de tout ça ? »
– « Non, on va tout faire! Et avec la meilleure qualité possible! »

Évidemment, ce qui devait arriver arriva on n’a pas eu le temps de finir parce que c’était humainement impossible. Le problème c’est que comme on s’est dit tiens on va faire tout de suite le truc parfait avec la meilleure architecture possible et la meilleure qualité possible, parce que c’est ce qu’il voulait, on n’a pas pu aller assez vite finir.

On s’est retrouvé à présenter des schémas pendant la présentation des projets à la fin du hackaton. Tu ne sais pas à quel point c’est ridicule de faire ça. Quand tout le monde présente des démos fonctionnels et que toi tu arrives avec des schémas.

Mais comme on aurait pu faire pour aller plus vite ? Comment on aurait pu faire pour accélérer ce hackaton ? Est-ce que c’est possible ?

Make it beautiful

La technique dont je le parle aujourd’hui va en contradiction avec beaucoup de choses que tu as déjà entendue. En tant que développeur on te répète toujours la même chose : on ne transige pas avec la qualité.

La qualité c’est ce qu’il ya de plus important. Si tu fais pas de qualité, tu es un mauvais développeur et c’est tout ! Et quand on te dit ça en permanence, ça rentre tellement fort que tu ne peux plus rien faire si c’est pas une qualité parfaite tout de suite. Et ça, ça pose beaucoup de problèmes.

Évidemment que la qualité c’est important, évidemment que tu dois t’en préoccupé et évidemment tu dois déployer des applications de production qui sont de qualité. Évidemment ! Mais le problème de la qualité c’est que ça prend du temps.

Voilà la phrase clé de la vidéo que tu peux encadrer : la qualité c’est ton objectif, pas ton point de départ.

C’est le problème que je vois partout, encore et encore, peu importe les entreprises où je suis passé, peu importe les niveaux de séniorité des développeurs que j’ai vus. Tous les
développeurs commencent par la fin. On leur a tellement fait rentrer dans la tête que la qualité c’est ce qui était le plus important au monde, qu’ils ne peuvent plus rien faire si c’est pas une qualité parfaite tout de suite.

Tu commences par la fin, tu commences par la qualité, comment tu veux aller vite si tu commences par la fin ? Comment tu veux aller vite si tu veux faire tout parfait tout de suite. C’est impossible, tu peux pas faire tout parfait tout de suite.

D’ailleurs ça porte un nom ! Ça s’appelle la paralysie d’analyse ! Tu veux tellement bien faire, tellement tout de suite que tu fais plus rien. Et parfois c’est même pervers en fait. Tu as des développeurs qui vont complètement procrastiner sous prétexte de la qualité. En gros ils vont utiliser la qualité pour repousser encore et encore le début du développement.

Tout ça compiler, c’est une perte de temps incommensurable que tu t’infliges en permanence parce que tu as décidé de commencer par la fin ! Et attention, je suis pas en train de te dire qu’il faut coder avec le cul et nager dans ton caca. Non, c’est plus subtil que ça.

Make it work

En fait, cet état d’esprit il est très simple et il est très facilement applicable absolument partout. Personnellement ça me fait gagner un temps fou depuis des années et il est hors de question que je fasse autrement.

À chaque fois qu’on me demande quelque chose que ce soit un projet entier ou juste une petite tache isolée ce que je fais c’est que je me concentre sur le problème principal. Quel est le problème principal ? Comment je peux réduire le problème pour avoir juste le coeur du problème, le coeur de ce que je dois résoudre en fait.

Je me concentre dessus et je le fais fonctionner le plus rapidement possible, sans me préoccuper de la qualité, pas tout de suite ! Je ne pense pas à ou est-ce que ça va être, je pense pas comment ça va être, je pense pas à comment je vais l’intégrer avec tout un système, je pense à d’abord régler le plus petit problème.

J’ai un seul objectif à ce moment-là, c’est de prouver que mon idée fonctionne. En fait, je fais des prototypes. Je fais des prototypes en permanence. Ce qui est cool avec cette technique c’est que parfois je me rends compte que mon idée marche pas en fait. Mon idée ne marche pas et je suis obligé de changer ce que je pensais faire. Ça arrive en permanence en fait !

Tu as une idée, tu te dis que ça va fonctionné comme ça, tu l’as fait rapidement, et puis tu te te rends compte que pas du tout en fait. Pas du tout, c’est même complètement stupide cette idée. Et le truc c’est que : ajuster des choix techniques quand tu fais un prototype : c’est rapide et facile. Ajuster des choix techniques quand tu as commencé par la qualité : c’est l’enfer.

Également, ce qui est important de comprendre c’est que, à ce moment-là, quand je suis à l’étape du prototypage, le code ya personne qui le voit. Il y a personne qui le voit à part moi. L’important c’est que ça fonctionne, je veux prouver que mon idée fonctionne !

Au bout d’un moment, et assez vite justement parce que j’ai pas à me préoccuper de beaucoup de chose : ça marche! Mon prototype fonctionne, mon idée est validée, la feature est faite ! Le problème c’est que le code il est dégueulasse. Donc je passe à l’étape 2.

Je commence par écrire un test ou des tests pour figer le fonctionnement de la feature que j’ai fait salement. Le test m’assure le comportement du code, peu importe ce qui va changer dans le code dans le futur.

Ensuite, je refactor ma feature. Je refactor jusqu’a que ça soit beau, jusqu’à que ça qualité jusqu’à que ça soit tellement propre qu’on puisse manger par terre !

Et là tu vas me dire : oui, mais je comprends pas, donc ça veut dire que tu recommences plusieurs fois la même chose en fait ? Oui oui oui ! Et c’est plus rapide !

Évidemment que tout n’est pas blanc ou noir, évidemment que parfois tu peux commencer par du bon code et aller vite. Mais la plupart du temps, surtout quand tu sais pas comment faire quelque chose, c’est beaucoup mieux et beaucoup plus rapide de commencer par du code salle, rapide, prouver une idée, prouvé un prototype.

C’est quelque chose qui va vraiment t’aider pour ta productivité, je rigole pas, franchement, c’est quelque chose, qui est super super utile pour plein de cas et pour plein de situations. Et si tu là en tête tu peux facilement l’utiliser et ça va vraiment de booster au niveau du temps de production!

Attend, y’a pas un mot buzz pour ça ? Ha oui, c’est un hack ! C’est un dev hack. Hack ton code, hack ta vie, hack ton code !

Bref, en tout cas, j’utilise cet état d’esprit et en effet, ça m’a fait gagner un temps fou. Et à la fin de l’histoire, tu as le même code que celui qui a commencé par la qualité, c’est juste que tu es plus rapide !

Épilogue

Cet état d’esprit est vraiment applicable partout ! Par exemple cette vidéo, moi je suis un blogueur à la base. Je fais du texte et puis je le ship et puis on verra bien. Les vidéos je sais pas faire! Je savais pas par où commencer et j’ai arrêté de faire une obsession sur comment faire. Je me suis dit OK réglons juste le plus petit problème.

Je veux juste faire passer un message à travers une vidéo. Est-ce que c’est possible ? Est-ce que je vais arriver à régler ce petit problème-là ? Je verrai le reste après, on verra, je verrai pour la partie refactor. Je vais éviter cette vidéo un max pour que ça se voie pas que je fais de la merde et ça va bien aller !

En tous cas merci d’avoir regardé la vidéo. On vient de taper les 600 000 visiteurs uniques depuis le début d’année 2020 : merci ! Ça fait plaisir !

Si tu connais pas le blog il est extraordinaire, ça s’appelle Je suis un dev et c’est toujours ouvert. Tu peux t’abonner ¸à mon twitter et à cette chaîne YouTube pour toujours plus de contenu, et on se dit à lundi prochain ?