Options pour un programmeur principal qui préfère la programmation à la direction? [fermé]

Au début de cette année, j'ai été promu à un rôle de développeur principal après que le développeur principal de notre équipe a déménagé dans un autre département. J'ai environ 5 ans d'expérience professionnelle et en raison de la disponibilité et des performances passées, j'étais le principal choix de la direction pour diriger le projet. J'étais un peu inquiet, mais j'ai décidé que c'était une bonne opportunité d'avancement professionnel et d'expérience, alors j'ai accepté.

Mais ma conclusion jusqu'à présent est que je ne l'apprécie pas autant que ma position de développeur précédente. Bien que j'ai dirigé avec succès une équipe de 5 développeurs à travers plusieurs versions, je ne touche presque jamais à aucun code. Au lieu de cela, j'effectue la planification et la conception et la gestion de l'équipe, ainsi que des révisions de code. La nécessité de garder une trace de bien d'autres choses et de planifier des tâches afin qu'elles puissent être affectées à l'équipe, me donne littéralement des maux de tête presque tous les jours. Même si je fais rarement des heures supplémentaires, je me sens le plus épuisé chaque jour lorsque je quitte le travail, et je ne pense même pas avoir autant apprécié le temps libre.

Alors ma question: comment géreriez-vous, ou comment avez-vous géré, une telle situation? Pour les personnes dans des situations similaires, avez-vous trouvé des moyens de mieux gérer votre équipe, les tâches et le temps qui vous ont fait apprécier le travail? Ou avez-vous trouvé un moyen de revenir à une position plus orientée vers le développement? Je sais que les postes de développeur principal paient presque toujours un salaire plus élevé, mais je me vois arriver à un point où je me soucie moins de l'argent et des promotions que de mon plaisir de mon emploi actuel.

Je n'ai discuté de cela avec personne dans la direction car je pensais que je devrais essayer de m'adapter pendant au moins un an.

La réponse que je fournis ici est ma meilleure estimation de ce qui pourrait potentiellement fonctionner, mais je ne l'ai pas vu fonctionner car j'essaie moi-même de sortir d'une situation similaire où vous vous trouvez. Le tout est encore une expérience d'apprentissage pour moi, mais je vois une tendance positive dans mon équipe.

