Retour à l'accueil du SAV de la Tech
21. Mon dev livre des usines à gaz 🏭💨
Cette semaine, dans le SAV de la Tech, on répond à la question de Robert:
"Je suis manager d'une équipe où je manage plusieurs devs. L'un d'entre eux me pose des problèmes de productivité. Il fait du code très propre, mais il est trop perfectionniste et à beaucoup de mal à délivrer. Il s’intéresse énormément aux problématiques d'architectures logiciels, au clean code et à toutes les bonnes pratiques, ce qui en soit est très bien. Mais j'ai l'impression qu'allier ceci à son perfectionnisme l'empêche de mener à bien les tâches qui lui sont attribuées. Il passe énormément de temps à préparer ses développements avant de les débuter, à chercher la meilleure façon de le faire, et durant le dev il revient régulièrement sur ce qui a été fait pour tenter de l'améliorer. Régulièrement il fini par produire des mini usines à gaz pour des choses très simples après un temps de dev qui dépasse très largement les estimations les plus pessimistes. Cela pose également des problèmes quand d'autres membres de l'équipe collaborent avec lui sur un projet. Il m'est même arrivé de faire une choses que je déteste: reprendre from scratch certaines tâches pour sauver les meubles et qu'elles soient terminées pas trop hors délais. Ce qui fait que je sais que les délais en question étaient largement tenables ^^
Ma question est donc: comment réussir à transformer un développeur trop académique en développeur plus orienté vers les besoins d'une entreprise ? Pour l'instant mes tentatives y ont échoué."
Épisode enregistré en Mai 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
Proposer une question, un sujet
Ressources mentionnées dans l'épisode
(🫣 À lire après écoute de l'épisode !)
- Request For Comments (RFC): L'écriture de RFC permet de proposer des changements à l'équipe et recueillir leurs suggestions avant d'effectuer ces changements dans le code.
- Test-driven Development (TDD): Technique de développement consistant à commencer par définir un micro-objectif fonctionnel à atteindre, sous forme d'un test automatisé, suivi d'une phase d'implémentation puis de raffinage. Avantage: aide à faire émerger une architecture progressivement, en réponse aux besoins fonctionnels.
- You aren't gonna need it (YAGNI): Règle consistant à se rappeler de ne pas écrire du code tant qu'on est pas sûr qu'il est nécessaire. Permet d'éviter l'over-engineering.