Un travail de maintenance dédié gêne-t-il la carrière d'un programmeur? [fermé]

La majeure partie de mon travail au cours des trois dernières années a principalement consisté à entretenir les systèmes existants qui nécessitaient une mise à niveau ou une refonte occasionnelle avant d'être revendus à nouveau.

Je comprends le rôle essentiel que les programmeurs de maintenance dédiés doivent jouer dans les entreprises ayant un grand nombre de projets et un nombre limité de développeurs.

Mais au fur et à mesure que je juge le progrès de ma carrière actuelle et que je regarde mes pairs; les entrepreneurs et les développeurs d'entreprise; J'ai vraiment le sentiment d'être à la traîne, car j'ai beaucoup appris sur les domaines que j'ai abordés, mais pas beaucoup. J'ai commencé à résoudre ce problème en créant un blog, en travaillant sur mes propres projets de git-hub et en reprogrammant ma vie pour avoir le temps de faire du codage personnel après le travail de manière régulière.

J’estime que si je passais des entretiens dans d’autres entreprises pour échapper à des travaux d’entretien, je devrais me représenter comme étant assez subalterne au niveau des compétences, car je n’aurais pas le niveau de connaissances requis de la part d’une personne possédant trois ans d’expérience, centrée sur un domaine particulier. chemin dans le développement des fonctionnalités serait. Donc, la moitié de mon expérience de travail actuelle compterait pour rien à long terme.

Mais cela me conduit à mes questions principales, excuses si cela semble trop centré sur mon dilemme personnel:

Les rôles de programmation de maintenance dédiés finissent-ils par nuire au début de carrière? Les autres programmeurs ont-ils raison d'éviter de tels rôles? Ce travail vous oblige-t-il à faire des tâches similaires à moins que vous ne soyez prêt à recommencer à zéro?

Les rôles de programmation de maintenance dédiés finissent-ils par nuire au début de carrière? Les autres programmeurs ont-ils raison d'éviter de tels rôles? Ce travail vous oblige-t-il à faire des tâches similaires à moins que vous ne soyez prêt à recommencer à zéro?

Tout d’abord, sachez que vous êtes considéré comme un junior pendant un bon bout de temps. Vous pouvez obtenir des promotions arbitraires parce que vous êtes bon et que c'est le seul moyen de vous payer un salaire décent, mais vous serez toujours considéré comme un junior lorsque vous vous dirigerez vers votre prochain emploi.

Deuxièmement, si j'embauche quelqu'un qui a de 2 à 4 ans d'expérience, peu m'importe que son travail soit purement de maintenance. Si vous avez passé 10 ans en maintenance et que j'engage pour un projet dans les espaces verts, j'ai peut-être des questions mais, les premières années, honnêtement, je m'y attends un peu.

D'un autre côté, si j'embauche quelqu'un qui n'a JAMAIS travaillé dans la maintenance, je vais être plus méfiant. J'ai eu beaucoup de candidats à des emplois qui ont passé leurs 4 premières années à passer d'un "bon" travail à un autre et tous n'ont rien appris sur ce qui fait du code maintenable. Et, ne vous y méprenez pas, si j'embauche pour un projet dans un espace vierge auquel j'ai l'intention de rester, peu m'importe que vous conserviez le code, je tiens à ce que vous sachiez le laisser maintenable pour les futurs développeurs.

Ces autres programmeurs que vous mentionnez, qui évitent des emplois comme ceux-ci, les évitent généralement parce qu'ils sont moins amusants et non pas parce que cela gêne leur carrière.

Enfin, sachez qu’un pourcentage très important (environ 80%, selon moi, des travaux de développement de logiciels) représente plus de 50% de la maintenance.

Donc, pour passer à travers tout cela et répondre à votre question: Non, je ne pense pas que cela va entraver votre carrière. Sauf si vous y restez trop longtemps. La règle générale est la suivante: "une fois que vous commencez à ressentir la même année d'expérience, il est temps de partir". Si vous sentez que, chaque année, vous pensez être un meilleur développeur que l'an dernier, tout va bien (et cela me vaut 20 ans de carrière, autant que vous).

Dans tous les emplois, l'expérience que vous obtenez est spécifique à ce que vous faites, ce qui limite votre éventail de possibilités lorsque vous postulez à d'autres emplois basés sur cette expérience. Ce n'est pas spécifique à la maintenance. Je pense que d'autres questions sont plus pertinentes que de savoir s'il s'agit de maintenance ou de développement de nouveaux logiciels:

