Ce billet de Pascal Martin aborde la réalité du développement logiciel, où les développeurs passent souvent plus de temps à maintenir ou modifier du code existant qu’à en écrire de nouveau. L’auteur souligne que, même au sein d’une équipe, la connaissance approfondie d’un projet est rarement partagée par tous ses membres, chacun intervenant principalement sur des parties spécifiques. Il évoque aussi l’absence historique de pratiques comme les revues de code ou les tests automatisés, qui auraient pu faciliter cette maîtrise collective.
Martin illustre son propos par son expérience personnelle, où il a souvent dû intervenir sur des bases de code inconnues, que ce soit en SSII ou en tant qu’éditeur de logiciels. Il note que même les projets développés from scratch reposent souvent sur des composants partagés, et que l’ajout de nouveaux développeurs ne garantit pas une connaissance exhaustive du code.
Enfin, il remet en question l’idée reçue selon laquelle une équipe connaît parfaitement son propre projet, rappelant que les absences, les départs ou le simple passage du temps rendent cette maîtrise illusoire. Il interroge ainsi les pratiques de passation de connaissances et de documentation au sein des équipes.
L’article de Rahul Garg, ingénieur principal chez Thoughtworks, propose d’encapsuler les standards d’une équipe sous forme d’instructions versionnées et partagées, afin d’améliorer la cohérence des résultats générés par les assistants IA. L’idée centrale est de transformer les connaissances tacites des équipes (conventions de code, bonnes pratiques de sécurité, etc.) en artefacts exécutables, réduisant ainsi la dépendance aux experts et les variations de qualité selon les utilisateurs.
L’auteur souligne que les pratiques informelles, acquises par l’expérience, créent des disparités dans l’utilisation de l’IA, même au sein d’une même équipe. Sans cadre formalisé, les prompts varient selon les individus, ce qui nuit à la standardisation des livrables. La solution envisagée consiste à externaliser ces règles dans des documents versionnés, accessibles à tous, pour garantir une application uniforme des standards.
Enfin, Garg illustre ce problème avec des exemples concrets : un développeur senior inclut des détails précis dans ses requêtes (style fonctionnel, gestion des erreurs, conventions de nommage), tandis qu’un junior se contente de demandes vagues, produisant des résultats moins alignés avec les attentes de l’équipe. L’objectif est donc de systématiser ces instructions pour fluidifier le travail collaboratif avec l’IA.
L’article explique que la lenteur des équipes techniques est souvent attribuée à tort aux compétences des développeurs, alors qu’elle provient principalement de la complexité du codebase. L’auteur, Ally Piechowski, introduit le concept de codebase drag (frottement du codebase), où la dette technique et les choix d’architecture alourdissent les tâches quotidiennes, comme illustré par l’exemple d’une équipe ayant passé une semaine sur une fonctionnalité simple à cause d’un code mal structuré.
L’auteur identifie cinq signaux révélateurs d’un codebase problématique, dont les estimations gonflées et la peur des déploiements. Par exemple, des équipes reportent systématiquement les déploiements par crainte de générer des incidents, ce qui reflète un manque de fiabilité du code et des processus. Ces problèmes ne sont pas résolus par des réorganisations ou des embauches, mais nécessitent un investissement direct dans la refonte du code.
L’article propose un audit interactif pour évaluer l’impact du codebase sur la productivité, soulignant que les équipes sous-estiment souvent l’ampleur des coûts cachés liés à un code mal conçu. La solution passe par une prise de conscience de ces dysfonctionnements et une priorisation de la maintenance technique pour réduire le codebase drag.
Cette page explore les différents archétypes d'ingénieurs Staff-plus, des rôles techniques de leadership au-delà de la voie managériale. Elle identifie quatre profils récurrents : le Tech Lead, qui guide une équipe ou un groupe d'équipes ; l'Architecte, responsable de la direction technique dans un domaine critique ; le Solver, qui résout des problèmes complexes ; et le Right Hand, qui assiste un exécutif dans la gestion d'organisations complexes. Ces archétypes aident à clarifier les attentes et les responsabilités des ingénieurs Staff-plus, souvent masquées par des grilles de carrière uniformes.
L'auteur explique la marche à suivre pour partager une liste d'extensions VS Code recommandées. Il précise aussi comment éviter certaines extensions et la création d'un pack
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Un article de fond sur le fonctionnement des équipes de développement et les pièges à éviter
Tout est dans le titre
Tout est dans le titre
Comment bien accueillir un nouveau développeur...