5 choses à faire pendant l'été pour devenir un·e meilleur·e développeur·se !

C’est le mois d’août ! Vos collègues sont toutes et tous partis en vacances et il ne reste que vous, qui êtes là au bureau…

Les journées sont calmes et le rythme est fluide, les tickets s’enchainent un peu plus vite que d’habitude (on va plus vite quand on n’est pas dérangé par les autres) et les pauses cafés sont légèrement aussi moins longues.

Et si c’était le moment de tenter 5 nouvelles choses pour devenir un ou une meilleure développeuse ? Lisez jusqu’à la fin pour découvrir toutes les astuces !

Mais avant tout, qu’est-ce qu’on attend d’abord par meilleur développeur ?

Un mot sur le mythe de la productivité

Un meilleur développeur, ce n’est pas juste une personne qui code 10 fois plus vite que les autres. Si la performance était simplement mesurée par les lignes de codes que l’on produisait, augmentez moi pour tous ces package-lock.json¹ modifiés dans ma vie !

Pour moi, un meilleur développeur est une personne qui a des actions qui ont un impact dans une de ces trois catégories :

• Moins de bugs
• Plus de features
• Meilleur ambiance dans l’équipe

(J’ai piqué ces métriques à HadrienMP)

Alors c’est parti pour être meilleur·e dans ces trois catégories !

Faire moins de bugs

Pour créer moins de bugs, la solution la plus radicale est de coder moins. Je ne plaisante même pas, je pars du principe que tout code est une dette, et tout ce qui permet de réduire la quantité de code produit est une bonne chose.

Mais parfois, nous sommes obligés de coder ! Alors je vous propose ces deux pratiques à explorer pendant l’été.

1 - Pratiquer le Test Driven Development en l’absence de ses collègues

Avec moins de pression, c’est le meilleur moment pour se mettre à écrire ses tests en premier ! C’est la pratique du TDD ! Grosso modo, un développement habituel se fait en trois étapes :

• Je comprends ce que je dois faire
• Je fais ce que je dois faire
• Je teste si ce que j’ai fait marche

Avec le TDD, on change légèrement la façon de travailler :

• Je teste un tout petit bout de ce que je comprends de ce que je dois faire
• Je fais ce que je peux
• Je fais du refactoring² et je recommence

Et c’est bien plus efficace pour faire moins de bugs et moins de régressions !

Comment s’y mettre ? Le plus simple vraiment est d’essayer sur des choses très simples (et même en frontend on peut), et abusez des versions gratuites de ChatGPT et autres IAs pour vous guider sur comment écrire un test en premier ! Faites au plus simple et vous verrez, c’est beaucoup plus accessible que vous ne l’imaginez.

2 - Apprendre la technique des 5 pourquois

Corriger un bug, c’est bien. Mais connaître sa cause principale c’est mieux. Et connaître la cause principale de la cause principale, c’est encore mieux. Et connaître la cause principale de la cause principale de la cause principale, c’est génial… Bref vous comprenez.

La technique des 5 pourquoi est une technique que j’ai redécouvert deux fois : d’abord par un article de Gitlab sur un postmortem de perte de données en production, et ensuite par mon ancien scrum-master dont j’ai remarqué qu’il me demandait systématiquement pourquoi, 5 fois, à toutes mes idées !!!

Comment s’y mettre ? Copiez collez ce texte dans n’importe quel outil d’écriture de texte et pensez au précédent bug que vous avez corrigé et forcez vous à répondre simplement :

Pourquoi <ce bug> a eu lieu ?

Réponse : A

Pourquoi A a eu lieu ?

Réponse : B

Pourquoi B a eu lieu ?

Réponse : C

Pourquoi C a eu lieu ?

Réponse : D

Pourquoi D a eu lieu

Réponse : E (c’est votre cause principale)

Une fois la cause principale établie, le top c’est de trouver un plan pour la traiter en amont.

Si vous suivez ce mode de fonctionnement, je vous garantis que vous aurez beaucoup moins de bugs, et vous ferez aussi des choses probablement bien plus passionnantes que passer votre journée à corriger, par exemple, des NullPointerException³

Faire plus de features

Mince, vous êtes devenu·e plus efficace pour corriger tous les bugs qu’on vous a refilé à corriger pendant l’été, et vous avez maintenant du temps pour coder de nouvelles fonctionnalités… Regardons comment on peut aussi optimiser cette catégorie !

3 - Commencer chaque journée par une liste de 3 objectifs

C’est un grand cliché mais ça marche tellement bien. Chaque matin, engagez vous à au maximum 3 micro objectifs, et si vous y arrivez : bonne nouvelle, pratiquez du TDD sur le temps restant, et sinon, découpez en un objectif plus petit.

