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


52

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?


Je pense que la technologie avec laquelle vous travaillez au début de votre carrière est (beaucoup) plus importante que votre travail de maintenance ou de développement. Si vous réalisiez un nouveau développement dans une langue maison ou dans une langue ancienne avec une demande faible, ce serait probablement bien pire que de ne pas le faire dans une langue à forte demande.
Juillet

6
Cela construit certainement du caractère.
quant_dev

Réponses:


70

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).


25
+1 Faire la maintenance rend quelqu'un un meilleur développement.

8
+1 Faire l'entretien vous-même ou le projet de quelqu'un d'autre vous oblige à apprécier les conséquences des décisions prises plus tôt dans le projet et à en tirer des leçons.
Ophidian

Bien que l’idéal soit d’avoir de l’expérience en matière de maintenance, j’estime que ce que vous apprenez du développement d’un projet réussi> de ce que vous pouvez apprendre en maintenant le projet de quelqu'un d'autre. Maintenance peut vous apprendre à ne pas faire, mais comme le dit si bien Jason Fried: apprendre de l'échec peut vous dire quoi ne pas faire la prochaine fois, mais cela ne vous dit pas quoi faire la prochaine fois .
Korey Hinton

@KoreyHinton: Je suis sûr que Jason Fried, un entrepreneur prospère, croit ce qu'il dit en termes d'entreprise. Je dirais que a) il ne sait pas vraiment ce qu'il pourrait faire de mieux, car tout s'est très bien passé pour lui, b) soutenir DHH and Rails était de 90% du succès de 37signals et c'est un pari qui ne paierait pas Dans 90% des cas, et même c), même Jason ne dirait probablement pas que le fait d’être un entrepreneur signifie nécessairement apprendre à devoir assembler des logiciels mal écrits.
Pdr

@pdr Vous avez raison, les deux choses ne se traduisent pas exactement. Comme je suis toujours étudiant, je parlais d’opinion plutôt que d’expérience. Personnellement, je préfère écrire un nouveau code que de conserver le code écrit par d’autres, mais il semble que la maintenance soit quelque chose que je vais faire beaucoup dans ce domaine.
Korey Hinton

13

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.


+1 Sur la vaste expérience . Ayant effectué 15 ans de développement et la dernière année en maintenance, je peux dire par expérience que j'ai touché beaucoup plus de langues et de plates-formes que je n'aurais pu rester en développement. En tant que pigiste, avoir beaucoup de largeur (généraliste) me donne le sentiment réconfortant de ne pas perdre mon emploi bientôt. C’est peut-être aux dépens de la possibilité de gagner plus d’argent lors de la spécialisation (spécialiste), mais je préfère réduire le risque.
Lieven Keersmaekers

2

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".


@ dan1111, quelles parties ne le sont pas? Bien que ce soit un doublon, je ferai volontiers une meilleure réponse.
LAFK dit Rétablir Monica

Merci Dan. J'élargirai un peu ma réponse pour mettre en évidence des parties qui, à mon avis, contiennent la réponse à votre commentaire.
LAFK dit Réintégrer Monica

+1 pour le travail supplémentaire sur la réponse. En particulier, il est utile d’expliquer l’ampleur de votre propre expérience pour établir la crédibilité de la réponse.

"Les personnes qui maintiennent un logiciel ... peuvent rarement connecter une nouvelle bibliothèque ou base de données et passer quelques jours à en comprendre le fonctionnement." Ce n'est pas vraiment mon expérience. Les programmeurs de maintenance doivent être capables de plonger dans quelque chose d'inconnu et de comprendre rapidement son essence (qu'il s'agisse d'un programme ou d'une bibliothèque). Du moins, c'est le cas si vous maintenez des choses différentes; si vous maintenez la même chose tout le temps, pendant des années, les inconvénients qui en découlent ne sont pas causés par la «maintenance», mais par le fait de travailler trop longtemps sur la même chose (peu importe où elle se trouve le cycle de vie).
user1172763

Bonjour @ utilisateur1172763. Je dois dire que votre définition de maintenance est assez extraordinaire. Je pense que la partie que j'ai ajoutée pour Dan traite de cas de maintenance plus intéressants, comme le vôtre. Cependant, je ne crois pas qu'il s'agisse d'une maintenance standard. Juste pour vérifier - la raison pour le vote négatif est parce que votre expérience ne correspond pas à ma réponse? Ensuite, veuillez indiquer vos sources, comme je l’ai dit pour que les autres puissent lire et prendre une décision.
LAFK dit Réintégrer Monica

1

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!


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.