Je serais très réticent à faire un travail qui était principalement de maintenance. Voici pourquoi:

1. C'est mauvais pour sa carrière (en interne). Les efforts héroïques pour maintenir le logiciel en état de marche ne sont presque jamais reconnus car les gens ne voient que le statut quo. Quelqu'un qui est resté éveillé toute la nuit pour terminer une nouvelle fonctionnalité recevra beaucoup d'éloges. Quelqu'un qui l'a fait pour empêcher le logiciel de tomber en panne? Personne ne sait même qu'ils l'ont fait. Au cours de ma courte carrière certes, je n'ai jamais vu d'éloges pour un bon travail d'entretien. J'ai entendu beaucoup de personnel de maintenance / informatique se plaindre d'être sous-estimé et pour la plupart, ils le sont. Demandez-vous ce que votre haute direction pense des développeurs de support? En savent-ils beaucoup sur les développeurs de support? Qui a été félicité?

2. C'est mauvais pour sa carrière (en externe). Un de mes amis est un développeur très expérimenté et pendant deux ans, il a principalement maintenu ce grand application. On lui a constamment demandé dans les entretiens futurs pourquoi il ne faisait que peaufiner, pas construire. La maintenance n'est pas considérée par beaucoup comme une ingénierie. Vous le voyez également dans de nombreux domaines en dehors de l'ingénierie. Lorsque je postulais à l'université, la chose à la mode était de fonder une association caritative et de construire une école. Pourquoi ne pas rejoindre et construire un existant? Vous n’en auriez pas le mérite, comme même s’ils obtenaient le même résultat, car cela n’impliquait ni «leadership» ni «initiative». Les gens qui construisent quelque chose sont beaucoup plus respectés que ceux qui font fonctionner quelque chose, même si ce dernier est plus difficile.

3. C’est mauvais pour sa carrière (technologie). Les projets de maintenance sont plus souvent construits avec des technologies plus anciennes. Le problème est que la technologie a une courte durée de vie dans le développement de logiciels. Si vous travaillez sur un projet avec JQuery au lieu de React ou un projet qui utilise Ant au lieu de Maven, Ruby au lieu de JS, votre valeur marchande diminue. Si vous utilisez AngularJS, Bootstrap 3, les versions Java inférieures à 8, Objective C, etc., vos options deviennent chaque jour plus limitées car peu de nouveaux développements sont effectués dans ces langages.

4. C'est plus difficile. Aujourd'hui, j'ai résolu un bug en ajoutant une vérification et en supprimant la table dans la base de données. Mon projet est un greenfield qui n'a pas encore été mis en production, nous n'avons donc pas besoin de maintenir la compatibilité ascendante ou de conserver les données existantes. La correction de ce bogue tout en conservant les données nécessiterait d'exécuter un script pour supprimer certaines lignes ou de modifier l'API pour sélectionner la bonne.

5. Vous êtes à jamais un centre de coûts. L'un des avantages d'un projet greenfield est qu'il permet aux dirigeants de s'impliquer et de valoriser davantage le projet . J'ai rencontré ces deux développeurs mobiles lors d'une conférence qui ont développé et mis à jour une application dans Xamarin pour la compatibilité croisée. Ensuite, il a été question de réduire les coûts et d'externaliser la maintenance de l'application en Inde (je vis au Canada, donc le coût est sensiblement différent) et d'économiser deux salaires de développement. Vous savez comment ils se sont sauvés? Parler de «problèmes de compatibilité» et convaincre la direction de leur demander de réécrire l'application à partir de zéro dans React Native. Cela a sauvé leurs emplois et leur a valu des augmentations. S'ils sont intelligents, il y aura plus de «problèmes de compatibilité» et un besoin de réécrire dans Flutter.

Un travail de développeur doit être une combinaison de travaux de maintenance et de nouveau projet. Je fais ça depuis plus de 35 ans. C'est courant et très malavisé.

Ce type de rotation est un problème d'organisation. Tous les développeurs devraient avoir une combinaison de travail de projet amusant et passionnant (les nouveautés) et de travail de maintenance (garder les lumières allumées).

Dans ma position actuelle, nous recherchons une répartition 60/40 entre le travail de projet et le travail de support. Cela peut (bien sûr) varier en fonction du projet et du montant de l'assistance.

Les entreprises qui ne récompensent pas le travail d'assistance dans la même mesure que les nouveautés ont tendance à rencontrer des problèmes. Lorsque les personnes expérimentées laissent une mine de connaissances métier et la connaissance système est perdue (le facteur bus).

