Je viens de commencer ma carrière en tant que développeur Web pour une entreprise de taille moyenne. Dès que j'ai commencé, j'ai eu la tâche de développer une application existante (mal codé, développé par plusieurs programmeurs au fil des ans, gère les mêmes tâches de différentes manières, sans structure).

Ainsi, après avoir étendu avec succès cette application avec les fonctionnalités demandées, ils m'ont confié la tâche de la maintenir complètement. Ce n'était bien sûr pas un problème, du moins le pensais-je. Mais ensuite, j'ai appris que je n'avais pas le droit d'améliorer le code existant et de me concentrer uniquement sur les corrections de bogues lorsqu'un bogue est signalé.

A partir de là, j'ai eu trois autres projets similaires à ceux ci-dessus, que je dois maintenant également maintenir. Et j'ai eu quatre projets où il m'a été permis de créer l'application à partir de zéro, et je dois également les maintenir.

En ce moment, je commence à être un peu fou des courriers quotidiens des utilisateurs (gestionnaires de lecture) pour chaque application que je dois gérer. Ils s'attendent à ce que je traite ces mails directement tout en travaillant sur deux autres nouveaux projets (et il y a déjà cinq autres projets alignés après ceux-ci). Le plus triste, c'est que je n'ai pas encore reçu de rapport de bogue sur tout ce que j'ai codé moi-même. Pour cela, je n'ai reçu que de rares demandes de changement de type «faisons-choses-à-180 °».

Quoi qu'il en soit, est-ce normal? À mon avis, je fais l'équivalent du travail de toute une équipe de développeurs.

Étais-je un idiot quand je m'attendais initialement à ce que les choses soient différentes?

Je suppose que ce message s’est transformé en un grand coup de gueule, mais dites-moi que ce n’est pas la même chose pour tous les développeurs.

PS Mon salaire est presque égal, voire inférieur, à celui d'un caissier dans un supermarché.

Durant l'un de mes stages, j'ai constaté que je passais beaucoup de temps à corriger des bugs. Vous devez comprendre qu'en tant qu'employé débutant, vous n'obtiendrez pas le travail le plus sexy, vous obtiendrez le travail ingrat dont personne ne veut. C'est malheureux, mais c'est comme ça à chaque travail.

De plus, vous devez comprendre que pour une entreprise, il est plus important d’avoir un code qui fonctionne que d’avoir un code propre. Du point de vue de votre entreprise, vous modifiez la structure existante, vous gaspillez de l’argent à la restauration de quelque chose qui est déjà fait et à l’introduction potentielle de plus en plus d’erreurs. Habituellement, ces types de sociétés ne sont pas des sociétés d’informatique ou de logiciels. Par conséquent, aucun gestionnaire suffisamment expérimenté n’a les connaissances techniques nécessaires pour savoir que vous devez parfois procéder à ces révisions majeures. Cela dit, si votre entreprise est dirigée par des personnes techniquement compétentes et qu'elles comprennent la valeur d'un bon code, vous aurez peut-être plus de marge de manœuvre, même si vous devez parfois choisir vos batailles (l'objectif principal d'une entreprise étant toujours de gagner de l'argent. ).

Cela dit, vous n'êtes pas déraisonnable de vouloir laisser votre marque sur le logiciel et de vouloir un travail plus significatif. Il est également regrettable que vous ayez à traiter autant de projets à la fois tout en répondant aux demandes de tant de gestionnaires différents.

En tant que programmeur, il est indéniable que vous passerez plus de temps à maintenir et à modifier le code d’autrui que vous n’écrirez le vôtre à partir de rien. Si cela vous pose un problème, vous devriez peut-être vous en tenir à votre passe-temps et poursuivre une carrière différente. Si le maintien du code vous convient, mais que vous sentez que vous n'êtes pas utilisé efficacement ou que vous êtes dépassé, vous devez en discuter avec votre responsable. Si vos problèmes sont plus graves que cela ou si vous avez l’impression que vos gestionnaires ne savent pas comment gérer efficacement vos compétences, il serait judicieux d’envisager de trouver un poste dans une autre entreprise. Compte tenu de votre faible salaire déclaré, il s'agit probablement de votre meilleur plan d'action.

On dirait que la direction a du mal à gérer votre charge de travail et à hiérarchiser vos tâches. Vous devriez parler à votre responsable et lui faire comprendre que vous êtes surchargé et que vous ne pouvez pas faire un travail efficace si tout le monde continue à vous bombarder de demandes qu’ils veulent voir exaucer immédiatement.

Cela vous fait sauter d'une tâche et d'un projet à l'autre, ce qui vous fait perdre beaucoup de temps. Pour un travail de développement logiciel efficace, il faut être capable de se plonger dans une tâche et de se concentrer pleinement sur celle-ci. Plus le nombre d'interruptions générées est important, plus la commutation de contexte perd du temps. Les recherches montrent qu'il faut environ 15 minutes pour s'immerger et atteindre l'état de flux où notre esprit travaille le plus efficacement possible. Si vous avez des interruptions toutes les 15 minutes, vous ne coulez jamais, ce qui est un énorme gaspillage pour vous et votre entreprise.

Vous devriez donc essayer de négocier un mode de travail plus judicieux avec votre responsable . Cela devrait inclure la hiérarchisation des demandes entrantes et la planification dans une certaine mesure . Toutes les demandes des utilisateurs doivent être maintenues dans une liste, classée par priorités. Et les priorités ne doivent pas être décidées par le demandeur (comme tout le monde pense naturellement que sa demande est la plus importante au monde), ni par vous, mais par une personne ayant une connaissance suffisante des affaires et une vue d'ensemble de la gamme de produits que vous conservez ( le propriétaire du produit ).

Idéalement, toutes les demandes entrantes devraient être entrées dans un outil de suivi des problèmes tel que JIRA ou Mantis . Ou du moins envoyé par la poste au propriétaire du produit, pas à vous. Et il / elle devrait également traiter de toutes les plaintes des utilisateurs "Pourquoi ma demande n'est-elle pas encore prête?!", Ce qui vous permet de vous concentrer sur le travail de développement. Si cela est inaccessible, vous devriez au moins négocier quelques fenêtres de temps lorsque vous examinez les demandes entrantes et les gérez, en réservant une partie ininterruptible de votre temps au seul développement.

Si cela est possible, la prochaine étape pourrait être de planifier dans une certaine mesure. C'est-à-dire, estimez le temps nécessaire pour mettre en œuvre les demandes prioritaires, puis programmez votre temps dans les sprints , qui peuvent durer une ou plusieurs semaines, et affectez suffisamment de tâches au prochain sprint pour couvrir votre temps.

Vous voulez probablement garder une partie de votre temps pour les demandes d'urgence entrantes, mais le reste peut être planifié à l'avance. Et vous pouvez également préférer organiser le travail sur différents projets en "séquences" distinctes, c’est-à-dire travailler sur le projet A lundi, le projet B le mercredi-mercredi, le projet C le jeudi matin et le jour D le lendemain, etc. réduire le changement de contexte.

De cette façon, vous avez une idée approximative de ce que vous devez faire au cours des prochaines semaines. De plus, cela donne également une feuille de route à vos clients: ils peuvent voir quand ils obtiennent la requête mise en œuvre. Vous pouvez vouloir ou ne pas vouloir mentionner le mot "agile" à votre responsable ici - il s’agit essentiellement d’ un développement agile , mais certaines personnes s’opposent à l’agile sans savoir ce que c’est :-)

