Quelles sont les principales choses qu'un programmeur attend du programmeur principal?

Récemment, j'ai lu les 5 types de boss suivants et comment s'y prendre , décrivant les atours du pire patron. Je viens de commencer à diriger une petite équipe de développeurs de logiciels.

J'aimerais savoir quelles sont les principales choses qu'un programmeur attend de son programmeur principal ou quelles sont les choses à éviter lors de la gestion d'une équipe.

De plus, j'aimerais savoir comment garder les programmeurs satisfaits et créer un environnement productif et complet pour mon équipe.

Des choses qui semblent bien fonctionner pour moi:

• Donnez du travail utile et encouragez l’appropriation - même quand un problème se pose, ne le résolvez pas, discutez-en et donnez à la personne un aperçu du problème pour qu’elle puisse le résoudre elle-même.
  • modifier - ajout - cela devait également inclure - rester en dehors des détails. Supposez que vos collaborateurs en savent assez pour accomplir leur mission sans microgestion ni obligation de s'enregistrer en permanence. Établissez un ensemble de règles indiquant le moment où ils doivent s’enregistrer - ce qui ne devrait se faire que lorsque le travail est terminé ou si véritablement gâché par une intervention sérieuse. nécessaire. Si possible, évitez même de devoir être au courant des problèmes de support inter-équipes.
• Soyez honnête - cela a plusieurs corollaires:
  • Soyez honnête avec vous-même - "Je n'aurai pas le temps avant mardi", "Je n'ai jamais fait ça, voici ma meilleure supposition", etc.
  • Soyez honnête à propos de l'équipe et de sa place dans l'entreprise. Si vous savez quelque chose au sujet des affaires, dites-leur si vous le pouvez et dites-leur ce que vous savez comme des faits clairs.
  • Soyez honnête en donnant des commentaires - ne mâchez pas les mots ou utilisez la pédale douce si vous avez des commentaires négatifs. C'est différent de "brutalement honnête" - vous pouvez toujours avoir de la compassion, mais si quelque chose ne va pas, dites-le.
  • Soyez honnête lorsque vous savez que le travail consiste davantage à réduire les formalités administratives qu'à accomplir quelque chose de significatif. Dans la vie de chacun, un travail insensé tombera. Ne prétendez pas que cela a du sens. Appelez-le comme il est, pour que vous puissiez tous vous concentrer sur le dépassement et sur quelque chose d'utile.
• Ecoute . Au moins 50% de votre travail est à l'écoute, peut-être plus. Vous êtes soudainement devenu responsable non seulement du travail technique, mais aussi des personnes qui le font. Vous devez écouter pour apprendre non seulement sur les problèmes rencontrés par l'équipe, mais également sur la façon dont votre personnel aborde le problème et sur les faiblesses de l'équipe en tant que groupe.
  • Corollaire important - l'écoute peut mener directement au point n ° 1 - donner un travail significatif - les ingénieurs sont doués pour proposer des moyens de faciliter le développement. Vous ne pouvez pas tout approuver, mais si l’idée est bonne, confiez la tâche à l’ingénieur, et ils vous ont essentiellement fait travailler pour vous. Ils ont créé un travail utile et vous ont expliqué en quoi il consiste.
