Comment être un développeur plus efficace

Bonjour surfeur des Internets et bienvenue dans un nouvel article pas piqué des hannetons. C’est bien un titre putaclic ce que je propose aujourd’hui! Je suis assez fier de moi. Ceci dit dans cet article on va vraiment parler d’efficacité oui oui. Mais pas n’importe laquelle, on va parler de la tienne. On va parler des petits trucs qui font toute la différence à la fin de la journée et surtout à moyen terme. Certains évidents, mais qu’il faut sans cesse répéter sans quoi on les oublie comme la plus sombre des règles REGEX (que ça sert a rien de l’apprendre). Et d’autres qui sont complètement des secrets de hackermen aguerris aux performances numériques hors du commun. Oui j’en fais des tonnes mais je propose des résultats spectaculaires.

Résoudre un bug de l’enfer

Avant même de commencer je pars du principe que vous travaillez avec les meilleures pratiques possibles, on parle de test, de code review etc etc je vais pas reparler de la base.
Maintenant qu’on est d’accord, on va voir comment résoudre un bug impossible et pour se faire on va commencer par décrire comment j’ai fait pendant très longtemps avant de me rendre compte que j’étais une personne complètement débile. En voyant une erreur mon premier réflexe de dev du dimanche était de googler l’horreur, cliquer sur le premier lien, scroller jusqu’à voir un bout de code qui ressemble à une solution et copier/coller le tout ca comme un gros sale. Ça marche pas ? Pas de problème, lien suivant et on recommence. Et pourquoi on fait ca ?  -Si si c’est sûr tu l’as déjà fait- On fait ça parce que ça marche en fait.

Enfin, ça marchait. Car oui à force d’évoluer vous êtes passé de problème de bisounours en sucre à des problèmes envoyés par Satan en personne. Satan il est vicieux, sans pitié, il vous connait et il va pas vous lâcher. Il aime ça vous voir craquer tout seul et foutre un coup de poing à votre bureau innocent pendant que les collègues vous regardent avec un gros smile. Bon par contre la partie moins drôle c’est que Satan il vous a vraiment pas lâché de la journée et vous avez rien avancé en fait.

Compréhension

Il faut tout comprendre, vraiment tout. T’arrêtes tout. Tu lis tout ce qui a à lire sur ton problème. Tant que t’as pas TOUT compris tu continues à la lire la doc. Si ya une couche, une techno, un terme, une commande ou autre pas super clair pour vous c’est pas bon du tout. Je sais ! Je sais ! Ça fait déjà 6h que tu es sur le même problème, tu commences à être stressé comme un condamné à mort et ton boss te regarde de travers. Mais dans la situation où tu te trouves c’est la méthode la plus rapide. C’est tellement rapide en fait que vous allez gagner du temps et de l’exp pour le prochain test de Satan. Non mais sérieux RTFD ca devient pénible de répéter ça mais ça sauve des vies. C’est fou le nombre de dev qui lisent pas la doc!

Attention je suis le premier abruti à rien lire, à me prendre pour Mr. Robot, monsieur je sais tout qui code en tâtonnant. Mais très vite ça me rattrape. Car tout simplement coder sans comprendre toutes les parties de son appli c’est compter un peu sur la chance. Et compter sur la chance pour faire votre métier c’est bien tout moisi on est d’accord ?

J’aime bien ce GIF. Tu vois le machin jaune ? Le machin jaune c’est toi. Le type qui te tabasse avec la doc? C’est la vie.

Isolation

Alors je te vois hein, tu vas me dire « oui écoute t’es bien gentil mais la doc je l’ai lu, merci, oui j’ai bien compris mon problème gros malin ». Alors OK, du calme, dans ce cas-là on va passer à l’étape 2. Comme tout bon dev qui se respecte j’ai déjà passé une journée entière sur un bug. Vous allez me dire « rien de fou » on a tous fait ça mais ce qui m’a énervé c’est que j’ai résolu le bug de l’espace en 5 secondes et un changement une ligne en fin de journée. Il était 9h17 ce jour-là et je commençais à tester mon application que je venais de déployer sur un env dev. Je travaillais sur une application NodeJS, dans un container Docker, déployée via une CI GitLab, via un chart HELM, hostée dans un pod à l’intérieur d’un cluster Kubernetes dont le traffic est géré par un serveur NGINX managé par le service mesh Istio le tout monitoré via une stack EFK… Je crois que vous voyez où je veux en venir. Confiant comme jamais d’un travail de qualité je me rends sur la page d’accueil. Et là, grosse page blanche des familles qui donne du plaisir. Aucune idée de ce qui se passe, ça a pas commencé c’est déjà en train de m’énerver.