• Dans quelle mesure les technologies spécifiques avec lesquelles vous travaillez sont-elles répandues? Si vous maintenez quelque chose qui est obsolète et qui est rarement utilisé ailleurs, cela limiterait vos futures opportunités de carrière (tout comme le développement d'un nouveau logiciel pour un système / plate-forme / technologie qui n'est pas largement utilisé).
• Comment votre travail actuel vous prépare-t-il pour le travail que vous voulez faire à l'avenir? Comme vous l'avez souligné, les travaux d'entretien sont importants et seront toujours présents. Il n’ya rien de mal à avoir une carrière axée sur ce type de programmation; il y aura toujours beaucoup de possibilités pour les mainteneurs de système. Mais peut-être que ce n'est pas ce que vous voulez faire. C'est un problème si votre travail actuel ne vous prépare pas à ce qui vous intéresse.

Cependant, je ne serais pas trop inquiet. Une chose que vous dites est:

J'ai beaucoup appris sur les domaines que j'ai abordés, mais pas beaucoup.

Ne considérez pas cela comme un problème, car il peut être utilisé à votre avantage. Avoir une vaste expérience signifie qu'il y a un large éventail de choses auxquelles vous pouvez dire "oui, je l'ai fait." Beaucoup d'emplois exigent de l'expérience dans différentes technologies et tâches. Vous auriez probablement un avantage sur un développeur qui possède une très grande expérience dans une technologie.

En outre, de nombreux travaux impliquent un mélange de maintenance et de développement. Si vous souhaitez développer davantage de nouveaux développements, vous pouvez utiliser votre expérience de maintenance existante pour passer à un rôle mixte qui vous apportera une plus grande expérience en développement.

En conclusion, votre CV est probablement meilleur que vous ne le pensez. Cela dépend en grande partie de votre capacité à analyser les points forts de votre expérience, puis à communiquer ces points forts dans le processus de candidature et d'entretien.

Les rôles de programmation de maintenance dédiés finissent-ils par nuire au début de carrière?

Plus souvent qu'autrement - OUI, en supposant que:

• cette carrière signifie ici une expertise dans de nombreuses compétences techniques.
• que vous y passez plus de X ans, où il suffit de "définir" votre façon de penser.
• que vous ne faites rien de côté.
• que « mainteneur dédié » (voir EDIT ci-dessous) signifie que vous ne code pas pour maintenir ainsi que le code des choses nouvelles, mais que vous codez presque toujours de maintenir le travail ou même sur un projet en mode maintenance - pas de nouvelles fonctionnalités, EXIGE moins changements de code pour corriger le bogue.

Cela ne signifie pas que c'est toujours le cas.

Les personnes qui entretiennent des logiciels sont rarement encouragées (voir EDIT, ci-dessous) à effectuer des recherches, ne peuvent que rarement brancher une nouvelle bibliothèque ou base de données et passer quelques jours à en découvrir le fonctionnement. C'est (généralement) un travail stable qui nécessite peu de modifications de la base de code existante et qui "façonne" ainsi la façon dont vous abordez les problèmes ultérieurement. Je peux nommer de nombreuses entreprises qui ont une politique de maintenance de logiciel qui stipule explicitement "moins de changements dans le code = mieux", malgré les inconvénients que cela peut entraîner.

Les autres programmeurs ont-ils raison d'éviter de tels rôles?

Je connais de très bons préposés à l'entretien qui aiment leur travail et qui ne voudraient pas postuler pour autre chose précisément parce que c'est confortable là où ils se trouvent. Tout le monde n'aime pas apprendre de nouvelles choses de temps en temps. Donc, évitez-le ou recherchez-le en fonction de vos préférences.

Ce travail vous oblige-t-il à faire des tâches similaires à moins que vous ne soyez prêt à recommencer à zéro?

Plus souvent qu'autrement - OUI. Parce que vous avez déjà de l'expérience dans ce domaine, parce que vous "connaissez déjà les ficelles du métier", etc. Mais le changement est définitivement possible et peut se produire sans postuler pour un poste junior. Vous avez déjà commencé à faire des choses de côté, continuez comme ça! En fait, cela en vaut la peine et peut réduire le «fossé des compétences» que vous avez remarqué.

EDIT: Dan a fait remarquer (à juste titre) que les tâches de maintenance peuvent souvent être effectuées AVEC la recherche. C'est vrai. J'ai changé la réponse ci-dessus à deux endroits pour mieux résoudre ce problème.