Dans mon entreprise, j'ai été promu chef d'équipe (ils l'appellent "chef de conception") et en raison du manque de personnes qui connaissent le produit et ont suffisamment d'expérience, je me suis porté volontaire pour diriger 2 équipes différentes. Il y a quelques mois "pour aider au planning", la direction a doublé la taille de ces 2 équipes.

Une chose que j'essaie de faire ...

1. Expliquez clairement à tout le monde (y compris à la direction) que le mien et le poste de chacun ne sont pas une affectation permanente. Tout le monde est le bienvenu pour monter dans l'assiette, avoir une vision plus large du projet et participer aux décisions d'architecture / conception. J'aurai le dernier mot (pour l'instant) s'il y a un désaccord sans résolution, mais jusqu'à présent cela ne s'est jamais produit.
2. Concentrez-vous sur le développement et la croissance des autres. J'ai eu des discussions (presque philosophiques) avec différents développeurs à différents moments sur le codage et la conception et les différentes approches pour faire les choses. Certaines de ces discussions sont liées au travail réel, d'autres sont de purs exercices de réflexion. J'avais un gars avec plus de 20 ans d'expérience, je suis retourné dans sa bibliothèque et j'ai acheté un livre C ++ parce qu'il était intéressé par des trucs de bas niveau que j'ai fait avec la méta-programmation de modèles. Ces discussions sont quelque peu contagieuses et après avoir abordé ces sujets suffisamment de fois, les gens commencent à penser à ce genre de choses par eux-mêmes.
3. Déléguez autant que possible à d'autres personnes. Bien que je regarde beaucoup de choses, je ne participe pas à chaque révision de code. Au lieu de cela, je fais des revues de code pour nos gars intermédiaires et je laisse ces gars faire la revue de code pour certaines personnes plus vertes. Je considère les revues de code comme un outil de transfert de connaissances plutôt que «veillons à lire chaque ligne et à trouver tous les bogues possibles».
4. Une fois que les interfaces sont définies et que la conception de base est en place, je laisse même les gars les plus récents avoir autant de liberté que possible pour coder les internes des classes. Oui, beaucoup de ce code est loin d'être parfait, mais il est testé et cela fonctionne. Si elle franchit une certaine frontière subjective en termes d '"odeur de code" et qu'ils ne l'ont pas refactorisée, je suggérerais que certaines classes doivent être décomposées ou réorganisées. C'est parfois douloureux, mais quand je reviens quelques jours plus tard et que je reçois une réponse, "Je déteste l'admettre, mais ce code est tellement mieux maintenant", ce qui me donne en fait une sensation de chaleur et de flou.
5. Défiez les gens. Au lieu de simplement leur attribuer une fonctionnalité à ajouter au produit, demandez-leur d'ajouter ces fonctionnalités, mais faites-le sans augmenter le nombre de fonctions / membres de données dans les classes existantes. Si vous devez mettre quelque chose de nouveau, vous devez retirer quelque chose d'existant et prendre le temps de comprendre ce que c'est. Tout le monde connaît la refactorisation, mais sans force supplémentaire au début, il semble que les gens aient besoin d'aide pour faire ce saut pour le faire. Au minimum, je me fais un devoir de visiter ce point pendant à peu près chaque révision de code.
6. Tout est question d'EQUILIBRE. Vous ne pouvez pas être la seule personne âgée de l'équipe à surveiller les autres. Vous ne pouvez pas passer votre semaine entière à des réunions et à faire des évaluations. Vous ne pouvez pas vous attendre à rattraper chaque erreur de votre équipe. À la fin de la journée, vous devez vous allouer du temps pour être le chef de file, mais vous devez également allouer du temps pour être développeur. Je deviendrais fou si je ne pouvais pas coder. Même avec tout le reste, je m'assure toujours d'avoir le temps d'écrire du code et pas seulement du code mais des trucs vraiment, vraiment chouettes. Je viens de mettre la main sur des livres de programmation de méta-modèles et j'ai commencé à creuser dans Boost. Les gars qui ont inventé ces trucs doivent être fous (dans le bon sens). Si votre gestion commence à vous embêter pour savoir pourquoi tout n'est pas examiné ou pourquoi un noob examine un autre code noobs, vous avez juste besoin d'expliquer tout l'équilibre et que l'équipe n'a tout simplement pas assez de personnes expérimentées et à la fin de la journée "c'est ce que c'est". Si votre équipe a des personnes âgées, alors il est temps de les responsabiliser et de leur donner la liberté de faire leurs propres conceptions / critiques / aider les autres et ne pas les traiter comme de simples générateurs de code. Avec l'autonomisation vient la liberté et les gens aiment la liberté. Si vous avez des développeurs qui ne se soucient pas de la liberté / autonomisation, ça va. Chaque équipe a encore besoin de codeurs purs, assurez-vous simplement de rechercher l'équilibre. s il est temps de les responsabiliser et de leur donner la liberté de faire leurs propres conceptions / critiques / aider les autres et de ne pas les traiter comme de simples générateurs de code. Avec l'autonomisation vient la liberté et les gens aiment la liberté. Si vous avez des développeurs qui ne se soucient pas de la liberté / autonomisation, ça va. Chaque équipe a encore besoin de codeurs purs, assurez-vous simplement de rechercher l'équilibre. s il est temps de les responsabiliser et de leur donner la liberté de faire leurs propres conceptions / critiques / aider les autres et de ne pas les traiter comme de simples générateurs de code. Avec l'autonomisation vient la liberté et les gens aiment la liberté. Si vous avez des développeurs qui ne se soucient pas de la liberté / autonomisation, ça va. Chaque équipe a encore besoin de codeurs purs, assurez-vous simplement de rechercher l'équilibre.
7. Votre temps est précieux. Demandez donc à l'équipe de vous envoyer par e-mail toutes les questions critiques non chronologiques auxquelles elle peut attendre quelques heures avant d'obtenir une réponse. Lorsque la question est posée, toute l'équipe doit y être copiée. Finalement, lorsque vous avez une pause dans votre journée, vous pouvez jeter un œil au problème et aider la personne, mais à plusieurs reprises, quelqu'un d'autre peut déjà vous avoir battu jusqu'à la réponse et vous n'avez rien à faire. Évidemment, en tant que responsable, je reste disponible et je le dis clairement parce que je crois que l'un de mes objectifs est de faire en sorte que personne dans l'équipe ne reste coincé pendant de longues périodes sans progresser.
8. Assurez-vous que votre équipe utilise autant d'outils que possible pour rendre les communications plus efficaces. Par exemple, nous avons un site wiki et chaque fois que le même problème apparaît plusieurs fois, je demande au dernier gars que j'ai aidé à créer une page wiki.

Je n'en ai discuté avec personne dans la direction

Je pense que vous savez que cela aiderait probablement. Communiquer son inconfort avec une position ne signifie pas nécessairement quoi que ce soit de concret. Il permet à la direction de savoir quelles cartes elle détient, et si c'est une bonne gestion, elle essaiera de trouver un moyen d'utiliser votre meilleur potentiel. Ne vous contentez pas de moins.

