Ce document explore quel développeur je suis, comment je collabore avec les équipes, en détaillant notamment mes préférences de travail.
J’ai pris soin à ce que chaque fait rédigé ici soit vrai et confirmé par mes pairs. Mon objectif n’est pas de plaire mais de faciliter ma rencontre avec des équipes qui cherchent quelqu’un avec ma personnalité et mes habitudes. ☝️
TLTR : J’organise mes journées avec rigueur, peu de réunions, un suivi précis du temps et des bilans quotidiens. J’adore le refactoring, le debug et soutenir les devs juniors. Je vise un code clair, sobre et durable. En revue, je cherche à partager la connaissance et à améliorer le projet sans égo ni fioritures.
Revues de code
- Je fais mes revues avec seulement deux objectifs : partager nos connaissances et garantir que chaque merge a un impact positif sur le projet.
- Dans mes revues, j’explicite les commentaires non-bloquants pour le merge. Ceux-ci invitent à la discussion, mais sont totalement facultatifs et peuvent être ignorés.
- Je marque une bienveillance forte et je ne m’attarde pas sur les fioritures.
- J’accompagne mes PR d’objectifs clairs, d’instructions pour faire la revue fonctionnelle, de captures d’écran, d’une liste exhaustive des modifications, et optionnellement de tests automatiques.
Conception logicielle
- Je préfère beaucoup de petits commits, avec des messages clairs et exhaustifs, plutôt que des gros commits en petit nombre.
- J’aime conserver les commits après les merge plutôt que les squash.
- Je suis vigilant à ce que mes branches ne subsistent pas à la fin de la journée, lorsque l'organisation de l'équipe le permet.
- Je sépare l’interface de la logique métier.
- J’aime TypeScript, les tests automatiques, et l'archi hexagonale (séparation IHM - logique métier - API).
- Je crois très important d’avoir une documentation régulièrement mise à jour, accessible aux collègues non-tech, rédigée dans la langue des utilisateurs finaux, disposée à un seul endroit.
- Depuis peu j’ai changé d’avis sur les tests end-to-end, j’aime utiliser Playwright maintenant, cependant je pense que tester le back-end via ces tests est une erreur.
Communication au sein de l’équipe
- Je suis vigilant à éviter tout éclat de fierté ou d’égo personnel : mon objectif est la réussite de l’équipe. Ainsi, je communique rapidement si je suis bloqué, et je signale les anomalies sans considérer l’impact sur la continuité de notre collaboration.
- Je suis vigilant à répondre très rapidement.
- Je ne sais pas tout, je me complais totalement dans cette citation de Kent Beck : « I’m not a great programmer; I'm just a good programmer with great habits ».
- Je privilégie une communication directe et factuelle.
Planification
- J'aime travailler entre 9h30 et 17h30.
- J’utilise un outil pour suivre mon temps de travail et noter mes avancées.
- Je protège ma concentration en limitant les notifications.
- J’ai l’habitude de travailler les jours fériés.
- Si une tâche dure moins de 10 minutes je peux m’y atteler immédiatement. Sinon, j’en fais une note.
- À chaque fin de journée je me rédige un résumé de ce qui s’est passé avec quelques propositions pour le prochain jour de travail. À chaque début de journée, je lis le résumé le plus récent.
Ce que j’adore !
- Le refactoring.
- Le debug.
- Rédiger des revues de code pour des devs juniors.