Eugene Yan partage ses conseils pour les nouveaux Principal Engineers (ou ICs - contributeurs individuels - techniques principaux), inspirés de ses observations et de mentors, notamment dans un contexte Amazon. Il souligne que le rôle varie selon les profils : certains excellent dans la technique pure, d’autres dans l’influence transversale ou l’alignement d’équipes. À ce niveau, le codage devient secondaire ; l’impact passe par la vision technique, le mentorat, la connexion des équipes et la résolution de problèmes ambigus que personne d’autre ne traite. Le Principal Engineer doit aussi savoir convaincre, déléguer, et créer de l’espace pour les autres, tout en évitant de devenir un goulot d’étranglement. L’article insiste sur l’importance de rester "hands-on" ponctuellement, de clarifier le "pourquoi" derrière les décisions, et de se préserver des réunions inutiles pour garder du temps de réflexion stratégique. Enfin, il rappelle que ce poste exige une autonomie totale dans le choix des problèmes à résoudre, avec une responsabilité accrue envers l’organisation et soi-même. Une lecture utile pour comprendre les attentes et défis de ce rôle clé en ingénierie.
L’article partage l’expérience d’un lead développeur qui, submergé par la multiplication des responsabilités, a réalisé que son emploi du temps était aussi mal optimisé qu’un code truffé de bugs. Il propose une méthode inspirée du développement logiciel pour "refactorer" son agenda : diagnostiquer ses tâches (en les listant, évaluant leur importance et leur urgence via une matrice d’Eisenhower adaptée), prioriser en distinguant l’urgent de l’important, et planifier avec le time-blocking (réserver des plages fixes pour les tâches récurrentes et laisser 30% de temps libre pour les imprévus). L’auteur insiste sur l’importance de la weekly review pour ajuster son planning, déléguer davantage (comme en pair programming), et ainsi retrouver du temps pour l’essentiel : développer, faire de la veille, ou animer des ateliers. Une approche pragmatique pour éviter le syndrome de la "fonction qui fait tout" et réduire le stress, avec des outils concrets comme la matrice de priorisation et des créneaux sanctuarisés. À tester surtout quand on passe de dev à lead ou manager !
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre (via https://damien.pobel.fr/post/veille-semaine-19-2018/ )
Tout est dans le titre
Je cite l'auteur : "napa vous aide à travers npm à installer des modules qui n’ont pas de package.json" Apparemment par contre, napa est à installer après npm-shrinkwrap
Un gestionnaire de paquets pour les développeurs web