Il est temps de relever le défi du cadre: ce problème n'est pas que les développeurs détestent la maintenance; le problème, c'est qu'ils détestent travailler pour votre entreprise.

Je ne pense pas que vous vous rendiez compte à quel point insensé votre taux de rotation est. Le taux de rotation informatique moyen est de 13,2% par an - et cette statistique est présentée comme une "vache sacrée, 13,2% est élevé!" J'ai travaillé pour une entreprise PoS pendant un certain temps, et elle avait un taux de rotation d'un peu plus de 20% - et je la considère personnellement comme une usine de désabonnement. Quel est donc le taux de rotation informatique de votre entreprise? Environ 80%! C'est six fois le taux de «vache sacrée, le taux de rotation informatique est élevé», et presque quatre fois le taux de «churn factory». (J'ai presque envie de copier-coller tout ce paragraphe dans un deuxième temps, juste pour souligner à quel point ce taux de rotation est dysfonctionnel.)

Donc, je veux que vous vous mettiez dans la peau d'un développeur qui a a rejoint votre entreprise - et déteste probablement leur nouvel emploi. Ils veulent déjà sortir ... mais ils ont un dilemme: quittent-ils le navire après seulement 2 mois de travail? Bien que compréhensible, ce serait quand même un peu un drapeau rouge sur leur CV qu'ils préféreraient éviter. Mais ils travaillent actuellement sur un projet. Peut-être que la bonne solution est de simplement tenir le coup quelques mois de plus jusqu'à ce que le projet soit terminé, puis de réclamer la réalisation sur leur CV? De plus, terminer le projet constitue un excellent `` serre-livre '' - une pièce de clôture qui marque mentalement leur temps dans l'entreprise. Il y a de très bonnes chances que vous obteniez des exodes massifs après la sortie du projet, ce n'est pas parce qu'ils voulaient tous quitter spontanément en même temps - c'est qu'ils voulaient quitter avant ce moment et attendaient simplement de terminer le projet. .

En examinant votre question, je pense que vous avez fait un saut que vous n’auriez pas dû faire: qu’ils partent spécifiquement pour des raisons de maintenance. Avez-vous demandé aux gens qui sont partis? Avez-vous demandé aux agents de maintenance actuels des commentaires anonymes? Avez-vous parcouru les avis sur Glassdoor?

Ne vous méprenez pas: ils pourraient en effet fuir parce qu'ils détestent l'entretien. Mais il peut y avoir d'autres raisons - des raisons pour lesquelles vous passez à côté à cause d'une hypothèse hâtive.

Je ne peux parler que pour moi-même, mais les raisons pour lesquelles je suis parfois un contre-exemple peuvent être éclairantes.

Maintenir un projet massivement chargé par une dette technique peut être difficile, mais cela peut aussi être extrêmement gratifiant. L'héritage de projets Android et ASP.NET désastreusement bâclés m'a appris plus de choses que je ne peux compter sur ce que ne pas faire dans ces frameworks. J'ai appliqué ces leçons dans mes propres projets greenfield. Je suis également devenu habile dans le refactoring, ce qui est très précieux dans ce secteur car il y a tellement de projets qui s'effondrent sous la dette technique. Et c'est émotionnellement gratifiant dans la mesure où la correction des bugs fait de vous un héros pour les utilisateurs.

Tout cela a été possible parce que la direction, ou du moins mes supérieurs immédiats, a reconnu que je faisais face à une dette technique et m'a donné une lettre de marque pour le rembourser. Se sentir comme un héros devient une incitation lorsque les développeurs connaissent ou ont une sorte d'engagement avec les utilisateurs. J'ai bâti une carrière très réussie en nettoyant les dégâts des autres, et je peux honnêtement dire que j'aime ça. Mais je peux facilement voir le chiffre d'affaires devenir un problème si ces conditions n'étaient pas remplies.

Je ne sais pas en général, mais je peux répondre par moi-même.

(sans ordre particulier)

1. Les projets sont considérés comme plus "excitants ", dans le sens où ils offrent plus de défis. Greenfield (i) projets en particulier, car la technologie est invariablement nouvelle (heu) et offre plus d'opportunités d'apprentissage. La maintenance est la même vieille, la même vieille.

2. Les projets ont généralement une fin fixe ou sont réalisés par étapes. La maintenance est considérée comme une liste interminable. Dans un mois, ce ne sera plus rien.