Personnellement, je me limite à 1 objectif le matin, en sachant pertinemment que 2 autres objectifs vont apparaître en cours de journée.

Vous remarquerez que j’utilise le terme objectif et non tâche, et c’est normal : plusieurs tâches permettent d’atteindre un objectif, et en général les objectifs changent moins vite que les tâches à faire !

Je ne suis pas psychologue donc je ne saurais expliquer pourquoi ça marche si bien, mais je vous invite vraiment tous les matins à vous dire : “Aujourd’hui, je vais accomplir cet objectif.”

Bonus : communiquez votre objectif à votre équipe qui n’est pas en vacances. Cela vous permettra de développeur votre focus, qui est une des valeurs de la méthode SCRUM en agilité !

Comment vous y mettre ? Prenez un post-it ou moyen de prendre des notes, recopiez et complétez la phrase ci-dessous :

Aujourd’hui, mon objectif est de…

4 - Apprendre son IDE

Ok celui là a l’air moins fun, mais laissez moi vous expliquer pourquoi c’est très utile d’apprendre son IDE :

• Les raccourcis de l’IDE permettent de faire beaucoup d’actions sans souris, et c’est bien pour nos petits poignets sujets aux tendinites
• Certains raccourcis sont très puissants (surtout ceux de refactorisation)
• Saviez-vous que vous pouvez automatiquement formatter votre code à la sauvegarde ? Éviter d’écraser une branche lors d’un git push --force ?
• Faire des modifications multi lignes ? Sélectionner le contenu entre les deux parenthèses les plus proches ? Ajouter un argument à une fonction à la volée sans revenir à sa définition ? Transformer une liste d’arguments d’une fonction en un objet avec des propriétés ? Inline⁴ une méthode ?
• Etc, etc, etc.

Lisez le manuel des raccourcis de votre IDE, vous verrez qu’il y a des tonnes de choses qui vous sauveront la vie.

Améliorer l’ambiance dans l’équipe

Vous avez résolu tous les bugs et créé toutes les features qu’on vous a demandé pour l’été : félicitations, vous êtes le ou la meilleur·e. Et si vous aviez un impact si grand que vous rendez votre équipe plus heureuse, plus contente de venir au travail ? Cela est possible…

5 - Rendre son daily plus intéressant avec la technique de walk the board

Les daily à base de “hier j’ai fait ça et aujourd’hui je vais faire ça”, je n’en peux plus. Mon constat :

La majorité de l’équipe s’en fiche de ce que vous avez fait hier, ils sont déjà au courant.

Ce qui nous intéresse au daily le matin, c’est de trouver un moyen d’accomplir nos objectifs (voir le point précédent). Alors je vous propose d’inverser le board : Plutôt que chacun parle l’un après l’autre, faites parler plutôt les sujets en cours.

Je m’explique : si vous avez un board kanban, vous avez probablement 4 catégories : à faire, en cours, en test, fini. Votre objectif, c’est de finir un maximum de sujets. Alors, pourquoi ne pas avoir en visibilité tous les matins les sujets le plus proche d’être finis ? On appelle ça walk the board.

Je vous recommande cette lecture de chez OCTO qui vous donnera des idées de comment ça marche. Personnellement, je ne peux plus revenir en arrière et je ne viens plus à des daily qui ont un format différent.

6 - Bonus ! Conventional Comments ! La relecture de code aussi mérite des conventions

Ce n’est pas mon invention, tout vient de cette vidéo : Revue de code : on n’est pas venu pour souffrir ! - Anne-Laure DE BOISSIEU - Forum PHP 2022.

L’idée de base, c’est d’utiliser un système de conventions, comme dans nos commits pour celles et ceux qui pratique le conventional commit, mais pour les reviews. De vrais exemples de reviews que j’écris :

question: pourquoi as-tu laissé cette variable définie ici ?

suggestion: tu pourrais retourner un Optional plutôt que retourner potentiellement null

bravo: j’adore comment tu as géré cette méthode

Cette façon de faire des tours supprime l’ambiguité inhérente de l’écriture⁵, et permet de créer un cadre pour nous permettre de faire des compliments à nos collègues. Trop bien ! Regardez la vidéo que j’ai postée, et la speakeuse est une personne incroyable. 😻

Si vous arrivez à faire tout cela, félicitations : vous êtes probablement le ou la meilleur·e développeur·se de votre équipe et peut-être même de votre entreprise.

On dit souvent que si on est la personne la plus intelligente dans une pièce, il faut changer de pièce. Plutôt que de poser votre démission, je vous propose de rendre vos collègues plus intelligents en partageant cet article !

Et si des choses ne sont pas claires, envoyez moi un petit message 😇 hello@nirinarabeson.fr