Comment sortez-vous du rôle de responsable du code? [fermé]

Dans mes trois derniers emplois, j'étais responsable du code. Dans les trois cas, j'ai été embauché après que la majorité du code du projet ait déjà été écrite.

Je suis un programmeur autodidacte. Avant de commencer mon premier emploi professionnel, j'avais peut-être une douzaine de projets à mon actif que j'avais démarrés et expédiés avec succès.

Écrire un nouveau code et conserver le code existant sont deux tâches complètement différentes. C'est comme comparer un ingénieur aéronautique avec un mécanicien d'aéronef.

Cela craint particulièrement lorsque vous êtes un mécanicien d'avion travaillant sur un avion conçu par un ingénieur qui n'a fait aucune tentative pour que l'avion soit logique ou facile à entretenir.

Je commence à avoir envie d'être là quand le projet démarre, vous devez être une de ces personnes spéciales qui ont en quelque sorte transcendé le reste des gens dans le domaine de l'informatique. Que faut-il pour être dans cette position?

J'ai l'impression que cette question n'a pas vraiment de réponse facile, mais quelqu'un pourrait-il me donner quelques idées? Avez-vous déjà été au rez-de-chaussée d'un nouveau projet? Qu'a-t-il fallu pour y arriver?

La maintenance signifie différentes choses pour différentes personnes et se produit pour différentes raisons.

• Pire cas, le système initial a été assemblé à la hâte, l'équipe initiale a pris le crédit pour le tout. Ils ont suivi la règle des 80/20, donc bien qu'il puisse y avoir un produit minimum viable pouvant être vendu, de nombreux clients ont besoin de nombreuses corrections et de petites améliorations. De nombreux problèmes, mais pas beaucoup de gloire demeurent. Vous avez le travail le plus difficile et son ingrat. J'espère que ce n'est pas votre situation.
• Mieux, vous avez montré que vous faites attention à votre travail et que vous pouvez faire confiance pour apporter des modifications au produit mis en service sans le casser. Les problèmes qui restent sont trop difficiles pour les personnes qui ont martelé le système d'origine ensemble. Peut-être qu'ils n'ont pas réussi à construire le système pour durer, et vous êtes là, peut-être en remplacement, pour remettre les choses en ordre et sauver les clients, le projet et les bénéfices.
• Cas très probable, 60% des coûts des projets proviennent de la maintenance. Peut-être que c'est le timing, peut-être que votre organisation fait la distinction entre le nouveau développement et la maintenance, mais vous êtes à la majorité des 3 / 5ème parce que beaucoup d'entre nous font de la maintenance.

Voici quelques trucs à essayer:

• Faites un excellent travail, ayez une bonne attitude, soyez un leader d'idées.
• Autant que possible, travaillez en équipe, pas seul.
• Apprenez de nouvelles langues.
• Apprenez les nouvelles plateformes.
• Demander à travailler sur des programmes plus petits, peut-être même postuler auprès de petites entreprises.
• Obtenez des compétences et impliquez-vous dans la documentation. Lorsque les projets démarrent, même dans l'ère post-cascade, ils ont besoin de beaucoup de coordination écrite pour planifier, documenter, évaluer et clarifier les exigences.
• Il est dangereux que les projets commencent entre les mains de personnes qui n'apprécient pas la gestion des exigences, l'estimation et l'évaluation des risques, alors apprenez et pratiquez ces compétences autant que vous le pouvez.
• Obtenez une formation ou des certifications plus formelles. Cela peut augmenter votre statut et vous faire un choix plus attractif lorsque des équipes pour de nouveaux projets de développement sont formées.
• Lancez une entreprise ou un conseil sur le côté. Cela vous donne un débouché créatif pour cibler votre type de travail préféré et vous donne une meilleure appréciation de ce que c'est que de commencer sans code ni documentation.
• Rapprochez-vous de votre patron et des personnes qui planifient de nouveaux projets.
• À l'inverse, si vous êtes très proche des testeurs et de l'assurance qualité, leur sortie est souvent l'entrée de la maintenance, alors devinez avec qui votre patron pense que vous travaillez très bien?
• Faites-vous autant d'amis et gagnez le respect du plus grand nombre possible de développeurs greenfield.
• Les nouveaux développeurs sont capables de faire des choses, alors soyez prudent à propos de tout soupçon de critique ou de négativité. Donnez-leur vos idées librement sans blâme ni jugement. Vos idées n'ont pas besoin d'être présentées, dites-les simplement. Ne dites jamais, nous le faisions de cette façon, ou cela ne fonctionne pas, essayez ceci. Ne dites jamais, je ne sais pas, mais cela pourrait fonctionner. Dites simplement l'idée. Ou mieux, montrez-le.
• Trouvez et saisissez toute opportunité pour construire une preuve de concept qui pourrait se transformer en votre nouveau projet.
• Faites attention à qui vous assigne le travail. Habituellement, ce devrait être quelqu'un dans votre chaîne de commandement. Si ce sont vos pairs, repoussez-vous une partie du temps. Si c'est quelqu'un que vous supervisez, il doit y avoir une bonne raison pour laquelle le contrôle est inversé. S'il s'agit d'AQ ou de test, assurez-vous qu'il est important pour votre chaîne de commandement et qu'il n'est pas planifié de manière à retarder le travail que vous aviez promis plus tôt.
• Attention à la perfection. Les nouveaux développements sont souvent réservés aux personnes rapides, même si elles croisent les yeux et ne pointent pas les t.
• Passez du temps à apprendre et à mettre en pratique les premières compétences de projet adaptées à votre ligne de développement. Cela pourrait inclure: créer des référentiels sources, définir l'environnement de génération, configurer le serveur d'intégration constante, travailler en étroite collaboration avec l'équipe matérielle pour proposer de nouvelles cartes avec des packages de support de carte ou écrire de la puissance sur les auto-tests. Il peut même être utile de savoir comment travailler avec les achats pour acheter de nouveaux outils de développement, de la formation et du matériel COTS.
• Assurez-vous d'avancer avant la fermeture de votre projet de maintenance, peut-être en achetant vos compétences en interne auprès des chefs d'équipe et peut-être des managers, ou en externe.
• Maîtrisez toutes les technologies que vous connaissez et connaissez beaucoup de technologies.

