Ce grand article de John Olspau s'intitule «Être ingénieur en chef» . La première fois que je l'ai lu il y a environ quatre ans, alors que je venais de changer d'emploi, cela a vraiment influencé les idées sur ce domaine de ma carrière.

Après l'avoir relu maintenant, une chose semble vraiment intéressante là-bas, que l'empathie et l'aide à l'équipe sont une partie importante du travail des seniors. Ce qui est bien sûr vrai!

Mais maintenant, je vois que la plupart ou la totalité des principaux ingénieurs que je connais apportent une aide importante à d'autres employés en plus de leur travail de programmation personnelle. Maintenant, il me semble que mes collègues et moi sommes moins confrontés au problème «Quoi ?? Besoin de parler avec des gens ?? INCROYABLE », combien avec un autre problème:« Comment équilibrer tout ce travail de leadership avec votre entrée / programmation individuelle? Combien et quel genre de travail dois-je faire? » Par conséquent, au lieu de parler des signes du seigneur de l'article d'Olspau (avec lesquels je suis tout à fait d'accord), je veux parler du travail que nous faisons.

De quoi parle cet article

«Ce que fait un ingénieur en chef» est un sujet énorme, mais voici juste un petit article, vous devez donc garder à l'esprit:

• Il n'y a qu'une seule description possible de ce qu'un ingénieur de premier plan peut faire. Il existe de nombreuses approches du travail, et cela ne devrait pas être un dogme.
• J'ai principalement travaillé dans une seule entreprise, donc mon expérience et mes opinions sont évidemment assez limitées.
• De toute évidence, il existe de nombreux niveaux de «senior». Il s'agit du niveau P3 / P4 dans la hiérarchie Mozilla (ingénieur senior / ingénieur personnel), peut-être un peu plus proche du niveau "staff".

Quelles sont les responsabilités

Ce sont des choses que je considère plus comme le travail d'un ingénieur principal et moins comme le travail d'un gestionnaire (bien que les gestionnaires fassent certainement certaines des choses ci-dessus, en particulier en créant de nouveaux projets et en reliant les projets aux priorités de l'entreprise).

Presque tout ce travail est essentiellement technique : aider quelqu'un à faire face à un projet complexe est clairement une interaction humaine, mais les problèmes que nous allons travailler ensemble seront généralement techniques! ("Peut-être, si nous simplifions la conception, nous pouvons faire face plus vite!").

• Écrivez du code (évidemment).
• Faites un examen du code (évidemment).
• Rédiger et réviser la documentation de conception . Comme pour les autres avis, un look tiers est susceptible d'améliorer la conception.
• Aidez vos collègues s'ils sont coincés . Parfois, les gens sont bloqués sur un projet, et il est important de les aider! Je ne pense pas tellement à «parachuter du ciel et à transmettre vos connaissances magiques aux gens», mais à «travailler ensemble pour comprendre le problème et voir si deux cerveaux peuvent faire face plus rapidement qu'un seul» :). Cela signifie également travailler ensemble, ne pas résoudre un problème au lieu d'une autre personne.
• Gardez vos collègues en hauteur . Pour différentes personnes, «niveau» a différentes significations (pour mon équipe, cela signifie fiabilité / sécurité / commodité du produit). Si quelqu'un prend une décision que je n'aime pas, cela signifie soit que je sais quelque chose qu'il ne sait pas, soit qu'il sait quelque chose que je ne sais pas! Par conséquent, vous n'avez pas besoin de dire: «Hé, vous vous êtes trompé, vous devez faire X à la place», mais il vaut mieux leur donner simplement des informations supplémentaires qu'ils ne possédaient pas, et souvent cela résout le problème. Et bien souvent, il s'avère que quelque chose me manquait, et en fait leur solution était tout à fait raisonnable! Dans le passé, j'ai parfois vu des ingénieurs de premier plan essayer de maintenir des normes de qualité en répétant leurs opinions plus fort parce qu'ils pensaient que leur opinion était correcte. Personnellement, je n'ai pas trouvé une telle approche utile.
• Créez de nouveaux projets . L'équipe de développement logiciel n'est pas un lieu à somme nulle! Les meilleurs ingénieurs que je connais ne se laissent pas le travail le plus intéressant, ils créent de nouveaux projets intéressants / importants et créent un espace pour que d'autres puissent faire ce travail. Par exemple, un membre de mon équipe a commencé à réécrire notre système de déploiement. Le projet s'est avéré être un succès, et maintenant toute l'équipe travaille sur de nouvelles fonctionnalités qui sont devenues plus faciles à implémenter!
• Planifiez le travail de vos projets . Il s'agit de rédiger / rapporter une feuille de route pour les projets sur lesquels vous travaillez et de vous assurer que les gens comprennent le plan.
• Signaler les risques du projet à l'avance . Il est très important de reconnaître quand quelque chose ne va pas très bien, d'en informer d'autres ingénieurs / managers et de décider quoi faire.
• Signaler un succès!
• Pour réaliser des projets tiers au profit de l'équipe / entreprise . Je constate que de nombreuses personnes âgées réalisent parfois des projets petits mais importants (par exemple, créer des outils de développement / aider à établir des politiques), ce qui aide finalement beaucoup de gens à faire leur travail beaucoup mieux.
• Soyez conscient de la façon dont les projets sont liés aux priorités de l'entreprise.
• Décidez quand arrêter le projet . Il s'avère qu'il est étonnamment difficile de comprendre quand vous devez arrêter / ne pas commencer à travailler sur quelque chose. :)