Évidemment quand je regarde ma super stack de logs, silence radio, les 3 milliards d’espions que j’ai mis sur mon appli sont tous sourds et muets tout d’un coup. Et je me retrouve à fixer l’écran blanc pendant 30 secondes en me disant que c’est un truc évidant c’est sûr et que je suis con. Et quand vous êtes dans une situation similaire où il ya autant de couches d’abstraction que de code, vous ne pouvez plus appliquer les techniques de debug ghetto du passé où on teste au pif de façon globale en faisant une prière a chaque fois. Non il faut isoler les parties de votre application jusqu’à trouver le vrai coupable, et ça se passe en deux étapes.

Validation via isolation: la première partie de la méthode et d’isoler couche par couche votre appli pour tester chaque couche seule et valider son fonctionnement. Quitte à mettre des stubs, il faut que le behavior de chaque couche soit totalement testable sans rien d’autres. La règle : vous avez un input et vous voulez un output précis. Si le résultat est exactement celui que vous voulez, très bien, couche suivante. Sinon vous avez sûrement trouvé votre coupable! Réglez le problème et réessayez de faire tourner votre appli. Ceci dit il arrive souvent qu’il y ait plusieurs coupables (sinon c’est trop facile) donc si ça ne marche toujours pas, reprenez où vous en étiez et passez à la couche suivante. Testez chaque couche vraiment, même si vous êtes sûr que ca marche. Je sais, « c’est sûr que c’est pas ça », mais vous le savez notre métier est super vicieux des fois, ça nous a tous surpris. Et on veut éviter de jeter son écran au milieu de l’open space et faire un foot avec à cause de ça.  Le but de cette étape est de valider unitairement chaque couche pour être sûr qu’il n’y a pas un maillon faible. Si chaque couche est validée seule et que votre appli marche toujours pas, étape 2.

Validation via accumulation: la seconde partie est simple, vous prenez la couche la plus basse et vous la « mergez » avec la couche d’au-dessus et vous validez avec le même principe d’input et d’output. Si ça fonctionne vous prenez la troisième couche au-dessus, vous l’accumulez comme fait juste avant et rebelote. Le but de cette partie est de valider la communication entre les couches et surtout de repérer là où la communication fait défaut pour trouver le coupable. Car si vous avez bien fait l’étape d’avant ce n’est pas un problème de maillon faible mais de communication qui foire à un moment donné entre les maillons de votre app.

Acceptation

Ça marche toujours pas ? Je te vois taper sur ton clavier et insulter ton écran ça sert à rien mais ça fait du bien je te comprends. Arrivés à ce point on a tous l’air d’un fou qui se bat contre une conspiration faite par les Illuminati en personne. On commence à essayer des choses de plus en plus improbables parce que « au point où j’en suis autant tenter ça, plus rien à foutre ». Et c’est là qu’on perd un max de temps. La première chose à faire est de step back et de se calmer. D’accepter que ce problème soit sérieux mais que finalement c’est pas très grave. C’est dur, c’est justement le moment où le stress est au maximum mais c’est justement pour ça qu’il faut se calmer et respirer un coup. Travailler dans cet état là pour la plupart des gens ne sert à rien, c’est contre-productif. Tu es plus efficace en plein chaos? Bienvenu au paradis alors 🙂 mais pour la plupart des gens c’est que de la perte de temps pur.
Donc l’étape suivante est d’appeler un collègue à la rescousse et de lui expliquer votre problème de façon très globale.

C’est fou le nombre de fois où votre collègue va juste pointer du doigt un trou évident dans votre raisonnement mais que vous pouvez plus voir tellement vous êtes loin, absorber dans votre situation. Vous n’avez plus le recul sur ce qui vous arrive et dans cette situation impossible d’identifier le souci, aussi gros qu’il soit. En général tout ceci finit par achever un bug et si c’est pas le cas : Etes-vous sûr que ce vous voulez faire est la meilleure façon de le faire ? Car le meilleur moyen de faire marcher une mauvaise solution et d’en trouver une meilleure.