• Dites "merci" . Je sais, cela semble évident. Nous aimons tous l'argent, les outils de meilleure qualité, un environnement de travail plus agréable et des promotions. Pour y parvenir, vous devez déployer de nombreux efforts, chacun méritant un "merci". "Merci" est totalement gratuit, vous ne les manquerez jamais, et savoir que votre responsable a vu et apprécié votre travail acharné est définitivement motivant.
• Passez du temps à la vue d'ensemble , même si cela signifie sacrifier une partie du travail quotidien qui vous a valu le poste. Il est probablement vrai que vous pouvez coder mieux que certains de vos collaborateurs, mais si vous ne passez pas suffisamment de temps sur l’ensemble, l’équipe, la direction générale du projet, l’état de votre base de code, l’efficacité de vos processus. , l’environnement de votre équipe - alors vous ne ferez pas le travail dont ils ont besoin.
• Apprenez à être un tampon pour votre équipe . Les équipes d'ingénierie fonctionnent mieux lorsqu'elles ont le temps de faire de l'ingénierie. La bureaucratie d'entreprise n'est pas de l'ingénierie. Tout ce que vous pouvez faire pour prendre l’agacement ennuyeux 1 réunion par an / mois / semaine avec des personnes externes est préférable. NOTE: Cela ne signifie pas des réunions agiles avec les parties prenantes - c'est de l'ingénierie, votre équipe doit être là pour ça. Je parle de la réunion avec les installations qui souhaitent placer une machine criard près de votre équipe ou du groupe de processus qui souhaite que votre équipe remplisse les documents en trois exemplaires avant que le code ne soit enregistré. Vous êtes le système d'absorption de la flak.
• Supposons que les personnes à problèmes ne soient pas méchantes , ce sont des personnes qui veulent faire le bien mais ne savent pas encore comment. Vous ne serez pas en mesure de réparer tout le monde, mais souvent, les quelques premiers ratés complets sont autant un facteur d'échec de la communication que d'incompétence ou de malice délibérée. Si vous partez du principe que les gens ne sont pas méchants, vous avez un espoir décent d'éviter un certain nombre des archétypes des patrons maléfiques de la liste ci-dessus.

Et probablement le plus important ... le respect . Si vous ne pouvez honnêtement pas respecter les membres de votre équipe, vous devez vous efforcer de changer cela (qu'il s'agisse d'enseigner aux gens ou de changer votre effectif). Donnez le respect le premier jour et vous le retrouverez, traitez les gens avec un manque de respect et vous n’obtiendrez jamais le respect en retour.

Pris ensemble, si vous faites la plupart de ces choses, la plupart du temps, votre équipe vous laissera le bénéfice du doute lorsque vous montrerez que vous êtes humain et que vous bousillez totalement quelque chose. :) Chaque chef a ses propres inconvénients. Il s’agit tout autant de développer une relation avec votre équipe dans laquelle ils peuvent vous aider à compenser vos faiblesses tout comme vous les aidez avec les leurs.

Eh bien, l’une des choses les plus importantes à apprendre est que très souvent, vous ne pourrez pas les garder heureux, car vous ne pourrez tout simplement pas leur donner ce qu’ils veulent.

Les meilleurs gestionnaires pour lesquels j'ai travaillé sont les plus honnêtes, qui défendront leur équipe contre toute la merde que la haute direction essaie de leur lancer, et surtout, ÉCOUTEZ leur équipe.

Je crois fermement que l'un des aspects les plus critiques du rôle de senior ou de lead est la disponibilité pour les juniors. Les seniors et les leaders ont souvent des tâches pour lesquelles ils sont seuls habilités (nous n'accordons pas aux juniors le droit d'écrire sur la mise en scène et la production, par exemple). De plus, une partie importante de votre travail consiste à encadrer les juniors, ce qui signifie répondre à des questions sans les ignorer. Plus vous êtes âgé, plus vous risquez d'être interrompu par d'autres personnes qui ont besoin de quelque chose de votre part. Vous devez abandonner ce panneau "Ne pas déranger" et apprendre à travailler avec des interruptions.

L'écoute est importante.

S'il vous plaît et merci sont importants et ne coûtent rien.

Ne vous attendez pas à plus que ce que vous êtes prêt à donner. Si vous voulez que je travaille jusqu'à 3 heures du matin, vous feriez mieux d'être là à mes côtés. Rien n'est plus décourageant que de travailler pour une personne qui part à l'heure tous les jours, immédiatement après vous avoir confié une tâche à accomplir avant 7 heures.