3. Le travail de base du projet peut souvent mieux apparaître sur le CV. "Pourquoi es-tu parti?" - "Fin de projet", sonne mieux que "Je m'ennuyais après 2 ans du même truc". Le locataire notera «s'ennuie facilement».

4. Coût / Temps. Vos «solutions personnalisées» auront des contraintes de coût ou de temps qui obligeront les développeurs à «faire juste», plutôt qu'à concevoir une solution élégante. Il en va de même pour les projets, mais comme ils sont beaucoup plus gros, c'est un problème moins évident (c'est aussi un risque de projet, mais c'est pour une réponse différente).

5. Argent - Travail d'assistance paie beaucoup moins.

6. C'est très spécifique à l'entreprise

(i) Un nouveau projet est un projet qui completement nouveau. Le terme vient de l'industrie du bâtiment; avant d'avoir un bâtiment, il n'y a qu'un champ vide. Brownfield est l'endroit où il y avait peut-être déjà eu un bâtiment et que l'ancien est réutilisé.

Clause de non-responsabilité: je suis un entrepreneur et j'ai fait beaucoup des deux types de travail. Je fais actuellement de la maintenance.

Changez la question. Au lieu de cela, demandez-vous pourquoi les auteurs préfèrent-ils écrire de nouveaux livres plutôt que d'éditer les livres d'autres personnes? Si vous regardez les choses de cette façon, la raison pour laquelle les programmeurs préfèrent les nouveaux projets devrait être évidente. Les programmeurs sont des créateurs par nature.

Mais je veux aborder ici un défi de frame mineur parce que je vois un assez gros drapeau rouge. Si vos développeurs ne restent avec vous que 4 à 9 mois, vous avez un problème important qui va au-delà du simple nouveau code par rapport à la maintenance. Êtes-vous sûr qu'il n'y a pas d'élément toxique dans l'environnement? Ou peut-être que le code est si insouciant que les responsables ne veulent pas en assumer la responsabilité? Votre gestion de projet est-elle désagréable et repousse-t-elle des délais déraisonnables? Une durée moyenne de 4 à 9 mois est inhabituellement courte, même dans cette profession.

Une chose que vous voudrez peut-être regarder est de vous débarrasser de l'idée d'avoir un «nouveau développement» et un groupe de «maintenance». Les développeurs qui créent le «nouveau» logiciel devraient être ceux qui le maintiennent. C'est ainsi que les développeurs grandissent - ils reçoivent des commentaires sur le travail qu'ils ont effectué, et ont la possibilité de l'améliorer et d'apprendre de l'expérience. Tous les développeurs doivent être impliqués à la fois dans le nouveau développement et dans la maintenance de leurs travaux précédents.

La réponse de Matthew a déjà couvert la plupart des problèmes liés aux travaux de maintenance, même si j'appellerais certaines choses un peu à courte vue par les futurs employeurs. Un bon développeur Java 7 peut facilement apprendre les nouvelles normes. Il y a cependant un aspect qui m'empêcherait de me consacrer uniquement à la maintenance: Cela peut être incroyablement frustrant et vous avez l'impression de ne rien faire

Nous ne sommes qu'une petite équipe et donc tout le monde s'occupe à la fois de la maintenance et du nouveau développement. Cependant, chaque logiciel a les parties qui "fonctionnent juste" pour l'éternité écrites par des gens qui sont partis il y a des années. Certaines de ces pièces sont antérieures à beaucoup de nos améliorations de qualité. Il n'y a pas de documentation appropriée (ou aucune que vous puissiez trouver). Il n'y a pas de couverture de test. Le code de ces parties peut être désordonné et "optimisé" de manière étrange, ce qui entraîne le dépassement de nombreuses limites invisibles lorsque vous essayez de changer quelque chose.

Chaque fois qu'une de ces parties s'arrête pour "juste fonctionner", Je me sens comme un archéologue analysant tous les détails probablement sans importance qui pourraient être pertinents. Réduire un problème peut être difficile dans ces systèmes car ils sont difficiles à isoler de leurs dépendances. En fin de compte, vous avez peut-être passé 2 jours et pour un correctif composé d'une seule ligne de code.

Et le pire, c'est que vous ne pouvez pas résoudre ce problème pour de vrai car une fois qu'un projet ou une version de produit est en maintenance mode, vous n'obtiendrez pas les ressources pour une réécriture majeure. S'il est possible de changer la situation dans son ensemble