Je mets d'abord «l'écriture de code», car en réalité cette tâche glisse facilement dans la liste des priorités. :)

Il n'y a aucun élément «faire des estimations / prévisions» dans la liste. Je ne suis pas encore très bien ici, mais je pense qu’un jour cela vaut la peine d’y consacrer plus de temps.

La liste semble longue. Il semble que si vous faites toutes ces choses, elles absorberont toutes vos ressources intellectuelles. Je pense qu'en général, il est logique d'isoler une partie et de décider: «En ce moment, je vais me concentrer sur X, Y et Z, je pense que mon cerveau va exploser si j'essaye de faire B et C».

Ce qui n'est pas un devoir

C'est un peu plus compliqué. Je ne dis pas que vous ne pouvez pas catégoriquement faire face à de telles choses. La plupart des principaux ingénieurs que je connais passent beaucoup de temps à réfléchir à ces problèmes et travaillent un peu dans cette direction.

Mais il me semble qu'il est utile de tracer une certaine frontière, parce que certaines personnes ont un sens élevé des responsabilités pour l'équipe et l'entreprise - et elles sont prêtes à tout assumer, ce qui les obligera à surcharger de travail et ne sera pas en mesure d'apporter une contribution technique, qui est en fait leur activité principale. Par conséquent, l'établissement de certaines limites aide à déterminer sur quelles questions il est logique de demander de l'aide lorsque la situation devient turbulente. Vos limites réelles dépendent de vous / de votre équipe. :)

La plupart des tâches suivantes sont des tâches de gestion. Avertissement: les managers font bien plus que ce qui est indiqué ici (par exemple, «créer de nouveaux projets»), et dans certaines entreprises, certains des éléments ci-dessus peuvent en fait être le travail d'un ingénieur principal (par exemple, la gestion du sprint).

• Assurez-vous que chaque employé est récompensé selon ses mérites pour son travail.
• Assurez-vous que le travail est bien distribué.
• Assurez-vous que les gens travaillent bien ensemble.
• Assurer la cohésion d'équipe.
• Discutez en privé avec chaque employé.
• Former de nouveaux managers, les aider à comprendre ce qu'on attend d'eux (même si je pense que les programmeurs de premier plan viennent souvent vraiment à une telle activité?).
• Gérer des projets tiers (à mon travail, c'est le travail de tout ingénieur menant ce projet).
• Soyez chef de produit.
• Diriger le sprint de gestion du sprint / déterminer les étapes de travail pour chacun / organiser des réunions hebdomadaires.

Il est utile de définir des limites de manière explicite.

J'ai récemment rencontré une situation intéressante lorsque j'ai discuté de mes responsabilités avec le manager - et nous avons réalisé que nous les regardions très différemment! Nous avons clarifié la situation, et maintenant tout est en ordre, mais cela m'a fait comprendre qu'il est très important de se mettre d'accord sur les attentes. :)

Quand j'ai commencé en tant qu'ingénieur, le travail était assez simple - j'ai écrit du code, essayé de proposer des projets qui avaient du sens, et tout allait bien. Mon manager a toujours eu une idée claire de mon travail, rien de trop compliqué. Maintenant, la situation a changé! Par conséquent, maintenant je crois que je dois déterminer le travail qui:

• Je peux faire / à long terme pour moi.
• Je veux faire / ce qui est généralement agréable et conforme à mes objectifs personnels.
• De valeur pour l'équipe / l'organisation.

Le libellé exact sera différent pour différentes personnes (tout le monde n'a pas les mêmes intérêts et forces, par exemple, je ne suis pas trop bon en révision de code!). Je pense que pour cette raison, il est encore plus important de discuter de ce sujet et de se mettre d'accord sur les attentes.

Ne vous contentez pas d'un travail que vous ne pouvez pas / ne voulez pas faire

Je pense qu’il est très important d’abandonner un travail que je ne peux pas faire ou qui n’apportera pas de joie à long terme! Il semble tentant d’effectuer beaucoup de travail, même si vous ne l’aimez pas vraiment («Oh, c’est bon pour l’équipe!», «Eh bien, il faut que quelqu'un le fasse!»). Bien sûr, parfois j'assume des tâches uniquement parce qu'elles doivent être terminées, mais je pense que pour la santé de l'équipe, il est vraiment important que les employés fassent ce qu'ils aiment généralement et ce qu'ils peuvent faire à long terme.

Par conséquent, je vais prendre de petites tâches qui doivent juste être faites, mais il est important de ne pas dire: "Oh, bien sûr, je passerai la plupart de mon temps sur ce que je fais mal et ce que je n'aime pas, il n'y a pas de problèmes" :). Et si «quelqu'un» doit le faire, cela signifie peut-être simplement que nous devons embaucher / former quelqu'un de nouveau pour combler le vide. :)

J'ai encore beaucoup à apprendre!

Bien que je sens que je commence à comprendre ce qu'est un «ingénieur en chef» (déjà 7 ans dans ma carrière), mais je sens toujours que j'ai encore besoin d'en apprendre beaucoup plus à ce sujet, et je serais intéressé d'entendre comment d'autres personnes définissent les limites votre travail!