Notez que même si votre position actuelle semble peu valorisée par votre entreprise, plus vous entretenez de projets, plus vous avez de pouvoir de négociation .

Trouver et former un nouvel employé pour entretenir tous ces projets prend beaucoup de temps (= argent) à la société. Et vous pouvez à juste titre souligner que votre code est tellement meilleur que les composants hérités de ces applications; il n’est donc pas évident qu’ils peuvent facilement trouver un candidat doté de capacités similaires pour le même montant. Sans oublier que s'ils n'améliorent pas les conditions de travail, ils feront en sorte que le prochain gars en ait marre et qu'il arrête de fumer aussi vite que vous ... Essayez de leur faire comprendre qu'il est dans leur intérêt de vous garder, et pour vous garder heureux où vous êtes :-) Cela peut vous donner le pouvoir de négocier les conditions ci-dessus et / ou de demander une augmentation de salaire.

Quel est votre pouvoir de négociation? C'est une grande question. Votre direction peut être ou ne pas être ouverte à ces idées, et peut vous ou ne pas vous respecter suffisamment pour prendre vos plaidoyers au sérieux. Mais si vous jouez bien vos cartes, vous avez une chance. Et s'ils refusent ... vous pouvez toujours chercher un meilleur lieu de travail. Cette situation n’est pas la même pour toutes les entrées, même si (malheureusement) vos expériences sont assez typiques. Mais il existe vraiment de meilleurs lieux de travail . La qualité du lieu de travail n’est que vaguement liée à la situation géographique, mais j’ai le sentiment qu’en Europe du Nord, les chances sont plus élevées que la moyenne. Donc, si vous ne pouvez pas améliorer sensiblement vos conditions actuelles, vous devriez commencer à regarder immédiatement , avant de vous en lasser complètement et de vous épuiser.

Il est extrêmement préférable de chercher un emploi tant que vous en avez toujours un. Vous n'avez donc pas besoin d'accepter la première offre simplement parce que vous avez besoin d'argent immédiatement. Finalement, vous trouverez un meilleur endroit :-)

PS Mon salaire est presque égal, sinon inférieur à celui d'un caissier dans un supermarché.

Heh je voulais écrire quelque chose sur la façon de négocier jusqu'à ce que je lis cela. Maintenant, tout ce que je peux dire, c'est partir! En supposant que ce soit la moitié de ce que gagne un développeur avec un diplôme. Et en supposant que les choses s’améliorent et qu’elles vous donnent immédiatement une augmentation de 10%, vous pouvez déterminer vous-même combien de temps il faut pour y parvenir. On dirait également que vous n’apprenez rien au travail et que vous ne semblez pas être entouré d’ingénieurs brillants, c’est donc une perte de temps.

J'étais également dans une situation similaire et je peux vous dire que si vous restez sur cette piste, elle ne finira jamais. La direction continuera à vous en parler, parce que ... ils le peuvent.

Il y a quelques réflexions supplémentaires que j'ai sur ce sujet.

1. Fais ce que tu aimes. Si vous ne l'aimez pas, préparez-vous à tenter de trouver ce que vous pourriez aimer.

2. La communication. Communiquez clairement vos incapacités à répondre à des attentes irréalistes. Dans mon expérience similaire, l'architecte (qui a fait le plus de pelletage) a déclaré: "vous devez gérer les attentes des autres par rapport à vous."

3. Burnout. Si vous n'avez pas connu l'épuisement professionnel, ne tentez pas le destin. Cela aspire votre vie et votre âme de votre esprit. Malgré tous vos efforts, votre objectif de travail devient gris, monotone et dépourvu de sens. Je donne ce conseil car il faut à tout prix éviter l'épuisement professionnel.

4. Entraînement. Voici la doublure en argent. Votre formation et votre expérience, même si elles sont frustrantes et peut-être sous-payées, sont très utiles à votre carrière. C’est votre salut qui vous permet de réaliser cela, car vous pouvez vous imprégner autant d’apprentissage que possible et retarder tout plafond de verre inévitable.

Concentrez-vous sur les talents et les compétences que vous développez ... Ceux-ci vous permettront de faire face aux prochaines opportunités de votre carrière.

Vous avez affaire à plusieurs problèmes ici ... Commençons par l'évidence ...

Est-ce normal?

Sûrement pas. Mais ... est-ce commun? Malheureusement oui.

Concernant la frustration liée à la correction des bogues

Bien que cela n'excuse pas le reste du gâchis que vous avez à gérer et les multiples projets qu’ils vous surchargent, je tiens simplement à dire rapidement que la solution du bogue n’est que la solution, tout en vous frustrant pour le développeur. , peut être une approche parfaitement judicieuse pour la société et son management.

Surface pour plus de bugs et de coûts

Plus vous touchez de code, plus vous êtes susceptible d’introduire des bogues, même si vous souhaitez l’améliorer. Cela signifie une durée de développement, une durée d’essai et des coûts plus longs. Et si cela se traduit par une version de service avec un défaut moyen à élevé, c'est un gros désastre pour eux.

Bruit / Brouillard dans vos journaux

Du point de vue de la gestion de la chaîne logistique, il est également judicieux de travailler directement depuis une branche de service, car vous souhaitez avoir une vue claire des modifications liées aux corrections de bugs. S'il y a 15 commits avec des milliers de modifications autour d'une correction qui nécessitait peut-être un changement de code sur une ligne, c'est un peu gênant.

Donc, étant une nouvelle recrue, il est encore plus judicieux de vous demander de ne pas refactoriser et / ou d’améliorer le logiciel, et cela me convient tout à fait d’être aussi "chirurgical" que possible avec vos corrections de bugs. Il garde juste les maux de tête aux abois.

Peux-tu faire quelque chose pour cela?

Maintenant, cela ne signifie PAS qu'il y aurait des moyens de parvenir à la fois à la santé mentale du code et à la santé mentale de l'esprit des personnes impliquées. En tant que junior, ils devraient demander à quelqu'un de réviser vos modifications, en particulier les correctifs, et de s’assurer de leur approbation avant de passer aux versions de service. Cela empêcherait ou limiterait les changements radicaux et serait plus sûr.

Le projet de l'enfer

Code de merde, troupeau de programmeurs, duplication, architecture de merde

Encore une fois, l'avocat du diable est ici, mais montre simplement que votre demande initiale contient quelques bits non consécutifs.

Mon point est ceci: J'ai vraiment vraiment rarement pris sur une base de code qui n'a pas été dans cet état. Et, par hasard, il s’agissait de projets ou de prototypes récemment lancés et lancés par de jolis programmeurs. Mais la très grande majorité d'entre eux ressemblaient à de la merde, et un nombre effrayant d'entre eux étaient de la merde réelle. Même ceux lancés par de bons ou de grands programmeurs peuvent finir par être de la merde, des échéances et d'autres engagements aidant ...

Bienvenue dans l'ingénierie logicielle industrielle réelle!

Et vous savez ce qui est amusant? C'est souvent pire dans le monde du développement web. Prendre plaisir! :)

Trop de projets et de demandes, pas assez de temps et de mains

Le problème réside probablement ici:

• votre direction (peut-être inconsciemment) vous maltraite ,
• vos collègues vous abusent (peut-être inconsciemment) ,
• votre (peut-être inconsciemment) ne pas couvrir votre cul et combattre suffisamment vos batailles .