Chacun sa religion

Oulala mais qu’est ce que tout ça a à voir avec les religions ? Bah en fait rien mais on va parler d’IDE/éditeur de texte et c’est quasiment la même chose pour beaucoup de dev. On va parler d’IDE/éditeur de texte mais je vous le dis tout de suite on va pas parler du mien. Je trouve ça ridicule quand je vois quelqu’un essayer de prêcher son IDE comme si c’est lui qui l’avait fait. Je ne vous dirai pas de prendre tel ou tel éditeur car d’abord, vous n’allez pas le faire et surtout c’est stupide de forcer quelqu’un à utiliser tel ou tel outil. Les excuses de type on veut le même lint pour notre projet sont ignorantes du fait que presque tous les éditeurs ont des plugins similaires qui font exactement le même boulot. Non, mon conseil est justement le contraire : utiliser l’outil qui vous met le moins de bâtons dans les roues. N’utiliser pas Web Storm avec ces 300 plugins de la NASA juste parce que c’est fancy d’avoir 10k features dans son éditeur alors que vous ne les utilisez pas. N’utilisez pas VIM car le hackerman du coin qui connaît tous les shortcuts vous dit que c’est la seule voix de l’excellence. C’est des conneries, tout hackerman de l’espace qu’il est il va pas vous aider, ça va être complètement le contraire en fait. Pour de vrai, chacun sa religion, chacun son IDE, chacun sa vie, utilisez ce que vous aimez et arrêtez de faire chier les autres autour de vous avec votre religion.

Procrastiner de façon régulière

Ha! Alors là, tu t’attendais pas à celle-là! Je suis censé vous dire que faut être focus non-stop sur son travail, pas le droit de cligner les yeux ou d’aller poser une pêche sinon c’est le mal. Non ça c’est penser comme un pion sévère du siècle dernier. La vérité c’est que procrastiner vous allez le faire. Peu importe votre motivation et le boulot que vous avez à faire, peu importe le patron qui vous flique et même pendant du pair-programming:  ça va lancer une petite tab Facebook twitter et autres et ça va checker ce qui se passe sur les Internets. Alors au lieu que je fasse le gros hypocrite on va plutôt discuter de comment on peut controller le temps qu’on passe a procrastiné. J’en avais déjà parlé dans un autre article dont je vous conseille fortement la lecture, mais j’avais pas insisté sur ses bénéfices.

On va parler d’une technique connue : Pomodoro. Le principe est simple vous lancez un compte à rebours de 25 minutes, utiliser un site en ligne genre lui c’est pratique, et pendant ces 25 minutes vous devez travailler seulement sur une tâche. Pas plusieurs tâches, une seule, full focus et sans aucune interruption. À la fin de ces 25 minutes vous devez vous arrêter, même si vous êtes au milieu de votre code, et faire tout ce que vous voulez qui n’est pas lié au travail pendant au moins 5 minutes. Se faire le café numéro 17, lancer un nerf dans la tête d’un collègue, envoyer des GIFS sur slack, ce que vous voulez mais votre cerveau doit pas faire d’effort lié au travail. Ensuite rebelote, jusqu’à que vous finissiez votre objectif de la journée. Franchement au début c’est pas évident à suivre. Les premières runs de pomodoro sont pas très efficaces car c’est dur de se focus. 25 minutes c’est énorme. Mais avec un peu de pratique c’est impressionnant les résultats et surtout ça vous permettre de rien foutre en sachant très bien que le job est fait et ça c’est la vie.

Épilogue

Il y a quelque chose d’important que j’ai pas dit. Peu importe l’utilisation de techniques utiles et autres méthodes de travail. L’ingrédient principal pour créer de la productivité c’est la motivation. Tu vas peut-être utiliser un peu des techniques plus haut et trouver ça super utile. Mais dans tous les cas sans motivation c’est compliqué de travailler sur autre chose que son feed Facebook. Exigé à tout prix et par tous les moyens de travailler sur quelque chose que vous aimez et que vous voulez voir grandir. On cajole et on donne toute notre attention seulement aux choses qu’on aime, et en dev c’est la même histoire.