Un rôle de maintenance peut être mis à votre avantage de plusieurs manières.

• Vous pouvez potentiellement travailler sur tous les projets de votre groupe ou même de votre entreprise.
• Si le nouveau développement et la maintenance sont séparés, vous pouvez potentiellement suivre une voie de leadership moins compétitive. Le plomb sur les nouveaux projets est très convoité, mais le plomb de maintenance peut être à votre disposition pour les demandes. Si vous avez des encouragements et du mentorat à donner, les membres de cette équipe peuvent l'apprécier davantage.
• Si le projet est en maintenance, vous êtes plus susceptible de vous connecter avec les clients. Mal géré, cela met fin aux carrières. Géré correctement, il reçoit une attention positive en dehors du développement difficile à trouver sans être un gestionnaire.

Cela dit, je suis le contre-exemple et non le modèle. Une grande partie de cette perspective provient de l'expérience et de l'observation.

De nombreux nouveaux programmes doivent encore être écrits.
Soyez prêt et vous y travaillerez étonnamment bientôt.

J'ai de mauvaises nouvelles pour vous: de nombreuses applications dont l'humanité a besoin sont déjà écrites, c'est juste qu'elles doivent être adaptées à un environnement en constante évolution.

Un jour, on vous demandera d'écrire une nouvelle partie du système, comme un nouveau module, et vous pourrez tirer parti de vos connaissances sur le développement de champs verts.

Jusque-là, vous pouvez essayer d'apprendre à refactoriser les applications héritées pour nettoyer les modules.

Une bonne lecture est « Travailler avec les applications héritées » et « Refactoring en modèles ». Si vous n'avez pas lu la refactorisation originale (Fowler), veuillez le faire. Et apprendre le développement piloté par les tests (TDD), aide toujours.

Dans le cas où vous travaillez avec PHP, j'ai écrit un article pratique que ce code fonctionne toujours ...

S'amuser!

Le moyen le plus simple de s'échapper est de changer complètement votre style de programmation et d'ajouter également de nouvelles compétences en même temps. Par exemple, vous pourriez essayer d'être chercheur. Ce n'est peut-être pas un emploi de prestige pour la première année, et ce n'est certainement pas aussi bien rémunéré que les emplois de programmation normaux (la première année si vous êtes chercheur / associé de recherche dans l'équipe d'une université - bien sûr, comme chercheur principal est assez en ligne avec le reste de l'industrie), mais cela mettra certainement vos compétences au service des problèmes les plus difficiles que vous pouvez trouver aujourd'hui. Après un tel travail, vous pourriez facilement sauter dans une meilleure position, à condition que vous ayez des projets intéressants à montrer à votre prochain patron.