Vos responsables doivent être conscients que vous travaillez sur trop de projets à gérer. S'ils ne le sont pas, assurez-vous qu'ils le sont dès que possible. Assurez-vous également qu'ils savent que tout n'a pas été fait dans le parc, que vous vous êtes senti sous pression et que cela doit cesser.

Essayez de regarder autour de vous et assurez-vous que vos collègues ne vous évitent plus de tâches et de projets, directement (en disant vraiment "X sera capable de s'en occuper") ou indirectement ("Je ne suis pas la bonne personne pour ça." ceci, trouver quelqu'un d'autre "-> finit par être vous).

Anecdote personnelle ici: j’ai fait un stage il ya quelques années. Le dernier jour de mon évaluation, mon supérieur hiérarchique m’a dit, bien que très satisfait de mon travail dans son ensemble, qu’un des responsables avait avait déchargé certaines "tâches pas si amusantes" sur un autre stagiaire quand ils se seraient attendus à ce que je les récupère. J'étais mortifié de les avoir laissé sentir déprimés et à l'idée de me donner l'impression que je me relâchais, alors que mon intention était tout à fait opposée: j'essayais de saisir les tâches les plus difficiles et de faire traiter l'autre stagiaire plus jeune avec moins de cheveux -pulling questions. Je ne savais pas que si j'avais été à sa place, le manque de défi m'ennuierait et je le ressentais probablement. Le fait est que vous devez communiquer pour vous assurer que personne ne fait de fausses hypothèses sur trois choses bien distinctes:

• ce que vous pouvez faire ,
• ce que vous voulez faire ,
• et ce que vous êtes prêt à faire .

C'est donc en partie votre faute si vous l'avez laissé devenir ainsi. Mais c'est normal, c'est une leçon que tout le monde doit apprendre. Il tient en deux lettres: N - O .

Vous l'utilisez généralement comme préfixe pour une réponse plus longue, mais pas tellement plus chargée: Non, je ne peux pas faire cela. Non, je ne sais pas comment faire ça. Non, je ne suis pas sûr d'être la bonne personne pour cela. Non, je n'ai jamais fait ça.

Au début, il est très facile de sentir que vous pouvez simplement dire «oui, je le ferai (éventuellement)», puis empiler des choses et les faire aboutir, peut-être en y ajoutant des heures supplémentaires. C'est tout faux. Vous devez comprendre que votre temps est, après vos compétences, votre atout le plus précieux, pour vous et pour votre entreprise. S'il est mal utilisé, cela aura un impact sur les projets, les délais et les budgets . Aussi simple que cela.

En outre, il semble un peu inquiétant que vous ayez trop de personnes à qui faire rapport. Vous pouvez traiter avec plusieurs clients et plusieurs propriétaires de projets ou même avec les principaux intervenants avec lesquels vous devez communiquer. Mais dans l’ensemble, surtout si vous êtes un nouvel employé, vous ne devriez vous adresser qu’à quelques gestionnaires (et probablement uniquement à votre directeur direct, et éventuellement à un développeur principal ou principal). Comment est-ce arrivé? Je ne sais pas. Cela peut être un problème d’organisation de votre entreprise, ou bien le résultat de votre faveur, de votre contact direct et de l’omission de dire «non». Ou bien il se peut que votre responsable direct ait des problèmes de répartition des tâches, pour autant que je sache (je devine vraiment, mais les schémas sont reconnaissables et bien connus).

Je vous recommanderais de procéder assez rapidement: parlez à votre supérieur hiérarchique en personne, expliquez que les autres top-managers pourraient être un peu pressés ou (probablement moins pleurnichard) que vous avez trop de choses accumulées par trop de personnes, et que vous avez besoin de son apport (et peut-être aussi du leur) pour savoir à qui donner la priorité.

Demandes de changement de 180 degrés

Ce sont un autre gros problème. Ils ne sont probablement pas de votre faute, mais vous pouvez essayer de les aider à y remédier.

Les "demandes de changement à 180 degrés", comme vous les appelez avec brio et précision, sont un signe clair que les exigences sont floues dès le départ et que personne ne fait assez d'efforts pour les avoir ciselées et éclaircies au fil du temps.

C’est généralement le moment où une personne doit téléphoner (ou mieux, prendre pied) et saisir les parties prenantes par la main et leur dire clairement: «C’est là où nous en sommes, c’est là que vous voulez que nous allions, confirmez-vous se diriger dans la bonne direction? ". C'est bien de ne pas obtenir de réponses claires au début, mais plus le temps passe, plus elles devraient devenir claires, ou ce projet est un désastre imminent.

Habituellement, je dirais: saisissez toutes les parties prenantes à portée de main, mettez-les dans une pièce, abordez-les à travers des questions litigieuses et essayez progressivement de les résoudre - et établissez des priorités tant que vous y êtes. Cependant, dans votre cas, il se peut que ce ne soit pas déjà votre appel. Mais vous mentionnez qu'ils vous ont vraiment confié la responsabilité des projets; donc si c'est vraiment le cas, alors prenez vos responsabilités et faites-le. Et Ne pas hésiter de dire « nous ne pouvons pas le faire » , ou même « nous ne le ferons pas » . Il est vraiment important de limiter la portée d'un projet.

S'il n'y a pas de portée, il n'y a pas d'exigences claires à la fin de la discussion.

Surcharge de courrier électronique

Les gens ont tendance à se comporter différemment selon le moyen de communication utilisé. Personnellement, bien que je sois une personne plutôt douce (et que je travaille principalement dans des pays étrangers, je finis également par ne pas trop parler au téléphone), je préférerais par ordre de préférence basé sur la productivité:

• parler aux gens face à face ,
• parler aux gens au téléphone,
• parler aux gens via la messagerie instantanée,
• parler aux gens par e-mail.

Les courriels sont intéressants pour le suivi, pour obtenir des confirmations, pour envoyer des notes.

Pour la planification, la planification et la discussion de points problématiques, ils sont quasiment inutiles. Allez frapper à la porte du gars jusqu'à ce qu'il l'ouvre et assoyez-vous avec un bloc-notes et une copie de votre documentation pour clarifier les choses. Une fois que vous avez terminé, envoyez un courrier électronique et demandez une confirmation. Si la réponse est négative ou si vous essayez légèrement de dissimuler quelque chose dans l'enveloppe, allez à nouveau assiéger le bureau de votre interlocuteur.

C'est du génie logiciel. Il est souvent plus productif de ne pas taper à l’écran sur un clavier et de réduire au minimum les coûts que vous devez affronter.

Faire le travail d'une équipe

Faites-vous l'équivalent du travail d'une équipe? Peut être.

Faites-vous l'équivalent du travail de votre équipe? Probablement pas.

Ce que je veux dire, c'est que votre équipe est probablement occupée à travailler et que vous êtes surchargée de travail. Et c’est le problème: vous êtes surchargé de choses qui devraient être écartées du calendrier actuel du projet ou données à quelqu'un qui a du temps.

Étais-je un idiot quand je m'attendais initialement à ce que les choses soient différentes?

Non; juste nouveau à la fête. C'est comme une première gueule de bois ou une relation. Vous allez vous en remettre.

Je suppose que ce message s’est transformé en un grand coup de gueule, mais dites-moi que ce n’est pas la même chose pour tous les développeurs.

C’est la même chose pour tous les développeurs d’organisations chaotiques, qu’il s’agisse de startups ou de géants bien établis, et n’ayant ni expérience ni confiance pour faire bouger les choses, pour que vos chances de survie se situent du bon côté de l’échelle.

PS Mon salaire est presque égal, sinon inférieur à celui d'un caissier dans un supermarché.

J'ai eu des salaires décents pour des emplois qui sembleraient nuls. Ce n'est pas le nombre sur le chèque qui compte, c'est le contexte. Ce que vous faites, votre âge, votre lieu de résidence et de travail, etc.

Cela dit, si vous êtes très sous-payé, travaillez trop et n'êtes pas tout à fait junior, allez demander cette augmentation ou trouvez-vous un nouvel emploi!

C'est simple:

• s’ils attachent de la valeur à ce que vous faites, ils accepteront volontiers une augmentation de salaire,
• Si ce n'est pas le cas, l'avenir de cette société ne semble pas très rose (pour vous, du moins, c'est ce qui compte), alors ne vous inquiétez pas de partir.

Sachez que demander une augmentation est une bonne chose, même si vous ne le croyez pas au début. Cela prouve que vous gardez une trace de ce que vous faites et suggère de garder un œil sur une autre option tout en restant prêt à rester à bord. Et c'est une bonne chose de s'habituer à les demander, car ils ressemblent à des entretiens d'embauche ou à des négociations en général: c'est quelque chose qui nécessite de la pratique, et ils ne tombent pas du ciel si vous ne les atteignez pas vous-même. Certaines entreprises distribuent régulièrement des relances sans que cela leur soit demandé, mais c'est uniquement parce qu'elles sont assez intelligentes pour savoir que cela vous rend moins heureux et moins enclin à changer, et qu'elles souhaitent couper l'herbe sous le pied (la plupart des peu inquiet de faire une offre de relance directement).

Comment procéder avec cette demande est un peu en dehors de la portée de CE projet ici, donc je ne vais pas entrer dans les détails. Mais je vous recommande de préparer un enregistrement de vos identifiants de validation SCM, de vos bogues corrigés et de vos succès, et de préparer des rapports les comparant aux efforts globaux de l'équipe. Par ici:

• vous pouvez mesurer vous - même si vous avez effectivement fait beaucoup plus que vos pairs ou non,
• vous pouvez défendre votre position s’ils disent que votre demande n’est pas justifiée.

En plus des commentaires d'autres personnes:

1. Oui, il est normal qu'un employé débutant se voit attribuer un travail que personne d'autre ne veut faire.

2. Vous devriez voir cela comme une pierre angulaire de votre future carrière.

Alors, que devrais-tu faire? Afin de vous prouver en tant que développeur professionnel, vous devez vous assurer que votre travail est structuré et planifié, sinon vous aurez peut-être du mal à exploiter les bonnes choses que vous faites actuellement. Vous devez donc essayer de faire les choses suivantes: vous n'êtes pas déjà).

1. Enregistrez votre travail avec précision, pour chaque projet. Donc, si vous passez une heure à réparer un bogue sur le projet A, connectez-vous cette fois. Cela sera utile pour montrer à votre responsable si vous souhaitez discuter des charges de travail.

2. Ecrire des tests unitaires. Vous avez mentionné que certains des projets que vous maintenez sont remplis de bogues, je suppose donc qu’il existe peu de tests unitaires (voire aucun). Pour chaque rapport de bogue, écrivez un test unitaire qui réplique le bogue, puis corrigez-le. Cela contribuera à éviter toute régression, à améliorer la qualité du code et à servir de plate-forme pour refactoriser le code si vous en avez l'occasion (par exemple, cela pourrait vous aider à convaincre les parties prenantes que la réécriture de certaines parties pourrait être améliorée. qualité sans introduire de nouveaux bogues, grâce à la suite de tests unitaires).

3. Cherchez un nouvel emploi - vous travaillez sur plusieurs projets à la fois, vous avez écrit du code à partir de rien et vous avez probablement expérimenté le cycle de vie d'un projet - toutes ces expériences sont bonnes pour postuler ailleurs.

Votre situation est un peu agitée, mais toujours normale. Mais la façon dont vous le gérez est très mauvaise. Voici ce que tu dois faire:

• Essayez de confronter votre patron. Vous devriez avoir des preuves (chiffres) du temps que coûte réellement la base de code défectueux. S'il ne comprend pas des choses comme une dette technique, arrêtez de le mentionner. Cela vous briserait la tête et vous pourriez être considéré comme un type de «mauvaise attitude». Ce n'est pas votre travail d'enseigner à votre patron à faire son travail.

• Maintenez votre propre backlog (Kanban). Lorsque de nouvelles tâches arrivent, mettez-le à la fin et indiquez le temps d'achèvement estimé.

• Augmentez votre temps de réponse, vérifiez votre email seulement deux fois par jour. Généralement avant le déjeuner et juste avant votre départ. (La vérification des courriels ne doit pas être suivie de codage, cela pourrait vous briser la tête)

• Améliorez légèrement le code dans le cadre de chaque tâche. Votre travail consiste simplement à améliorer le code, les compétences et les outils que vous utilisez. Cela stimulera également votre moral à long terme.

• Pas de changement de projet pendant la journée. Aujourd'hui, vous travaillez simplement sur le projet X et vous commencerez une autre tâche pour Y demain.

• Allouer une heure par jour pour garder les portes. Cela signifie de petites tâches qu'il est facile de faire. Si cette tâche prend plus de 10 minutes (peu importe la raison), elle est archivée et vous en informez le responsable.

Maintenant vient la partie difficile. Actuellement, les gestionnaires ne communiquent pas les uns avec les autres et supposent que leur projet sera terminé avec une priorité maximale. Cela entraîne beaucoup de stress sur votre tête, car vous êtes au milieu d'arguments. Vous devez obliger les gestionnaires à commencer à coordonner votre travail. À la fin, vous devriez avoir un carnet de commandes simple et agréable et les gestionnaires doivent se brimer mutuellement sans vous.

Faisons donc quelques jeux de rôle simples. Il existe trois gestionnaires et projets (Xavier avec le projet X, Yvonne avec le projet Y et Zed avec le projet Z). Vous avez un arriéré de travail pendant deux semaines, cinq jours pour X et cinq jours pour Y.

• Z vous demande de faire une tâche (1 jour)
• Vous répondez que cela se fera dans 11 jours.
• Z répond qu'il s'agit d'une tâche simple et ne devrait pas prendre plus d'une journée (notez que Z applique une petite pression).
• Vous répondez que vous travaillez actuellement pour X et ce dernier pour Z. Vous pourrez ensuite faire son travail.
• Z répond que vous devriez quand même faire son travail (pression accrue, violation directe des territoires X et Y).
• Vous répondez que faire sa tâche retarderait le travail de X et Y. Il devrait leur demander d’abord. Vous avez également CC X et Y.

Maintenant, il y a deux extrémités:

• Les gestionnaires vont commencer à se faire aboyer, de nombreux courriels, probablement des réunions ... Vous devriez rester à l'écart et laisser le gagnant vous attribuer une tâche.

• Rien ne se passera, Z vous demandera deux jours plus tard où est sa tâche. Vous répondez que vous travaillez actuellement pour X et qu'il n'a rien dit du projet Z. Encore une fois, CC X.

Maintenant, ce type de comportement peut vous faire virer. Mais votre situation est intenable et vous allez probablement quitter bientôt de toute façon. Cette solution ne fonctionne que si les gestionnaires se font concurrence (très souvent). Vous devriez également garder des traces de votre travail (arriéré), au cas où quelqu'un se plaindrait, que vous vous relâchiez.

Il y a sept ans, je travaillais à peu près à 100% à la maintenance et j'ai écrit un article à ce sujet: The Art of Maintenance Programming . Une partie que vous pouvez trouver utile:

1. Apprécie

Comment quelqu'un peut-il aimer la programmation de maintenance? Les développeurs rêvent d’être les architectes en chef de leurs équipes et quand ils finissent par maintenir les logiciels existants, cela ressemble presque à une punition. Ce n'est pas obligé: la programmation de maintenance présente ses propres défis et requiert beaucoup de créativité, d'adaptabilité, de patience, de discipline et une bonne communication. Cela peut aussi être bénéfique pour votre carrière: avoir des entrées percutantes comme «Application d'entreprise architecturée à plusieurs niveaux 24 heures sur 24, 7 jours sur 7» dans votre CV a l'air sympa, mais les employeurs apprécient les gens qui résolvent les problèmes; et la programmation de maintenance peut être une bonne occasion de démontrer vos compétences en résolution de problèmes.

Votre problème ressemble à quelque chose que vous entendez plus souvent. Cela semble être un travail qui pourrait facilement tenir sur The Daily WTF .

De nombreuses organisations se concentrent davantage sur les ventes ou la promotion des fonctionnalités que sur la qualité. Ce que ces entreprises ne voient pas, c’est qu’il n’ya pas que des qualités externes à un logiciel. Ward Cunningham a inventé le terme dette technique .

Vous voudrez peut-être aussi lire Steve McConnell sur la dette technique . Il a des points intéressants. Ken Swaber parle de développement logiciel agile dans Google Tech Talk . Une bonne partie concerne une histoire semblable à la vôtre. Il parle d'un projet logiciel devenu "braindead" après 10 ans de programmation par divers programmeurs sans jamais refactoriser . Je pense que si vous voyez cette vidéo, vous verrez beaucoup de similitudes avec ce que vous décrivez.

Tout système logiciel se dégradera en qualité lorsqu’il sera développé. En fait, pour survivre, il devra le faire. Les lois de Lehman expliquent assez bien ce principe. En fin de compte, cela se résumera à la question suivante: "Comment convaincre votre patron de procéder à une refactorisation?" .

Comment j'ai abordé un problème similaire:

• J'ai confronté mon patron et expliqué que la qualité du code se détériorait lorsque nous continuions à nous développer ( Lehman Laws ).
• J'ai essayé d'expliquer à mon patron le concept de dette technique . Et que la façon dont il vous laisse travailler est une façon qui lui coûtera de l’argent à long terme.
• Afin de lui montrer à quel point le problème était grave, j’ai (à mon époque) procédé à une analyse de code statique. Les patrons ne comprennent pas les logiciels, mais ils comprennent les chiffres. Bien que les métriques de code aient leurs défauts, il est bon d'avoir quelque chose de mesurable dont vous pouvez parler. Essayez de savoir ce que sont les lectures normales pour ces métriques, et vous serez surpris lorsque vous comparez cela à votre propre base de code.
• Si rien ne change rien et que rien ne change, la seule chose à faire est d'expliquer qu'une nouvelle fonctionnalité nécessitera de remanier d'autres parties de votre base de code. Expliquez-leur que si vous avez du code en double et qu'ils veulent changer quelque chose, les coûts d'une modification sont également dupliqués.
• Une réponse commune au point précédent sera que personne n’a demandé et donc n’a pas payé pour cette reprise. Que "peut-être" ce remaniement est superflu. Vous devrez expliquer que le logiciel devra toujours changer. Comme le disent les lois de Lehman ; il devra changer pour rester en usage. Si ce n'est pas le cas, les autres programmes qui ont effectivement changé survivront toujours. Ce sont ceux qui attendent le changement et peuvent s’adapter au changement qui survivront. C’est ce qu’est le développement logiciel agile . ( Wikipedia )

Mon patron utilise aujourd'hui le concept de dette technique pour expliquer à nos clients que nous avons parfois besoin de retravailler certaines parties du logiciel que nous construisons. Juste pour le prouver - si vous avez un patron raisonnable, il est possible de changer les choses pour le mieux.

La situation à laquelle vous faites face est presque (sinon totalement) la même pour de nombreux étudiants de première année.

Cela se passe dans les premières phases d'une carrière. Voici le piège: nous devons surmonter ce problème et prouver notre valeur à la société (moyenne ou multinationale ). Nous devrions pouvoir prendre des décisions sur ce que les circonstances nous demandent de faire. Il n’ya donc rien de mal à faire des efforts, à condition d’être remarqué et d’être un individu à part entière. Si vous valez la peine, l'entreprise le remarquera! Adios et bonne chance.

À mon avis, une entreprise qui interdit la refactorisation ne vaut pas la peine de travailler pour elle. Refactoring est une compétence de développement de logiciels essentiels, et les outils de contrôle de version , il est très facile de développer des changements dans l' isolement sans altérer le « tronc » (dans le cas d' un refactoring effectivement fait casser quelque chose). Comme le dit Bob (paraphrasé): "Vous ne devriez pas demander à être un professionnel et à bien faire votre travail."

La programmation de maintenance ne doit jamais signifier perpétuer un mauvais code.

J'ai reçu ce courriel il y a cinq ans d'un de mes amis.

Email body:    

Un ingénieur stagiaire récemment recruté demande à son patron "quel est le sens de l'évaluation?"

Boss: "Savez-vous le sens de la démission?"

Stagiaire: "Oui je le fais"

Patron: "Alors laissez-moi vous faire comprendre ce qu'est une évaluation en la comparant avec la démission"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Stagiaire: "Oui assez patron, maintenant j'ai compris mon avenir. Pour une évaluation, je vais devoir démissionner ... !!!"

Si j'étais vous, je passerais quelques heures tardives après le travail à reconstruire l'application gratuitement. Ce serait probablement une tâche amusante. Lorsque vous avez fini, montrez-le à votre patron. Si cela fonctionne et que vous faites de la maintenance dessus, il ne devrait avoir aucune inquiétude. Cela facilitera grandement votre travail et ouvrirait les yeux aux plus hauts potentiels de votre potentiel dans l'entreprise.

Je suis un étudiant à temps plein et je travaille à un stage à temps partiel pour 10 USD l'heure. Je fais des choses QA ennuyeuses, répétitives et faciles. Je me considère extrêmement chanceux, car je sais qu'un jour cela ouvrira la porte à des lieux plus grands et meilleurs.

Oui, vous devrez toujours gérer des applications, écrites par vous et d'autres personnes. La seule exception est si vous écrivez un programme qui n'a jamais, jamais besoin de maintenance. Donc, vous feriez mieux de bien vous débrouiller en maintenance.

Je pense qu'il y a dans la question un soupçon subtil d'une faille dans votre approche. C'est-à-dire que la correction des bogues n'implique pas l'amélioration du code.

Mais ensuite, j'ai appris que je n'avais pas le droit d'améliorer le code existant et de me concentrer uniquement sur les corrections de bogues lorsqu'un bogue est signalé.

Je ne peux pas croire que quelqu'un vous a dit "vous devez corriger les bugs sans améliorer le code". C'est à la fois difficile et impossible. Ce que vous ne pouvez pas faire, c'est réécrire l'application simplement parce que vous n'aimez pas, ou avez du mal à comprendre, l'approche utilisée dans la base de code existante.

Mon conseil est d'apprendre à refactorer. Chaque fois que vous corrigez un bogue, vous avez la possibilité d'améliorer au moins une partie du code. Le nombre de modifications de la base de code dépend de la nature du bogue et de la qualité du code. Mais si vous corrigez des bogues et que vous laissez sciemment du code qui sent partout, vous ne faites pas votre travail et vous accumulez une dette technique .

Certains bogues sont en fait corrigés simplement par refactoring, et il est parfois utile de refactoriser afin de vous aider à comprendre le code . En effet, la refactorisation doit améliorer la maintenabilité et la cohérence du code.

Lorsque j'estime une correction de bogue, je décide généralement si un refactor majeur est la meilleure façon de le faire et je tiens compte de cela. La même chose avec les tests unitaires. Ces deux choses devraient faire partie de la façon dont vous écrivez le code, et non pas une option, qui demande du temps supplémentaire.

Donc, vous ne devriez pas demander "puis-je améliorer le code lorsque je corrige le bogue?" Parce que tu devrais l'être quand même. Vous ne devriez pas demander "puis-je utiliser le refactoring pour corriger le bogue?" Parce que si le code à l'origine de la correction de l'application a un besoin urgent de refactoring, vous devriez le faire quand même. Vous ne devriez pas demander "puis-je écrire des tests unitaires lorsque je corrige ce bogue?" Parce que vous devriez écrire un test de régression avant même d'essayer de corriger le bogue.

NB: Je pense que cette réponse devrait être attribuée à Jeff Atwood, qui a lié 3 de ses articles.

Celui-ci est tout au sujet de l'argent. À mon avis, en tant que partant, vous êtes probablement trop gentil pour les clients qui ont déjà eu plus que ce qu'ils ont payé.

Apprenez à proposer un prix pour les nouvelles demandes. C'est loin d'être facile et les clients vont souvent vous essayer. Si vous le pouvez, demandez l'aide d'un chef de projet / produit expérimenté.

Une fois que vous avez réfléchi en termes d'argent, la communication avec la direction devient beaucoup plus facile. Si vos clients actuels fournissent de l’argent à temps plein, vous ne devez pas vous lancer dans de nouveaux projets. Mais vous comprendrez que la direction essaiera toujours de vous forcer à les faire.

Si vous êtes vraiment précieux pour l'entreprise, vous obtiendrez un pouvoir de négociation. Vous pouvez leur demander d'embaucher plus de personnes, d'obtenir moins de nouveaux projets, de vous aider à réduire la charge de maintenance ou d'augmenter votre salaire.

Votre employeur ne devrait pas décider de vous microgérer dans la mesure où il vous est interdit d’améliorer le code existant. Utilisez votre propre jugement professionnel. Lorsque vous estimez le travail, je prendrais en compte un délai supplémentaire pour permettre une refactorisation, si cela devait augmenter la productivité à l'avenir.

Quoi qu'il en soit, il semble que vous ne communiquiez pas efficacement avec votre employeur.

1. Vous avez des preuves que le refactoring permettra d'économiser de l'argent. Élaborez une proposition de projet de refactoring et montrez combien de temps et d’argent l’économie pourrait économiser. Décrivez précisément quels changements vous apporteriez au code et combien de temps cela prendrait.

2. Tenez un journal précis pour enregistrer le temps que vous passez sur le codage, les réunions et la réponse aux courriels. Cela vous protégera si vous êtes en retard.

3. Ralentir. Cela peut sembler un peu contre-intuitif, mais votre temps ne sera exploité que si vous faites tout rapidement. Les gens respecteront davantage votre temps si vous en faites moins. Par exemple, je ne vérifierais les courriels qu'une ou deux fois par jour. Sinon, vous risquez l'épuisement professionnel.

4. Compte tenu de votre taux de rémunération, il ne vaut pas la peine de se faire mal à la tête. Assurez-vous de partir à l'heure tous les jours. Ne mettez pas des heures supplémentaires sans compensation supplémentaire. L'exception est s'il y a de bonnes options d'avancement, ou si la réputation de la société va grandement stimuler votre CV, alors vous devrez simplement le sucer.

Sans en savoir plus, je vous suggère simplement d'essayer d'être plus ouvert avec vos gestionnaires. Peut-être commencer à augmenter vos estimations de tâches. Rappelez-leur constamment à quel point votre charge de travail est occupée. De plus, vous devriez rencontrer votre supérieur hiérarchique et lui expliquer que vous souhaitez une augmentation de salaire dans les six prochains mois, et vous demander de quelle manière vous pourriez améliorer vos performances pour atteindre cette augmentation de salaire.

Bonne chance.

D'après mon expérience, le monde universitaire ou les 6 à 12 premiers mois d'une start-up axée sur la technologie sont les deux seuls domaines fiables dans lesquels vous ne rencontrerez aucun problème. Ils supportent tous les deux leurs propres coûts, mais si vous aimez coder et êtes souvent horrifié par la qualité du code que vous découvrez à l'état sauvage, vous devriez commencer à orienter votre carrière dans l'une de ces directions.

Essayez de parler avec vos employeurs et voyez si vous pouvez résoudre ce problème. On dirait que vous êtes dépassé, et cela n’a rien à voir avec un mauvais programmeur.

Les petites entreprises du Web ont souvent beaucoup de projets en même temps, ce qui vous laisse à bien des égards. Essayez de tirer le meilleur parti de votre situation ou tentez de trouver un nouvel emploi si vous pensez pouvoir le faire. Je promets qu'il y a de meilleurs emplois de codage, alors ne laissez pas ce premier vous effrayer.

Bonne chance et j'espère que vous et vos collègues comprenez la gravité ou vos efforts!

Expérience personnelle

Comme beaucoup ici, je reconnais aussi votre situation. En gros, j'ai eu mon premier travail de codage avec un salaire bas et je devais maintenir beaucoup de code construit avec une structure médiocre. Au début, j’ai trouvé amusant d’apprendre de nouvelles choses, mais quand j’ai finalement eu beaucoup de projets à maintenir, de nouveaux projets à créer et un tableau blanc qui grandissait de jour en jour avec des points que je n’avais pas terminés, j’ai réalisé que ça ne marchait pas.

Après l'avoir enduré pendant deux ans, j'ai arrêté et trouvé un autre emploi de codeur quelques mois plus tard, ce qui me convient parfaitement.

Quoi qu'il en soit, plusieurs fois, ce ne sont pas seulement vos projets qui posent problème. Je me trouve plus à l'aise sur un lieu de travail quand je suis reconnu et respecté pour mon travail. Le problème avec la situation dans laquelle vous vous trouvez est que vos employeurs pourraient ne remarquer que les bogues générés par les projets créés, et non le temps que vous prenez pour supprimer tous les autres bogues.

Un salaire

Si vous voulez plus d'argent, vous pouvez souvent l'obtenir. J'ai réussi à négocier mon salaire en moins de deux ans pour une augmentation de 33%.

En gros, réfléchissez à la valeur de votre travail et aux besoins de l’entreprise. S'ils n'ont pas les moyens de vous donner le salaire que vous avez gagné, l'entreprise doit alors examiner leurs dépenses ou se rendre compte que leur entreprise ne fonctionne pas.

Et comme beaucoup l'ont mentionné ici, et je suis d'accord, vous êtes une pièce très précieuse du casse-tête de l'entreprise. Enfer, vous êtes probablement le seul qui peut résoudre ce puzzle. :)

Etant donné que je ne peux pas encore commenter car je suis un lurker sur ce site Stack Exchange, je vais simplement ajouter des informations à ce sujet.

1. Étant donné que vous venez de commencer, votre salaire ne sera pas exceptionnel, sauf si vous êtes allé travailler pour une grande entreprise telle que Microsoft, Amazon ou quelque chose qui se ressemble. Mais ce ne devrait pas être celui d'un employé d'épicerie! Ne le supportez pas trop longtemps, gagnez de l'expérience dans ce que vous faites et passez à autre chose quand une meilleure opportunité se présente.

2. Pour un concert de niveau d'entrée, c'est plutôt normal. Votre charge de travail est trop importante, mais le type de travail est attendu. Pour devenir un meilleur développeur, vous devez apprendre des erreurs des autres. Plus vous en voyez, mieux vous devenez. Mais cela implique que vous cherchiez des choses pour apprendre, pas des mauvaises habitudes ...

3. Le rapport entre la maintenance et le travail de projet devrait évoluer dans le temps. Si ce n'est pas le cas, cela signifie que la société pour laquelle vous travaillez ne comprend pas comment garder un bon développeur; ils ont l'intention de vous faire faire la même chose jour après jour. Fixez-vous un objectif annuel en ce qui concerne vos objectifs, vos attentes en matière de salaire et d’emploi, et déplacez-vous en conséquence.

4) Si vous n'êtes pas content, partez! La vie est trop courte pour traiter avec des gens stupides.