Une fois votre projet terminé, recherchez une position plus orientée programmeur dans votre entreprise ou en dehors.

Discutez avec la direction du fait que vous aimeriez moins de gestion et des compétences pratiques plus techniques.

Cela ressemble à votre position de PM par rapport à un développeur principal. Je considérerais qu'un développeur principal coderait davantage.

Point de vue des employeurs :

Si vous aimez le travail actuel et avez une bonne histoire là-bas, je voudrais vous garder et trouver une place pour vous, donc je ne m'inquiéterais pas trop de leur parler.

Un grand développeur est une chose précieuse, mais vous devez leur vendre que vous valez mieux faire du codage et peut-être du design que de faire du jonglage.

Donnez-leur un moyen de vous reculer en établissant un plan de relève. Fondamentalement, vous trouvez quelqu'un dans l'équipe actuelle qui est intéressé à faire les choses qui vous donnent mal à la tête, au cours des 6-9 prochains mois, vous les entraînez, en leur donnant vos tâches une à la fois.

Choisissez d'abord quelque chose de facile, comme des mises à jour hebdomadaires de statut:

• Asseyez-les à côté de vous lorsque vous effectuez une mise à jour de statut.
• Asseyez-vous à côté d'eux pendant la prochaine mise à jour du statut.
• Laissez-les le faire par eux-mêmes et révisez-le avant qu'il ne sorte pour la finale.

Donnez-leur ensuite progressivement les tâches supplémentaires jusqu'à ce que vous ayez transféré la majoration de vos responsabilités supplémentaires.

La raison pour laquelle ces emplois moins souhaitables sont mieux payés est que s'ils n'étaient pas, personne ne les ferait, pas nécessairement parce qu'ils nécessitent un niveau de compétence plus élevé ... l'offre et la demande.

Mais pour vous faire payer plus cher ... Si c'était moi, je voudrais entendre que vous restez, vous aiderez cette personne si nécessaire, serez le mentor des nouveaux gars, le concepteur / cerveau clé / expert du domaine plutôt que chef de projet. Fondamentalement, c'est une position précieuse, quelqu'un d'autre peut faire le tour et jongler (pour plus de salaire évidemment).

Je pense que si vous présentiez à votre employeur un plan de 6 à 9 mois qui disait

• Une bonne explication de la raison pour laquelle vous pensez qu'il vaut mieux que vous reveniez à vous concentrer sur le codage par rapport aux autres responsabilités.
• Dans qui subsister ... ou doit-il trouver quelqu'un ... ce sera un facteur clé, je pense.
• Rach mois pendant 6 mois quelles responsabilités vous confieriez à la nouvelle personne
• Quelles responsabilités vous garderiez aux épaules (comme la conception, peut-être assis sur les revues de code, etc.).
• Une idée de la baisse des salaires que vous seriez prêt à accepter (quelque part entre l'original et maintenant), mais laissez-les en parler.

Si vous organisez cela comme un plan pour moi, en tant qu'employeur, je serais plus qu'heureux de travailler avec vous pour que cela se produise.

Bonne chance.

Je suis exactement dans ta situation. la réponse se résume à la relation que vous entretenez avec votre manager. Dans mon cas, c'était un très bon, alors je l'ai pris un jour pour lui dire que je n'aimais pas le travail, que je me sentais trop stressé et que je voulais revenir au codage. Il était beaucoup plus heureux d'entendre cela que de me faire entrer et de quitter. Nous avons donc élaboré un plan pour que quelqu'un d'autre prenne le relais en tant que chef d'équipe et moi pour revenir au codage.

2 questions qui ne ressortent pas de votre message:

• Êtes-vous dans une entreprise qui tire directement de l'argent du logiciel que vous écrivez (comme Google, Microsoft ou Fog Creek) ou êtes-vous dans une fonction subsidiaire (comme dans une banque ou une entreprise alimentaire)?

• Le PDG est-il un technologue ou quelqu'un qui a grandi via des rôles commerciaux?

Si vous êtes une entreprise de logiciels avec un PDG technologue, ne vous inquiétez pas. La direction de l'entreprise saura qui sont les précieux développeurs et fera tout ce qu'il faut pour les garder. Si les dirigeants sont tous des gens qui ont obtenu leurs galons "gérer les gens" ou "gérer les budgets", soyez inquiet. Soyez doublement inquiet si vous travaillez dans un service informatique interne. Si tel est le cas, vous devez accepter qu'un bon équilibre entre vie professionnelle et vie privée soit la récompense pour rester développeur.

Un dernier point - faites ce qui vous rendra heureux. Les conseils de tous les autres sur les choix de carrière comme celui-ci concernent ce qui les rendrait heureux - et cela vous concerne.