De plus, même maintenir son propre code peut être une vraie douleur. Une fois qu'il est dans la nature, il devient beaucoup plus difficile à déboguer. Au lieu de joindre un débogueur, vous lisez les journaux et espérez avoir choisi le bon niveau d'instrumentation. De nombreux problèmes dans la nature dépendent de l'action de l'utilisateur ou, pire encore, ils dépendent des données. La reproduction de ces problèmes nécessite beaucoup de coopération avec les clients, ce qui n'est pas vraiment amusant.

Ajouter à @Matthew Gaiser

Créer un produit maintenable est difficile. Faire un produit qui nécessite peu de maintenance est encore plus difficile.

Étant donné le choix, les développeurs ne font ni l'un ni l'autre (et la plupart d'entre eux sont de toute façon incapables). Ils sont payés, promus et félicités pour l'ajout de fonctionnalités et ils continuent d'ajouter des fonctionnalités et continuent de s'améliorer dans l'ajout de fonctionnalités. Les cas d'angle, la gestion des erreurs ou mieux, les choix de conception qui demandent beaucoup de réflexion sont laissés pour compte.

Soit ils savent assez bien ce qu'ils ont fait (s'ils sont honnêtes avec eux-mêmes), soit ils font face à la vérité d'une manière plutôt désagréable lorsque le projet est déployé.

Bienvenue dans l'enfer de la maintenance.

--- edit:

La maintenance est assez similaire au développement. Vous faites fonctionner les choses. Sauf ...

1. Pression des personnes qui utilisent le produit et qui en ont besoin pour fonctionner maintenant. La façon dont ils sont formés ou habitués.

2. Responsabilité. C'est vous qui serez viré pour une perte de données royale, pas le développeur "rock star" qui ne voit jamais les données des utilisateurs.

3. Contrainte des mauvais choix de conception de ceux-ci " rock stars "qui l'a écrit (c'est encore pire si ces rock stars sont vous).

4. Des métriques de succès complexes: ... eh bien, c'est compliqué. Vous prenez beaucoup de blâme. Voir d'autres réponses.

5. Généralement des personnes moins compétentes et moins motivées qui font de la maintenance (ou doivent travailler avec ces personnes si vous restez dans la maintenance).

Les autres réponses ont parlé du plaisir de travailler sur un nouveau projet, mais il existe également de bonnes et de mauvaises façons de gérer les projets de maintenance. Le bon moyen offre de nombreuses opportunités d'améliorations initiées par les développeurs, et je pense que la plupart des développeurs trouvent cela presque aussi gratifiant. La mauvaise façon est un slog constant de passer un temps excessif sur ce qui devrait être de simples correctifs, puis d'être abattu chaque fois que vous suggérez des améliorations qui pourraient vous accélérer, comme des refactors ou l'automatisation des tests et des déploiements.

Ceci est basé sur des opinions, mais créer un désordre est plus amusant que d'en nettoyer un.

Maintenance

En général vous corrigez des choses qui n'ont pas été faites correctement au départ. Souvent, ce n'est pas votre faute. Cela pourrait être une véritable erreur, un oubli, d'autres développeurs étant paresseux ou inexpérimentés, fluage de la portée, technologie obsolète, etc.

Vous prenez le blâme pour que les choses ne fonctionnent pas, même si ce n'est pas votre faute . C'est stressant et humiliant.