Bonne chance.

Vous commencez à utiliser un outil de suivi des problèmes pour suivre votre liste de tâches.

Cela vous aidera non seulement à garder une trace de ce qui est critique, mais aidera également les utilisateurs et votre patron à voir quelle est votre charge de travail actuelle.

De plus, s’ils embauchent un deuxième développeur (ou si vous arrêtez de travailler et que votre remplaçant prend maintenant votre charge de travail), cela vous aidera à gérer cette charge de travail et vous éviterez de vous faire marcher sur les pieds.

Le seul moyen de rompre cette chaîne est de développer de nouvelles infrastructures conçues pour la flexibilité et testées à l’unité et à l’intégration.

Si vous parvenez à vendre cela à la direction (engagez d'autres concepteurs et responsables sur le concept lors de réunions 1: 1), vous pourrez alors atteindre lentement un état dans lequel la plupart du code des applications se trouve dans l'infrastructure et il est facile de développer et maintenir, alors que les applications réelles sont légères et peuvent être écrites assez rapidement.

Le développement de l'infrastructure peut permettre, dans un premier temps, de remplacer des parties d'applications existantes et, au bout d'un certain temps (éventuellement quelques années), de remplacer des applications entières.

À long terme, cela peut réduire considérablement le temps de développement de nouvelles applications et le temps de maintenance des applications existantes futures.

Le nouveau développement nécessitera au moins 80% de dévouement (de préférence plus) avec une équipe de plus d’un développeur (quelques esprits valent mieux qu’un seul). Tous les développeurs devront être capables de penser de manière créative et de briser les idées préconçues existantes.

Essayez de définir et de concevoir à haut niveau une telle nouvelle infrastructure, puis présentez la définition à vos pairs et à la direction.

En fonction de vos conditions de travail, demandez à diriger une nouvelle équipe d’infrastructure chargée de ces problèmes (sur la base de vos définitions et de votre conception) et invitez de nouveaux développeurs à gérer l’ancien matériel tout en vous aidant si nécessaire (jusqu'à 10 à 20% des utilisateurs). le temps). Si la direction accepte l’idée, vous pouvez demander à renégocier vos conditions. Préparez-vous à trouver un autre emploi s'ils refusent. (N'oubliez pas que votre travail requiert des compétences, des connaissances et de l'expérience, vous n'êtes pas aussi facile à remplacer que vous le payez pour le croire.)

Votre responsable est-il au courant de toutes ces demandes de changement (demandes de maintenance)? Est-ce qu'il / elle se rend compte que votre temps est pris en passant au crible de telles demandes que vous n'avez aucune autorité pour sanctionner? Ou bien apportez-vous des modifications à chaque fois qu'un responsable vous le demande?

Il me semble que votre premier point de contact est de tout mettre sur le bureau de votre responsable. Personne ne devrait venir à vous directement. Les problèmes devraient venir de quiconque, par exemple une équipe de soutien. Il est normal que vous preniez en charge votre code pendant une courte période de transfert, généralement une semaine environ. Les changements doivent être chiffrés et facturés (frais de transfert) dans toute entreprise qui se qualifierait de "taille moyenne", et cela semble être en train d’être ignoré (il n’est pas surprenant qu’ils vous submergent - vous êtes comme la salope du bal de promo).

Il devrait y avoir une procédure de demande appropriée pour les problèmes soulevés et les demandes de changement. Le support / maintenance concerne la correction des bogues et des problèmes (qui correspondent à la spécification d'origine, mais échouent à cause d'un bogue dans le code ou d'un événement extérieur - comme une mise hors tension ou un système en amont corrompu, etc.).

Si votre entreprise ne propose rien de tout cela et s'attend à ce que vous vous en teniez à cette myriade de demandes aléatoires, alors vous devez sérieusement envisager de passer à autre chose. Les salaires sont toujours très bas - dans mon premier emploi en programmation (il y a presque 25 ans), j'ai passé 8 ans pour la même entreprise et mon salaire a peu augmenté (même s'il était toujours beaucoup plus élevé qu'un caissier!). Deux ans après mon départ, je l'avais doublé - et deux ans plus tard, je rentrais chez moi plus de dix fois ce que j'avais commencé (mais j'étais alors un entrepreneur indépendant). Comme toujours, gagnez de l'argent, apprenez votre métier et passez dans un environnement plus chaud.

Peut-être pouvez-vous vous adresser à un responsable et lui dire: «Écoutez, je vais être franc avec vous. Mon salaire est terrible. Je pourrais obtenir N fois cela en tant que programmeur débutant chez X.

Je fais beaucoup trop de choses avec A, B et C. Je ne peux pas maintenir ça. Honnêtement, et sans vouloir offenser personne, je vais sortir de la salle avec ceci réglé ou avec ma lettre de démission laissée avec vous. Maintenant que tout est dans l'air, comment pouvons-nous travailler ensemble pour que cela fonctionne correctement? "

La solution consiste à essayer de l'expliquer dans des termes compréhensibles.

• C'est comme les changements d'huile. Ils ne sont pas urgents .... mais doivent être faits régulièrement néanmoins
• peinture sur la rouille et ça va fière allure. Jusqu'à ce qu'il saigne
• construire un nouveau bureau de toit de terrasse sur le toit sans renforcer les appuis. Cela fonctionnera peut-être pendant un moment. Ensuite, il va s'effondrer et blesser les gens et vous serez responsable.
• La climatisation est géniale. Une unité de fenêtre est idéale pour une ou deux pièces. Essayer de placer 146 climatiseurs de fenêtre dans un immeuble et vous aurez ... des problèmes.
• Enseigner à 5 enfants c'est bien. 10 c'est pas trop mal. Mais il y a des limites. Essayez d'enseigner de manière informelle à 75 enfants et vous verrez cela.

Si ceux-ci ne résonnent pas. Partez - LE JOUR QUE VOUS OBTENEZ UNE OFFRE SUR ÉCRIT, pas le lendemain! Une fois que vous avez un nouvel emploi, partez sans préavis. Littéralement, ne venez pas ce jour-là. Mais assurez-vous d'avoir un ou deux collègues qui savent ce que vous avez fait. Cela aidera réellement l'entreprise, si elle peut être aidée, en leur montrant que leur manque de respect et leur arrogance ont un prix. Dernière entreprise, j'étais à trois des quatre technologies à gauche dans les 6 mois, sans travail à aller. Il a au moins fait une déclaration et donné à la personne qui partait une bonne occasion de dire: «Oui, gentil, vous dites tous les jours, mais vous en êtes tellement rempli que je ne vous donne même pas la satisfaction de mon avis.

Enfin, sachez que cette affaire était la NORM et la norme il y a 20 ans, avant que agile, tdd, bdd et refactoring ne deviennent plus que la norme. Vous êtes peut-être en train de parler à des personnes de haut rang qui répondent immédiatement: "C'est ce que j'ai fait moi-même et tout a bien fonctionné, bla, bla, bla." Eh bien, les chevaux et les calèches fonctionnaient bien il y a 150 ans. Dans les domaines technologiques, les techniques d'il y a 20 ans sont aussi désuètes que les transports d'il y a 150 ans. S'ils rejettent cette amende. Sachez simplement qu'ils n'engageront jamais de développeurs de technologie décents qui resteront. Ils auront le pire des pires et leur entreprise en souffrira terriblement. S'ils dépendent de la technologie et ne peuvent pas s'adapter, ils échoueront et ce sera peut-être la meilleure récompense pour vous. Il'

Il semble que votre direction ne vous respecte pas et ne comprenne pas votre charge de travail.

Vous ne devriez pas implémenter chaque demande de fonctionnalité qui arrive. Votre responsable doit agir en tant que tampon entre vous et les demandes entrantes (à l'exception peut-être de la plus simple des demandes d'interruption / correction). Ensuite, il ou elle devrait s'asseoir avec vous pour déterminer la faisabilité et la priorité de toute demande approuvée.

En outre, vous devriez probablement faire 2x (au moins) ce qu'ils vous paient.

On dirait qu'ils ont probablement besoin d'au moins un autre développeur pour travailler à vos côtés, mais avec ce qu'ils vous paient, cela semble plutôt improbable.

S'ils ne sont pas disposés à vous payer suffisamment ou à vous aider à gérer votre charge de travail, je chercherais un nouvel emploi. Vous souhaitez travailler dans un lieu où vous faites partie d'une équipe et où votre direction travaille avec vous pour mener à bien vos projets. Quittez ce navire en train de couler dès que vous le pouvez.

Etre un héros dans une équipe ne peut que vous épuiser.

Je ne suis qu'étudiant (encore) mais c'est assez normal (de mon expérience de stage). C'est ce que vous obtenez lorsque vous travaillez dans le support et les applications Web.

Je vous conseillerais de comprendre ce que le client (responsable) veut avant de commencer à coder. Cela pourrait être délicat, car parfois ils ne le savent pas eux-mêmes, alors travaillez avec eux jusqu'à ce qu'ils s'entendent sur quelque chose. Assurez-vous que vous êtes tous deux d'accord sur la solution finale avant de la coder.

De même, si vous êtes un responsable, vous pouvez pratiquement changer n'importe quoi dans le code - assurez-vous simplement que cela ne change pas le comportement et ne présente pas de bogues. Je m'attends à ce que les gestionnaires ne vous «autorisent» pas à changer quoi que ce soit parce qu'ils sont habitués et satisfaits de la situation actuelle et qu'ils ne veulent pas payer pour de nouveaux changements.

Enfin, ne vous inquiétez pas si vous ne pouvez pas gérer quelque chose parce que vous faites autre chose. Je vous conseillerais de faire savoir aux gens que votre travail est débordé et que leur demande prendra du temps. Si vous ne le faites pas, les gestionnaires penseraient simplement que vous êtes paresseux. Faites-leur savoir que vous avez déjà du travail et qu'ils pourraient embaucher plus de personnes. Ils n'ont aucun autre moyen de savoir que le travail est trop difficile pour une seule personne.

C'est un problème de gestion de projet. Utilisez une sorte de gestion de projet pour décider de la priorité absolue sur laquelle vous souhaitez travailler.

a) Vous avez besoin d’un arriéré d’articles sur lequel travailler. Vous mettez votre plan pour améliorer le code dans l'arriéré.

b) Tous les bogues entrent dans l'arriéré

c) L'arriéré est hiérarchisé.

d) Vous faites tout cela par ordre de priorité.

Les bugs peuvent très bien avoir une priorité plus élevée, mais si vous corrigez une fois pour toutes, vous avez des cycles à dépenser pour de nouvelles fonctionnalités ou pour la conception de refactoring.

Il est plus simple de procéder à une refactorisation progressive des améliorations, en passant sur les sections présentant des problèmes / bogues à résoudre. Ensuite, vous pouvez dire à la direction: "Je devais corriger A, mais B était fondamentalement cassé et je devais faire la solution C pour tout réparer afin que D soit plus facile / moins cher dans le futur" Où A = Le bug, B = Le anti-pattern, C = solution, D = gains futurs

Si vous ne pouvez pas justifier le travail comme un investissement rentable, les hommes d’affaires ne l’accepteront jamais.

C'est comme d'habitude. Vous serez exploité aussi longtemps que vous travaillerez, semble-t-il. Il est dans l'intérêt de l'entreprise de continuer avec ce modèle plutôt que de vous faire sentir heureux dans ce que vous faites. En fin de compte, ils ne s'en soucient pas vraiment. Il s'agit de créer un code fiable pour eux et si vous êtes un one-man-band, ils vont certainement vous faire banque. Pourquoi changeraient-ils?

La bonne nouvelle, c'est que vous êtes un VIP pour eux, même s'ils ne le savent pas. Ce que je suggère, c’est d’aligner encore plus de possibilités avant de sauter, puis de les saisir par la balle et d’exiger un salaire plus élevé. Si pas passer à une meilleure opportunité. À mon avis, vous devriez bientôt trouver du travail plus excitant. Visez aussi haut que vous pouvez. Une fois que vous arrivez dans une boutique de développeurs, vous serez beaucoup plus heureux, comme Google ou une start-up amusante, dans laquelle il existe une culture de développeurs collaborative où vous vous sentirez vraiment heureux.

Personnellement, j’ai eu recours à une organisation de sous-traitants pour chasseurs de têtes et j’ai rapidement eu beaucoup d’excellentes expériences à mon actif, passant de l’une à l’autre tout en maintenant un emploi stable chez mon sous-traitant. Cela vous empêche de vous ennuyer et vous met au défi. Finalement, pendant mon temps libre, j'ai bâti une petite entreprise qui est devenue une véritable affaire, puis j'ai quitté le marché pour faire du travail contractuel.