De telles tâches pourraient sûrement être faites de cette façon et si elles sont - géniales! Cependant la plupart des mainteneurs AFAIK DEDIES des systèmes existants ont des politiques ou des attentes de la direction et les délais que - encore une fois, le plus souvent - les contraindre à résoudre le problème avec des changements moins possible. Souvent, la pression est suffisamment forte pour que, même si vous pouvez le faire de cette façon, vous ne le souhaitiez peut-être pas. Surtout si ce n'est pas VOTRE code: sans théorie (d'après Ryle et Naur) derrière cela, vous risquez de causer plus de dégâts que vous ne corrigez.

Néanmoins, il convient de noter: je n'ai pas de données globales fiables, je parle de ma propre expérience - j'ai travaillé dans une situation en tant qu'OP, j'ai recruté des personnes avec 4 à 10 ans d'expérience en tant que responsables de maintenance, j'ai parlé à de nombreux responsables de maintenance et j'ai connaître des personnes travaillant en tant que mainteneurs dédiés . Pas seulement des personnes qui codent de nouvelles choses, mais aussi du code pour maintenir un projet - des mainteneurs dédiés, dont le seul travail est de corriger des bogues et des correctifs, et même pas une nouvelle fonctionnalité, parce que c'est un ancien projet et qu'il est maintenant uniquement en "mode maintenance".

Je devrais me représenter comme étant assez subalterne au niveau des compétences car je n'aurais pas le niveau de connaissances requis de la part d'une personne possédant trois ans d'expérience axée sur une voie particulière du développement des fonctionnalités.

Correct. Vous ne pourriez pas dire "3 ans d’expérience dans la conception de systèmes utilisant X, Y et Z à partir de zéro", mais "3 ans d’expérience MAINTENANT les systèmes à partir de X avec Y, Z et Z", sauf si vous le souhaitez. mentir sur votre CV.

J’estime que si je devais interviewer dans d’autres entreprises pour échapper à des travaux d’entretien, je devrais me représenter comme étant assez subalterne au niveau des compétences, étant donné que je n’aurais pas le niveau de connaissances requis de la part d’une personne possédant trois ans d’expérience axée sur un domaine particulier. chemin dans le développement des fonctionnalités serait

Si vous voulez dire "Je conçois et construis des systèmes à partir de zéro", alors vous devrez vous classer comme junior.

Ce qui est assez courant en informatique (et je ne dis pas que c’est ce que vous faites), c’est que les gens supposent que, parce qu’ils travaillent depuis X ans, ils ont X années d’expérience et après {nombre indéterminé} ils doit être considéré comme un développeur senior {Widget}.

Maintenant, ne vous méprenez pas, il n'y a rien de mal en travail de maintenance, tout le monde doit le faire à un moment ou à un autre, mais vous vous êtes rendu compte que rester coincé à le faire trop longtemps rendrait probablement difficile votre tâche. sortir de ce rôle à l'avenir. Cela va souvent de pair avec le fait d'être "coincé" sans apprendre de nouvelles technologies / outils / méthodes.

Idéalement, vous souhaitez combiner un "nouveau" travail système et un travail hérité.

Sur une note positive, vous avez probablement vu beaucoup d'architectures différentes (bonnes et mauvaises), d'approches différentes, à quel point les mauvaises décisions peuvent amener les programmeurs hérités à travailler beaucoup plus dur par la suite. Ce sont tous des aspects positifs que l’on peut accentuer.

Bonne chance!

Sous un angle différent, je pense que se vendre en tant qu'expert en maintenance est une opportunité commercialisable.

En tant que propriétaire d'une société de logiciels ayant plusieurs projets en cours, l'un des principaux risques que je dois minimiser concerne les développeurs qui quittent le système, et la maintenance ultérieure de leur code.

Donc, en supposant que vous soyez capable de vous passionner pour le travail de maintenance (ce que je suppose être le cas puisque vous êtes prêt à bloguer sur votre expérience), si vous veniez me proposer vos services en tant que gourou de la maintenance, vous garantissant de les polir tous des différents projets de mes développeurs en refacturant, en optimisant et en documentant leur code pour une maintenabilité à long terme - et vous aviez un historique de performance pour sauvegarder votre garantie, je vous embauchais immédiatement.

Mon conseil serait de donner à ceci un essai approprié. Positionnez-vous comme un expert en maintenance et cultivez votre blog. Vous pouvez être sur quelque chose.