Être juste. Ne jouez pas les favoris (surtout ne donnez pas les favoris à votre copine ou à votre copain avec les meilleures choses). Traitez tous les employés avec respect (même les personnes que vous n'aimez pas personnellement).

Être décisif. Ne laissez pas les décisions en suspens pour que personne ne puisse progresser ou, pire encore, les modifier toutes les cinq minutes.

Lève-toi pour ton peuple. Vous ne les gagnerez pas tous, mais les gens marcheront à travers le feu pour quelqu'un qui les soutient tout au long de la chaîne.

Soyez prêt à être le méchant si nécessaire. Une pomme pourrie peut détruire une équipe de développement, ne vous en tenez pas à cette personne, car vous ne voulez pas confronter son mauvais comportement (cela s'applique davantage aux responsables et aux superviseurs officiels). Lorsque vous avez de mauvaises nouvelles, dites à l’équipe, ne gardez pas cela secret (elles le découvriront un jour, puis elles sont folles à la fois des mauvaises nouvelles et de la conservation des secrets). Vous n'êtes pas là pour être populaire mais pour faire le travail. Toute personne occupant un poste de direction ou de quasi-direction doit être prête à être impopulaire.

Apprenez à vendre des idées à des niveaux supérieurs et à enseigner ces compétences à vos développeurs.

Comprenez l’importance du domaine commercial et devenez un expert en la matière ainsi qu’en matière de programmation.

Les mots clés ici sont confiance et responsabilité.

Vous devrez simplement avoir confiance que les membres de votre équipe sont compétents et concentrés sur l'accomplissement de leurs tâches. En ne vous mêlant pas trop, vous les laissez essentiellement "assumer" la responsabilité de leur travail.

IMHO, cela seul fait des merveilles dans la création d'une atmosphère saine.

Eh bien, OMI, je m'attends à ce que le développeur principal, le responsable ou tout ce qui le concerne, se range aux côtés de l’équipe de développement pour éviter des délais idiots, pas de ressources, mais pour construire Rome, des heures supplémentaires obligatoires, etc., tout ce qui réduit la productivité et rend les gens malheureux.

La principale chose à éviter pour l’OMI est d’être un "oui-mec" pour la direction et d’être toujours d’accord, peu importe ce qu’ils disent (un con-kisser, en d’autres termes)

Compétences sociales. Parfois, les gens reçoivent le titre "Senior" et oublient qu'ils ne sont pas omniscients. Ils estiment que la promotion est un commentaire de leurs compétences techniques suprêmes et de leur génie latent. En réalité, ils sont maintenant des gestionnaires de très bas niveau. Ils doivent comprendre comment et qui motiver, qui laisser, comment faire des compromis et quand écouter.

La possession. Les pires programmeurs seniors ne s'approprient pas ce sur quoi ils étaient "seniors". Ils se rabattent sur la tactique du dodo travail et du blâme qui ont conduit à leur promotion (plus que probablement en dansant sur la tombe de la personne qu'ils ont jetée dans le bus). Maintenant, ils ont besoin de comprendre que c'est leur faute dans l'élingue et que c'est leur responsabilité de s'approprier la conception, le plan et une grande partie du travail.

Expérience. Je m'attends à ce que les développeurs seniors aient tout vu deux fois. Ils devraient comprendre le domaine et la technologie. Ils devraient attaquer les risques de manière agressive et pouvoir perdre du temps à perdre leur temps.

La cohérence est l'une des choses les plus importantes. Si les développeurs peuvent prédire comment vous allez agir, ils seront plus heureux. Même si vous êtes constamment un outil complet, il vaut mieux être parfois cool et parfois être un outil. Cela étant dit, ne soyez pas un outil.

Connaissance et communication. Connaître la source et beaucoup, beaucoup , plus important encore, être capable de l'expliquer à n'importe qui, d'une manière qu'ils vont comprendre et conserver.