(certains développeurs adorent trouver et résoudre les problèmes, d'autres le détestent)

Développer

Vous ' re le créateur. Vous obtenez tous les éloges pour que les choses se passent bien. Lorsque des problèmes sont découverts plus tard, c'est un problème de maintenance.

Solutions possibles

Peut-être que le problème que vous rencontrez concerne davantage la culture et les processus. Assurez-vous que les développeurs construisent les choses selon des normes élevées, avec des spécifications et des processus clairement définis.

Avant la fin d'un projet, organisez une réunion pour les planifier sur un autre projet, en leur donnant quelque chose à espérer , partageant leur temps entre la maintenance et un nouveau projet.

Les développeurs veulent développer (créer), ne coller personne dans un groupe purement de maintenance (bouc émissaire).

Je vais faire écho au sentiment de GrandmasterB en disant que si vos développeurs ne restent que 4 à 9 mois, le problème n'est pas le fait que ces développeurs sont mis en maintenance. Vous avez un problème plus grave, et les gens qui quittent votre entreprise et vous disent que c'est à cause de la maintenance essaient simplement de calmer le vrai problème. Bien que je ne puisse pas parler pour les autres, une des raisons pour lesquelles je pourrais faire quelque chose comme ça serait parce que j'ai l'impression que si je soulevais le vrai problème, je ne serais pas écouté. Quelque chose, peut-être, comme un manager toxique qui est dans l'entreprise depuis des années et que la direction l'aime, mais tous ses subordonnés directs se plaignent de lui, mais les RH ne font jamais rien parce qu'ils pensent qu'il est génial et qu'il produit des résultats. Connaissez-vous quelqu'un qui pourrait correspondre à cette description au sein de votre organisation? (indice: sinon, ce pourrait être vous). Vous pouvez rechercher votre entreprise sur Glassdoor et voir ce que les gens disent de votre entreprise; les gens ont tendance à être plus honnêtes lorsqu'ils sont anonymes, et vous pourriez y trouver la vraie raison. Il est important que lorsque vous parcourez les avis de Glassdoor pour comprendre que la plupart des gens n'essaient pas de vous calomnier, ils donnent leurs vrais conseils en fonction de leurs expériences réelles, et de nombreuses entreprises se mettent sur la défensive lorsqu'elles ont un problème, alors que vous devriez être introspectif et essayez de résoudre le problème.

Voici une autre question qui pourrait vous éclairer sur la manière dont votre entreprise peut être gérée au niveau macro: disons que je rejoins votre entreprise. Vous m'avez mis sur un projet pendant les 6 premiers mois, puis je termine le projet et vous m'avez mis en maintenance pour le reste de mon mandat dans l'entreprise. Ensuite, vous voulez démarrer un nouveau projet, donc vous embauchez quelqu'un d'autre. Ensuite, ils passent à la maintenance. Ensuite, vous démarrez un nouveau projet et embauchez quelqu'un d'autre, et ainsi de suite. Pendant ce temps, moi et l'autre gars sommes toujours dans l'entreprise, nous sommes des développeurs capables qui pourraient faire le projet, et vous ne nous utilisez pas pour répondre aux besoins de votre projet. Outre le fait que cela nous fait nous sentir inutiles parce que nous n'obtenons pas le travail de projet «intéressant», cela signifie également que votre base de code est un gâchis, car chaque fois que vous faites un nouveau projet, vous embauchez de nouvelles personnes qui entrent dans l'entreprise avec leurs propres normes, expériences et styles. Cela augmente le coût de maintenance de votre service dans son ensemble, car en plus des tâches de maintenance régulières telles que la qualité des données et le triage des bogues, nous (les responsables de la maintenance) devons également comprendre potentiellement des dizaines ou des centaines de styles de codage différents de toutes les personnes différentes, certains d'entre eux. qui ont peut-être quitté l'entreprise après avoir soumis leur code.

En réalité, vous ne devriez pas avoir une "équipe de projet" et une "équipe de maintenance". Vous devez diviser votre équipe par responsabilités ou domaines, puis chaque développeur de chaque équipe est responsable à la fois du nouveau développement et de la maintenance de tout ce qui relève de son domaine. Ensuite, vous avez des chefs d'équipe ou des responsables de l'ingénierie qui répartissent ces tâches entre les membres de leur équipe afin que chacun ait une part décente des nouvelles tâches de développement et de maintenance.

Un autre signal d'alarme à propos de votre entreprise est que vous ressentez le besoin d'avoir une "équipe de maintenance", c'est-à-dire un ensemble de développeurs qui sont en service de maintenance à plein temps. Cela en dit long sur la qualité de votre code d'application. Des bogues se produisent, c'est sûr, mais si vous avez tellement de bogues que vous avez une équipe dont la responsabilité principale est de passer d'un bogue à l'autre pour éteindre les incendies, cela pourrait valoir la peine d'envisager une réécriture de votre application, car ce n'est pas censé se passer. Cela vient de l'embauche de mauvais développeurs, et les mauvais développeurs sont aussi des personnes qui pourraient partir d'ici 4 à 9 mois, comme "voici mon code de merde, maintenant c'est votre problème, à bientôt" (pas que les bons développeurs n'aient pas de raisons de partir rapidement , mais les mauvais développeurs ont plus de raisons de partir rapidement). Vous devriez probablement également jeter un coup d'œil à la rémunération de vos employés et la comparer aux taux du marché pour voir si vous n'attirez peut-être pas les talents. Le talent attire plus de talent; J'adorerais travailler avec des gens qui sont plus intelligents que moi, mais si tout le monde est moins qualifié que moi, je n'ai aucune raison de rester car je n'apprends pas ou ne fais rien d'intéressant, et je dois constamment réparer les autres le mauvais code des gens parce que personne n'écrit de code aussi bon que le mien.

En bref:

1) Vous avez probablement un problème au sein de votre organisation sous la forme d'une personne toxique dans la gestion. Découvrez de qui il s'agit et débarrassez-vous d'eux.

2) Vous devriez probablement diviser vos équipes en domaines de projet plutôt que maintenance par rapport à projet, et avoir des chefs d'équipe qui répartissent les tâches de projet et de maintenance pour garder votre les développeurs sont satisfaits.

3) Vous devriez probablement augmenter vos taux de rémunération pour attirer les talents qui peuvent créer un meilleur code afin que vous ayez à faire moins de maintenance. Vous pouvez également supprimer votre application actuelle et la reconstruire complètement une fois que vous avez de bons talents à bord pour réduire les coûts de maintenance.

J'aime la réponse de Matt mais je souhaite ajouter un exemple s'il n'est pas déjà partagé. Supposons que quelqu'un a construit une maison et que cette même personne se promène maintenant pour entretenir la maison. Ce serait assez ennuyeux de le faire principalement parce que vous trouverez les éléments communs qui se cassent, et il est probable que tout le reste est principalement un malentendu sur la façon dont quelque chose fonctionne. Vous passerez plus de temps à ne rien faire qu'à faire quelque chose. Bien sûr, il y a de nouveaux projets qui peuvent apparaître ici et là et peut-être qu'à certains moments, des extensions de la maison peuvent se produire, mais dans l'ensemble, vous passez du temps à faire la maintenance et les pannes courantes.

Je pense que la plupart des développeurs veulent quelque chose de plus difficile que de faire une simple maintenance, surtout si la technologie est ancienne, sans à peine rien de nouveau à apprendre, pas de nouveau langage / framework / etc. Vous êtes donc coincé avec quelque chose qui ne mènera à rien, que vous ne pourrez pas utiliser plus tard dans votre carrière si vous changez d'emploi. Aussi je trouve ça ennuyeux, sans trop de travail, sans intérêt

Je suis développeur et je n'aime pas non plus la maintenance, en effet cela peut être comparé au travail de conciergerie. La meilleure chose à propos de mon travail est d'être créatif et de construire des choses à partir de zéro. Mais quand vous faites de la maintenance:

1. Vous perdez beaucoup de temps à comprendre le code de quelqu'un d'autre, qui est souvent compliqué
2. Vous n'utilisez pas votre créativité, mais vous modifiez simplement quelque chose qui existe déjà, et vous devez vous conformer à une structure déjà existante
3. Plus important encore: le code déjà existant peut agir comme une couche opaque entre la technologie que vous essayez d'apprendre et vous . Le code appartenant à l'entreprise est souvent sans valeur en dehors de l'entreprise, tandis que les technologies et les frameworks généraux (par exemple apprendre Django) peuvent être très utiles et appréciés en dehors de l'entreprise, et aussi très intéressants
4. Au fur et à mesure que la base de code se développe, le la complexité augmente et faire de petits changements devient très complexe, ce qui peut être démotivant

Les raisons 2 et 3 peuvent être des tueurs de motivation pour moi. La dernière chose que je veux entendre en tant que développeur junior, c'est que quelqu'un avec plus d'expérience que moi a créé quelque chose que je devrais utiliser parce que je ne suis pas assez habile pour créer quelque chose. Cette dernière raison peut être vraie ou fausse, mais ce que je veux faire, c'est apprendre. S'appuyer sur le code de quelqu'un d'autre, c'est comme si au lieu d'apprendre à conduire une voiture, quelqu'un crée une interface pour vous, ce qui à la fin (1) vous empêche d'apprendre à conduire la voiture, ce qui est intéressant et précieux, et (2) vous empêche de contrôler la voiture. Pour combien cela peut être difficile, la dernière chose que vous voulez entendre, c'est qu'on ne vous apprend pas à le faire vous-même.

J'ai peur qu'en tant que junior, je n'ai pas assez d'expérience pour vous donner une liste concrète de points d'action qui ont fait leurs preuves. Mais tout ce que je peux dire, c'est qu'un développeur (s'il est passionné) voit une entreprise comme une opportunité d'apprentissage, pas seulement comme une source d'argent. Ce que vous pouvez faire pour encourager un développeur qui travaille sur la maintenance, c'est lui permettre d'être créatif, par exemple en lui permettant de réécrire des parties de l'application en utilisant les nouvelles technologies et en y mettant sa créativité.