Je fais 90% de maintenance et 10% de développement, est-ce normal?
Je viens tout juste de commencer ma carrière de développeur web pour une entreprise de taille moyenne. Dès que j'ai commencé, j'ai eu la tâche d'étendre une application existante (mal codée, développée par plusieurs programmeurs au fil des ans, gère les mêmes tâches de différentes manières, structure nulle).
Donc, après avoir réussi à étendre cette application avec la fonctionnalité demandée, ils m'ont donné la tâche de maintenir entièrement l'application. Ce n'était bien sûr pas un problème, du moins c'est ce que je pensais. Mais j'ai appris que je n'étais pas autorisé à améliorer le code existant et à me concentrer uniquement sur les corrections de bogues lorsqu'un bogue est signalé.
Depuis lors, j'ai eu trois autres projets, tout comme celui ci-dessus, que je dois également maintenir. Et j'ai eu quatre projets où j'ai été autorisé à créer l'application à partir de zéro, et je dois aussi les maintenir.
En ce moment, je commence à devenir un peu fou des mails quotidiens des utilisateurs (gestionnaires de lecture) pour chaque application que je dois maintenir. 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 bug sur tout ce que j'ai moi-même codé. Pour cela, je n'ai reçu que des demandes de changement occasionnelles de choses à faire à 180 degrés.
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 à des choses différentes?
Je suppose que ce message est devenu une grosse diatribe, mais dites-moi que ce n'est pas la même chose pour tous les développeurs.
P.S. Mon salaire est presque égal sinon inférieur à celui d'un caissier dans un supermarché.
Au cours de l'un de mes stages j'ai trouvé que je passais beaucoup de temps à corriger des bogues. Vous devez réaliser qu'en tant qu'employé débutant, vous n'obtiendrez pas le travail le plus sexy, vous obtiendrez le travail de grogne que personne d'autre ne veut. C'est malheureux, mais c'est comme ça à chaque emploi.
De plus, vous devez réaliser que pour une entreprise, avoir du code qui fonctionne est plus important que d'avoir du code propre. Du point de vue de votre entreprise, vous changez la structure existante est de l'argent gaspillé pour refaire quelque chose qui est déjà fait et en introduisant potentiellement encore plus d'erreurs. Habituellement, ces types d'entreprises ne sont pas des sociétés informatiques/logicielles, donc aucun gestionnaire suffisamment élevé n'a les connaissances techniques pour savoir que parfois vous devez effectuer ces révisions majeures. Cela dit, si votre entreprise est dirigée par des personnes techniquement compétentes et qui comprennent la valeur d'un bon code, vous pouvez obtenir plus de latitude, même si parfois vous devez choisir vos batailles (le but principal d'une entreprise est toujours de gagner de l'argent, après tout ).
Cela dit, vous n'êtes pas déraisonnable en voulant pouvoir laisser votre marque sur le logiciel et en souhaitant 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, c'est une réalité de la vie que vous passerez plus de temps à maintenir et à modifier le code des autres que d'écrire le vôtre à partir de zéro. Si c'est un problème pour vous, alors vous devriez peut-être vous concentrer sur le développement comme passe-temps et poursuivre une carrière différente. Si vous êtes d'accord avec le maintien du code, mais vous sentez que vous n'êtes pas utilisé efficacement ou que vous êtes dépassé, alors c'est une question dont vous devez discuter avec votre responsable. Si vos problèmes sont plus graves que cela ou si vous avez l'impression que vos managers ne savent pas comment gérer efficacement votre ensemble de compétences, ce serait une bonne idée d'envisager de trouver un poste dans une autre entreprise. Compte tenu de votre faible salaire déclaré, c'est probablement votre meilleure solution.
Il semble que la direction ait du mal à gérer votre charge de travail et à hiérarchiser les 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 de vous bombarder de demandes qu'il souhaite satisfaire immédiatement.
Cela vous fait passer d'une tâche et d'un projet à l'autre, ce qui vous fait perdre beaucoup de temps à changer de vitesse dans votre esprit. Pour un travail de développement logiciel efficace, il faut être capable de s'immerger dans une tâche et de s'y concentrer pleinement. Plus il y a d'interruptions, plus le changement de contexte est perdu. La recherche montre qu'il faut environ 15 minutes pour s'immerger et atteindre l'état de flux où notre esprit fonctionne le plus efficacement. Si vous obtenez des interruptions toutes les 15 minutes, vous ne pouvez jamais circuler, ce qui est un énorme gaspillage pour vous et pour l'entreprise.
Vous devriez donc essayer de négocier un mode de travail plus sensé avec votre manager . Cela devrait inclure hiérarchiser les demandes entrantes et planifier à l'avance dans une certaine mesure . Toutes les demandes des utilisateurs doivent être conservées dans une liste, triées par priorité. Et les priorités ne doivent pas être décidées par le demandeur (comme naturellement tout le monde pense que sa demande est la plus importante sur terre), ni par vous, mais par quelqu'un ayant suffisamment de connaissances en affaires et une vue d'ensemble de toute la gamme de produits que vous gérez (le propriétaire du produit).
Idéalement, toutes les demandes entrantes doivent être saisies dans un outil de suivi des problèmes comme JIRA ou Mantis . Ou au moins par la poste au propriétaire du produit, pas à vous. Et il/elle devrait aussi traiter toutes les plaintes des utilisateurs sur "pourquoi ma demande n'est pas encore prête?!", Vous permettant de vous concentrer sur le travail de développement. Si cela n'est pas possible, vous devez au moins négocier certaines fenêtres de temps lorsque vous examinez les demandes entrantes et les traiter, en réservant une partie ininterrompue de votre temps uniquement pour le 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 implémenter les demandes prioritaires, puis planifiez votre temps dans sprints , qui peut être d'une ou plusieurs semaines chacune, et allouez 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 le lundi, le projet B le mardi-mercredi, le projet C le jeudi matin et D l'après-midi, 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 quelle demande est mise en œuvre. Vous pouvez ou non vouloir mentionner le mot "agile" à votre responsable ici - c'est essentiellement développement agile , mais certaines personnes s'opposent à l'agile sans vraiment savoir de quoi il s'agit :-)
Notez que même si votre position actuelle semble peu valorisée par votre entreprise, plus vous maintenez de projets, plus vous avez de pouvoir de négociation .
Trouver et former une nouvelle embauche pour maintenir tous ces projets prend beaucoup de temps (= argent) pour l'entreprise. Et vous pouvez à juste titre souligner que votre code est bien meilleur que les parties héritées de ces applications, il n'est donc pas certain qu'ils peuvent facilement trouver un candidat de capacités similaires pour le même montant d'argent. Sans oublier que s'ils n'améliorent pas les conditions de travail, ils feront que le prochain gars en aura marre et quittera aussi vite que vous ... Essayez de leur faire comprendre que c'est dans leur propre intérêt à vous garder et à vous satisfaire où que vous soyez :-) Cela peut vous donner un certain pouvoir pour négocier les conditions ci-dessus et/ou demander une augmentation de salaire.
Combien de pouvoir de négociation vous avez - c'est une grande question. Votre direction peut être ou non ouverte à ces idées et peut ou non 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 tous les démarreurs, bien que (malheureusement) vos expériences soient assez typiques. Mais il y a vraiment de meilleurs lieux de travail . La qualité du lieu de travail n'est que faiblement corrélée à la situation géographique, mais j'ai le sentiment qu'en Europe du Nord, vous avez des chances supérieures à la moyenne. Donc si vous ne pouvez pas améliorer sensiblement vos conditions actuelles, vous devriez commencer à chercher immédiatement , avant d'en avoir complètement marre et de vous épuiser.
Il est extrêmement préférable de chercher un emploi pendant que vous en avez encore 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 :-)
P.S. Mon salaire est presque égal sinon inférieur à celui d'un caissier dans un supermarché.
Hé, je voulais écrire quelque chose sur la façon de négocier jusqu'à ce que je le lise. Maintenant, tout ce que je peux dire, c'est partir! En supposant que c'est la moitié de ce que gagne généralement un développeur diplômé. 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 le temps qu'il faut pour y arriver. Il semble également que vous n'ayez rien appris sur le tas 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, cela ne finit jamais. La direction continuera de vous pelleter, car ... ils le peuvent.
Il y a quelques réflexions supplémentaires que j'ai sur ce sujet.
Fais ce que tu aimes. Si vous ne l'aimez pas, préparez-vous à essayer de trouver ce que vous pourriez aimer.
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 dit: "vous devez gérer les attentes des autres envers vous."
Burnout. Si vous n'avez pas connu d'é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, morne et vide de sens. Je vous donne ce conseil car vous devez à tout prix éviter l'épuisement professionnel.
Entraînement. Voici la doublure argentée. Votre formation et votre expérience, tout en étant frustrantes et peut-être sous-payées, sont en fait très précieuses pour votre carrière. C'est votre grâce salvatrice pour le réaliser car vous pouvez vous imprégner du plus d'apprentissage 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 mèneront à travers les 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 courant? Malheureusement oui.
Concernant la frustration de correction de bugs
Bien que cela n'excuse pas le reste du gâchis auquel vous avez à faire face et les multiples projets avec lesquels ils vous surchargent, je veux juste faire une brève note que l'approche "correction de bogue" uniquement, tout en frustrant pour vous en tant que développeur , peut être une approche parfaitement sensée pour l'entreprise et sa direction.
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 votre intention est de l'améliorer. Cela signifie un temps de développement, un temps de test et des coûts prolongés. Et si cela passe à une version de service avec un défaut moyen à élevé, c'est un gros gâchis pour eux.
Bruit/brouillard dans vos journaux
D'un point de vue SCM, cela a également un peu de sens si vous travaillez directement sur la branche d'une version de service, car vous voulez avoir une vue claire des changements liés à la correction de bogues. S'il y a 15 commits avec des milliers de modifications entourant un correctif qui nécessitaient peut-être un changement de code d'une ligne, c'est un peu ennuyeux.
Donc, étant une nouvelle recrue, il est encore plus judicieux de vous demander de vous abstenir de refactoriser et/ou d'améliorer le logiciel, et tout à fait correct à mon sens d'être aussi "chirurgical" que possible avec vos corrections de bugs. Il garde juste les maux de tête à distance.
Peux-tu faire quelque chose pour cela?
Maintenant, cela ne signifie PAS qu'il y aurait des moyens d'atteindre à la fois la raison du code et la raison des esprits des personnes impliquées. Étant junior, ils devraient demander à quelqu'un d'examiner vos modifications, en particulier les corrections de bogues, et de vous assurer qu'elles sont approuvées avant de passer aux versions de version 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 ici, mais montrant simplement que votre demande initiale contient quelques bits non consécutifs.
Mon point est le suivant: j'ai vraiment vraiment vraiment repris rarement une base de code qui n'était pas dans cet état. Et par hasard que je l'ai fait, il s'agissait de projets ou de prototypes récemment lancés par des programmeurs assez stellaires. Mais la très grande majorité d'entre eux ressemblait à de la merde, et un nombre effrayant d'entre eux étaient de la vraie merde. Même ceux commencés par de bons ou de bons programmeurs peuvent finir par être de la merde, des délais et d'autres engagements qui aident ...
Bienvenue dans l'ingénierie logicielle industrielle réelle!
Et tu sais ce qui est amusant? C'est souvent bien pire dans le monde du développement Web. Profitez-en! :)
Trop de projets et de demandes, pas assez de temps et de mains
Le problème réside probablement ici dans:
- votre gestion (peut-être inconsciemment) vous abuse,
- vos collègues (peut-être inconsciemment) vous abusent,
- votre (peut-être inconsciemment) ne couvrant pas votre cul et ne combattant pas assez vos combats.
Vos managers doivent être conscients que vous travaillez sur trop de projets à gérer. S'ils ne le sont pas, assurez-vous qu'ils sont ASAP. Assurez-vous également qu'ils savent que ce n'était pas une simple piqûre dans le parc et que vous vous sentiez sous pression et que cela devait s'arrêter.
Essayez de regarder autour de vous et assurez-vous que vos collègues ne détournent pas plus de tâches et de projets sur vous, directement (en disant vraiment "X pourra s'en occuper") ou indirectement ("Je ne suis pas la bonne personne pour cela, trouver quelqu'un d'autre "-> finit par être vous).
Anecdote personnelle ici: J'ai fait un stage il y a quelques années, et juste le tout dernier jour, quand j'ai eu mon évaluation, mon patron m'a dit, bien qu'il soit très satisfait de mon travail dans l'ensemble, que - n des managers avait l'impression que je déchargeais des "tâches pas si amusantes" sur un autre stagiaire quand il se serait attendu à ce que je les récupère. J'étais mortifié de les faire sentir déçus, et à l'idée que je donnerais l'impression de me relâcher, quand mon intention était exactement le contraire: j'essayais de saisir le plus fort tâches et demandez à l'autre stagiaire plus jeune de faire face à moins de problèmes de tirage. Je n'avais pas réalisé que, si j'avais été à sa place, j'aurais été ennuyé par le manque de défi et probablement ressenti comme lui. Le fait est que vous devez communiquer pour vous assurer que personne ne fait de fausses hypothèses sur 3 choses très distinctes:
- ce que vous pouvez faire,
- ce que vous voulez faire,
- et ce que vous êtes prêt à faire.
C'est aussi en partie de votre faute pour l'avoir laissé ainsi. Mais c'est normal, c'est une leçon que tout le monde doit apprendre. Il contient deux lettres: N - O .
Vous l'utilisez habituellement comme préfixe pour une réponse plus longue mais pas beaucoup plus chargée: non, je ne peux pas faire ça. Non, je ne sais pas comment faire ça. Non, je ne suis pas sûr d'être la bonne personne pour ça. Non, je n'ai jamais fait ça.
Au début, il est très facile de se sentir comme si vous pouviez simplement dire "oui, je vais (éventuellement) le faire", et empiler les choses et les faire, peut-être en mettant quelques 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é, il a un impact sur les projets, les délais et les budgets. Aussi simple que cela.
De plus, il semble un peu inquiétant que vous ayez trop de personnes à qui faire rapport. C'est OK d'avoir plusieurs clients avec qui traiter, et plusieurs propriétaires de projets ou même les principales parties prenantes avec lesquelles vous devez communiquer. Mais, dans l'ensemble, d'autant plus que vous êtes un nouvel embauché, vous devez principalement relever de quelques gestionnaires uniquement (et probablement uniquement de votre gestionnaire direct, et éventuellement d'un développeur principal ou principal). Comment est-ce arrivé? Je ne sais pas. Cela peut être un problème d'organisation dans votre entreprise, ou cela peut être le résultat de votre faveur et d'être ensuite contacté directement, et de ne pas dire "non". Ou il se peut que votre gestionnaire direct pose des problèmes avec les tâches de répartition, pour autant que je sache (je suppose vraiment, mais le modèle est reconnaissable et bien connu).
Je vous recommande de faire ce qui suit assez rapidement: allez parler à votre supérieur direct en personne, expliquez que d'autres gestionnaires pourraient être un peu arrogants, ou (probablement moins pleurnicher) que vous avez trop de choses à vous empiler de trop de gens, et que vous avez besoin de sa contribution (et peut-être aussi de la leur) pour savoir lesquels privilégier.
Demandes de changement à 180 degrés
Ce sont un autre gros problème. Ce n'est 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 magnifiquement et avec 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 ciseler et les nettoyer temps.
C'est généralement lorsque quelqu'un doit prendre le téléphone (ou mieux, debout) et saisir les parties prenantes par la main et leur dire clairement: "c'est là que nous sommes, c'est là que vous voulez que nous allions , confirmez-vous que nous allons dans la bonne direction? ". Il est normal 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 une catastrophe qui attend de se produire.
Habituellement, je dirais saisir toutes les parties prenantes à portée de main, les mettre dans une pièce, les conduire à travers des problèmes litigieux et essayer progressivement de les résoudre - et obtenir des priorités pendant que vous y êtes. Cependant, dans votre cas, ce n'est peut-être pas votre appel à faire déjà. Mais vous mentionnez qu'ils vous ont vraiment donné la responsabilité des projets; donc si c'est vraiment le cas, alors prenez la responsabilité et faites-le. Et N'HÉSITEZ PAS à dire "nous NE POUVONS PAS faire cela", ou même "nous NE LE FAISONS 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 des e-mails
Les gens ont tendance à se comporter différemment en fonction du support de communication qu'ils utilisent. Personnellement, bien que je sois plutôt douce (et que je travaille principalement dans des pays étrangers, je finis également par ne pas aimer parler au téléphone), je privilégierais par ordre de préférence en fonction de 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 agréables pour le suivi, pour obtenir des confirmations, pour envoyer des notes.
Pour planifier, planifier et discuter des points problématiques, ils sont presque inutiles. Allez frapper à la porte du gars jusqu'à ce qu'il l'ouvre et asseyez-vous avec un bloc-notes et une copie de votre documentation pour clarifier les choses. Une fois que vous avez terminé, envoyez un e-mail et demandez une confirmation. S'il revient avec une réponse négative ou une tentative légèrement cachée de faufiler autre chose dans l'enveloppe, allez à nouveau faire le siège du bureau de votre interlocuteur.
C'est du génie logiciel. Il est souvent plus productif lorsque vous ne tapez pas sur un clavier, et peut en fait réduire à l'avance la merde dont vous aurez besoin.
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 surmené. Et c'est là le problème: vous êtes surchargé de choses qui devraient être exclues des délais actuels du projet, ou données à quelqu'un qui a du temps libre.
Étais-je un idiot quand je m'attendais initialement à des choses différentes?
Non; juste nouveau pour le parti. C'est comme une première gueule de bois ou une première relation. Vous vous en remettrez.
Je suppose que ce message est devenu une grosse diatribe, 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 sans expérience ni confiance pour faire bouger les choses un peu pour faire pencher vos chances de survie du bon côté de l'échelle.
P.S. Mon salaire est presque égal sinon inférieur à celui d'un caissier dans un supermarché.
J'ai fait des salaires décents pour des emplois qui semblaient minables. Ce n'est pas le numéro du chèque qui compte, c'est le contexte. Ce que vous faites, votre âge, où vous vivez et travaillez, etc ...
Cela étant dit, si vous êtes très sous-payé, travaillez trop et pas tout à fait junior, allez demander cette augmentation ou obtenir un nouvel emploi!
C'est simple:
- s'ils apprécient ce que vous faites, ils accepteront volontiers une augmentation,
- s'ils ne le font pas, l'avenir dans cette entreprise ne semble pas très rose (pour vous, du moins, ce qui compte), alors ne vous sentez pas mal à l'idée de partir.
Sachez que demander une augmentation est une bonne chose, même si vous ne seriez pas enclin à le penser au début. Cela prouve que vous gardez une trace de ce que vous faites et laisse entendre que vous gardez un œil sur les autres options tout en étant prêt à rester à bord. Et c'est une bonne chose de s'habituer à les demander, car ce sont comme 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 distribueront des augmentations régulièrement sans y être invité, mais c'est uniquement parce qu'elles sont assez intelligentes pour savoir que cela vous garde à moitié heureux et moins disposé à changer, et qu'elles veulent couper l'herbe sous votre pied (la plupart des gens ressentiraient un peu inquiet à l'idée d'augmenter une offre d'augmentation qui leur a été proposée directement).
Comment procéder avec cette demande est un peu hors de portée de CE projet ici, donc je n'entrerai pas dans les détails. Mais je vous recommande de préparer un enregistrement de vos ID de validation SCM, de vos bogues corrigés et de vos réalisations, et de préparer également des rapports en les comparant à l'effort global de l'équipe. Par ici:
- vous pouvez mesurer par 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 des autres:
Oui, il est normal qu'un employé débutant reçoive les emplois que personne d'autre ne veut faire.
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 pourriez avoir du mal à tirer parti des bonnes choses que vous faites actuellement - vous devriez donc essayer de faire des choses comme les suivantes (si vous n'êtes pas déjà).
Enregistrez votre travail avec précision, pour chaque projet. Donc, si vous passez une heure à corriger un bug sur le projet A, connectez-vous cette fois. Cela sera utile de montrer à votre responsable si vous souhaitez discuter des charges de travail.
Écrire des tests unitaires. Vous mentionnez que certains des projets que vous maintenez sont pleins de bogues, donc je suppose qu'il y a peu (le cas échéant) de tests unitaires. Pour chaque rapport de bogue, écrivez un test unitaire qui reproduit le bogue, puis corrigez le bogue. Cela aidera à garantir qu'aucune régression ne se produira, améliorera la qualité du code et servira de plate-forme sur laquelle refactoriser le code si vous en avez la chance (par exemple, cela pourrait vous aider à convaincre les parties prenantes que la réécriture de certaines parties pourrait améliorer qualité sans introduire de nouveaux bugs, en raison de la suite de tests unitaires).
Recherchez un nouvel emploi - vous travaillez sur de nombreux projets à la fois, vous avez écrit du code à partir de zéro et vous avez probablement expérimenté tout le cycle de vie du projet - ce sont toutes de bonnes expériences pour postuler ailleurs.
Votre situation est un peu énervé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 une preuve (nombre) du temps que coûte réellement la mauvaise base de code. S'il ne comprend pas des choses comme la dette technique, arrêtez de le mentionner. Cela vous ferait perdre la tête et vous pourriez être marqué comme un gars de "mauvaise attitude". Ce n'est pas votre travail d'apprendre à votre patron à faire son travail.
Gérez votre propre backlog (kanban). Lorsque de nouvelles tâches arrivent, arrêtez-les et indiquez l'heure approximative de leur achèvement.
Augmentez votre temps de réponse, vérifiez votre courrier électronique seulement deux fois par jour. Généralement avant le déjeuner et juste avant votre départ. (La vérification des e-mails ne doit pas être suivie d'un codage, car cela pourrait vous casser la tête).
Faites de petites améliorations de code dans le cadre de chaque tâche. C'est simplement votre travail d'améliorer le code, les compétences et les outils que vous utilisez. Cela stimulera également votre moral à long terme.
Aucun changement de projet pendant la journée. Aujourd'hui, vous travaillez simplement sur le projet X et vous commencerez d'autres tâches pour Y demain.
Allouez une heure par jour pour le gardiennage. Cela signifie de petites tâches qui sont triviales à faire. Si cette tâche dure plus de 10 minutes (quelle que soit la raison), elle entre dans le backlog et vous informez le manager qu'elle sera retardée.
Vient maintenant la partie difficile. Actuellement, les gestionnaires ne communiquent pas entre eux et supposent simplement que vous terminerez leur propre projet avec une priorité maximale. Cela met 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 agréable et simple et les gestionnaires devraient se mutiler sans vous.
Faisons donc un jeu de rôle simple. Il y a trois gestionnaires et projets (Xavier avec le projet X, Yvonne avec le projet Y et Zed avec le projet Z). Vous avez un carnet de commandes de deux semaines, 5 jours pour X et 5 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 que c'est 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 pouvez ensuite faire son travail.
- Z répond que vous devez de toute façon faire sa tâche immédiatement (pression accrue, violation directe des territoires X et Y).
- Vous répondez que faire sa tâche retarderait le travail pour X et Y. Il devrait leur demander d'abord. Vous aussi CC X et Y.
Maintenant, il y a deux extrémités:
Les managers vont commencer à aboyer les uns les autres, de nombreux e-mails, probablement quelques réunions ... Vous devriez rester à l'écart et laisser le gagnant vous assigner 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 il n'a rien mentionné du projet Z. Encore CC X.
Maintenant, ce type de comportement peut vous faire virer. Mais votre situation n'est pas viable et vous quitterez probablement bientôt de toute façon. Cette solution ne fonctionne que si les managers se font concurrence (très habituel). Vous devez également conserver des enregistrements de votre travail (arriéré), au cas où quelqu'un se plaindrait, que vous vous relâchez.
Il y a sept ans, je travaillais à peu près à 100% pendant un certain temps et j'ai écrit un article à ce sujet: The Art of Maintenance Programming . Une partie que vous pourriez trouver utile:
- Appréciez-le
Comment peut-on aimer la programmation de maintenance? Les développeurs rêvent d'être les architectes en chef de leurs équipes, et lorsqu'ils finissent par maintenir les logiciels existants, cela ressemble presque à une punition. Cela ne doit pas être le cas: la programmation de maintenance a son propre ensemble de défis et nécessite beaucoup de créativité, d’adaptabilité, de patience, de discipline et une bonne communication. Cela peut aussi être bon pour votre carrière: avoir des entrées explosives comme "Application d'entreprise n-tier 24/7 archivée" dans votre CV est joli, mais les employeurs apprécient les personnes qui résolvent les problèmes; et la programmation de la maintenance peut être une bonne occasion de démontrer vos compétences en résolution de problèmes.
Votre problème ressemble à un sommet dont vous entendez plus souvent parler. 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 y a plus que des qualités externes d'un logiciel. Ward Cunningham a inventé le terme dette technique .
Vous pouvez également lire Steve McConnell sur la dette technique . Il a des points intéressants. Dans une conférence Google Tech, Ken Swaber parle de développement de logiciels agiles . Une bonne partie concerne une histoire similaire à la vôtre. Il parle d'un projet logiciel devenu "braindead" après 10 ans de programmation par différents programmeurs sans jamais en faire refactoring . 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é lors de son extension. 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 puis-je convaincre votre patron de refactoriser?" .
Comment j'ai abordé un problème similaire:
- J'ai confronté mon patron et expliqué que la qualité du code se dégrade lorsque nous continuons à 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 la gravité du problème, j'ai (en mon temps) fait une analyse de code statique. Les patrons ne comprennent pas les logiciels, mais ils comprennent les chiffres. Bien que les mesures de code ont leurs défauts il est bon d'avoir quelque chose de mesurable dont vous pouvez parler. Essayez de savoir quelles sont les lectures normales de ces mesures, et vous serez surpris lorsque vous comparerez cela à votre propre base de code.
- Si rien n'y fait et que rien ne change, la seule chose que vous pouvez faire est d'expliquer qu'une certaine nouvelle fonctionnalité nécessitera un remaniement d'autres parties de votre base de code. Expliquez que si vous avez du code en double et qu'ils veulent changer quelque chose, les coûts d'une modification se reproduisent également.
- Une réponse commune au point précédent sera que personne n'a demandé et donc pas payé pour cette reprise. Que "peut-être" ce remaniement soit superflu. Vous devrez expliquer que le logiciel devra toujours changer. Comme les lois de Lehman dire; il devra changer pour rester en service. Sinon, les autres programmes qui ont changé dureront toujours. Ce sont ceux qui attendent le changement et peuvent s'adapter au changement qui survivront. C'est à cela que sert développement de logiciels agiles . ( 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 prouver que - 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 nombreuses recrues.
Cela se produit dans les phases initiales d'une carrière. Voici le piège: nous devons surmonter ce problème et prouver notre valeur à l'entreprise (que ce soit de taille moyenne ou MNC ). Nous devrions être en mesure de prendre des décisions sur ce que les circonstances nous demandent de faire. Il n'y a donc rien de mal à mettre des efforts dans le travail, à condition de vous faire remarquer et de vous présenter comme un individu pour votre travail. Si vous en valez la peine, l'entreprise le remarquera! Adios et bonne chance.
À mon avis, une entreprise qui interdit le refactoring ne vaut pas la peine de travailler. Le refactoring est une compétence essentielle de développement logiciel, et les outils de contrôle de version permettent de développer très facilement des changements de manière isolée sans corrompre le 'trunk' (au cas où un refactor en fait le ferait casser quelque chose). Comme oncle Bob dit (paraphrasé): "Vous ne devriez pas avoir à demander à être un professionnel et à bien faire votre travail."
La programmation de la 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 nouvellement rejoint demande à son patron "quel est le sens de l'évaluation?"
Boss: "Connaissez-vous le sens de la démission?"
Stagiaire: "Oui je fais"
Boss: "Alors laissez-moi vous faire comprendre ce qu'est une évaluation en la comparant à 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 un bilan je vais devoir démissionner ... !!!"
Si j'étais vous, je passerais quelques heures en retard après le travail à reconstruire l'application gratuitement. Ce serait probablement une tâche amusante. Lorsque vous l'avez terminé, montrez-le à votre patron. Si cela fonctionne et que vous en faites l'entretien, il ne devrait pas avoir à s'inquiéter. Cela rendra votre travail beaucoup plus facile et ouvrirait les yeux des hauts fonctionnaires à votre potentiel dans l'entreprise.
Je suis un étudiant à temps plein qui effectue un stage à temps partiel pour 10 USD de l'heure. Je fais des trucs d'assurance qualité ennuyeux, répétitifs et faciles. Je me considère comme extrêmement chanceux, car je sais qu'un jour cela ouvrira des portes à des endroits plus grands et meilleurs.
Oui, vous devrez toujours maintenir des applications, écrites à la fois par vous et par d'autres personnes. La seule exception est si vous écrivez un programme qui n'a jamais besoin de maintenance. Il vaut donc mieux devenir bon en maintenance.
Je pense qu'il y a un soupçon subtil dans votre question d'un défaut dans votre approche. C'est-à-dire que la correction des bogues n'implique pas l'amélioration du code.
Mais j'ai appris que je n'étais pas autorisé à améliorer le code existant et à me concentrer uniquement sur les corrections de bogues lorsqu'un bogue est signalé.
Je ne peux pas croire que quelqu'un vous ait 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 à refactoriser. Chaque fois que vous corrigez un bug, vous avez la possibilité d'améliorer au moins une partie du code. La quantité de base de code qui est refacturée dépend de ce qu'est le bogue et de la qualité du code. Mais si vous corrigez des bogues et que vous quittez sciemment le code sent partout, alors vous ne faites pas votre travail et vous accumulez dette technique .
Certains bugs sont en fait corrigés simplement par refactoring, et parfois il est utile de refactoriser pour vous aider à comprendre le code . En effet, le refactoring devrait 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 sera le meilleur moyen de le faire, et j'en tiendrai compte. La même chose avec les tests unitaires. Ces deux choses devraient faire partie de la façon dont vous écrivez du code, et non quelque chose de facultatif qui implique du temps supplémentaire.
Vous ne devriez donc pas demander "puis-je améliorer le code lorsque je corrige le bogue?" Parce que tu devrais être de toute façon. Vous ne devriez pas demander "puis-je utiliser le refactoring pour corriger le bogue?" Parce que si le code qui provoque le bug de l'application a un besoin urgent de refactoring, vous devez le faire quand même. Vous ne devriez pas demander "puis-je écrire des tests unitaires lorsque je corrige ce bogue?" Parce que vous devez écrire un test de régression avant même de commencer à essayer de corriger le bogue.
NB: Je pense que l'attribution de cette réponse devrait aller à Jeff Atwood, car j'ai lié 3 de ses articles.
Ce ne devrait pas être la décision de votre employeur 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 du temps supplémentaire pour permettre une refactorisation, si cela augmentera la productivité à l'avenir.
Quoi qu'il en soit, il semble que vous ne communiquez pas efficacement avec votre employeur.
Vous avez la preuve que le refactoring vous fera économiser de l'argent. Rédiger une proposition de projet de refactoring et démontrer combien de temps et d'argent l'entreprise pourrait économiser. Décrivez précisément les modifications que vous apporteriez au code et combien de temps cela prendrait.
Gardez un journal précis pour enregistrer combien de temps vous passez sur le codage, les réunions et la réponse aux e-mails. Cela vous protégera si vous prenez du retard.
Ralentir. Cela peut sembler un peu contre-intuitif, mais votre temps ne sera abusé que si vous faites tout rapidement. Les gens respecteront davantage votre temps si vous en faites moins. Par exemple, je ne vérifierais les e-mails qu'une ou deux fois par jour. Sinon, vous risquez l'épuisement professionnel.
Compte tenu de votre taux de rémunération, cela ne vaut pas la peine d'avoir un mal de tête. Assurez-vous de partir à l'heure tous les jours. Ne mettez pas d'heures supplémentaires sans compensation supplémentaire. L'exception est s'il existe de bonnes options d'avancement, ou si la réputation de l'entreprise stimulera considérablement votre curriculum vitae, alors vous n'aurez qu'à le sucer.
Sans en savoir plus, je vous suggère simplement d'essayer d'être plus ouvert avec vos managers. 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 patron et lui expliquer que vous souhaitez une augmentation de salaire au cours des six prochains mois, et demander comment vous pourriez améliorer votre performance afin de réaliser cette augmentation de salaire.
Bonne chance.
Essayez de parler avec vos employeurs et voyez si vous pouvez résoudre ce problème. On dirait que vous êtes bien au-dessus de votre tête à ce sujet, et cela n'a rien à voir avec le fait d'être un mauvais programmeur.
Les petites sociétés Web ont tendance à avoir beaucoup de projets en cours en même temps, ce qui vous laisse à bien des égards. Soit essayez de tirer le meilleur parti de votre situation, soit essayez de trouver un nouvel emploi si vous pensez que vous le pouvez. Je promets qu'il existe de meilleurs emplois de codage, alors ne laissez pas cette première 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 également votre situation. J'ai essentiellement obtenu mon premier emploi de codage avec un faible salaire et j'ai dû maintenir beaucoup de code construit avec une mauvaise structure. Au début, j'ai trouvé drôle d'apprendre de nouvelles choses, mais quand j'ai finalement eu beaucoup de projets à maintenir, de nouveaux projets à faire et un tableau blanc qui grandissait de jour en jour avec des points avec lesquels je n'avais pas fini, j'ai réalisé que ça ne marchait pas.
Après l'avoir supporté pendant deux ans, j'ai quitté et j'ai trouvé un autre travail de codage quelques mois plus tard qui me convenait parfaitement.
Quoi qu'il en soit, plusieurs fois, ce ne sont pas seulement vos projets qui pourraient être en cause. Je me sens plus à l'aise sur un lieu de travail lorsque je suis reconnu et respecté pour mon travail. Le problème avec la situation dans laquelle vous vous trouvez est que vos employeurs ne remarquent que les bogues qui proviennent des projets créés, et non le temps que vous prenez pour supprimer tous les autres bogues.
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%.
Fondamentalement, pensez à la valeur de votre travail et aux besoins de l'entreprise. S'ils ne peuvent pas se permettre de vous donner le salaire que vous avez gagné, l'entreprise doit alors examiner leurs dépenses ou réaliser 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 puzzle de l'entreprise. Enfer, vous êtes probablement le seul à pouvoir résoudre ce casse-tête. :)
Celui-ci est une question d'argent. Je suppose qu'en tant que débutant, vous êtes probablement trop gentil pour les clients qui ont déjà reçu plus qu'ils n'ont payé.
Apprenez à proposer un prix pour de 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 pensez en termes d'argent, la communication avec la direction devient beaucoup plus facile. Si vos clients actuels fournissent de l'argent à plein temps, vous ne devez pas prendre de nouveaux projets. Mais vous comprendrez que la direction essaiera toujours de vous intimider.
Si vous êtes en effet précieux pour l'entreprise, vous gagnerez un pouvoir de négociation. Vous pouvez leur demander d'embaucher plus de personnes, d'obtenir moins de nouveaux projets, de réduire la charge de maintenance ou d'augmenter votre salaire.
Comme je ne peux pas encore commenter parce que je suis un rôdeur sur ce site Stack Exchange, je vais simplement ajouter des informations ici.
Puisque vous débutez, votre salaire ne sera pas exceptionnel à moins que vous ne travailliez pour une grande entreprise comme Microsoft, Amazon ou quelque chose de similaire. Mais ça ne devrait pas être celle d'un épicier! Ne supportez pas cela longtemps, acquérez de l'expérience en faisant ce que vous faites et passez à autre chose quand une meilleure opportunité se présente.
Pour un concert d'entrée de gamme, c'est un peu normal. Votre charge de travail est trop élevée, mais le type de travail est attendu. Pour devenir un meilleur développeur, vous devez apprendre des erreurs des autres. Plus vous voyez, mieux vous devenez. Mais cela implique que vous cherchez des choses à apprendre, pas des mauvaises habitudes ...
Le rapport entre la maintenance et les travaux du projet devrait évoluer dans le temps. Si ce n'est pas le cas, cela signifie que l'entreprise pour laquelle vous travaillez ne sait 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 pour savoir où vous aimeriez être, en termes de salaire et d'attentes professionnelles, et déplacez-vous en conséquence.
4) Si vous n'êtes pas satisfait, partez! La vie est trop courte pour faire face à des gens stupides.
Bonne chance.
Vous commencez à utiliser un outil de suivi des problèmes pour garder une trace de votre liste de tâches.
Cela vous aidera non seulement à garder une trace de ce qui est essentiel, mais cela aidera 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 démissionnez et que votre remplaçant prend maintenant votre charge de travail), cela vous aidera à gérer la charge de travail, et vous pourrez éviter de marcher les uns sur les autres.
D'après mon expérience, le monde académique ou les 6 à 12 premiers mois d'une start-up axée sur la technologie sont les deux seuls domaines fiables où vous rencontrerez une véritable ardoise vierge. Ils supportent tous deux leurs propres coûts, mais si vous aimez coder et êtes souvent horrifié par la qualité du code que vous découvrez dans la nature, vous devriez commencer à orienter votre carrière dans l'une de ces directions.
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 consacré à passer au crible de telles demandes que vous n'avez pas le pouvoir de sanctionner? Ou faites-vous simplement des changements chaque fois qu'un gestionnaire vous le demande?
Il me semble que votre première escale est de tout mettre sur le bureau de votre manager. Personne ne devrait venir directement vers vous. Les problèmes doivent venir de quiconque travaille dans ce domaine - généralement une équipe d'assistance. 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 devraient être chiffrés et facturés (frais de transfert) dans toute entreprise qui se classerait comme "de taille moyenne", et cela semble être contourné (pas étonnant qu'ils vous inondent - vous êtes comme la salope au bal).
Il devrait y avoir une procédure de demande appropriée pour soulever des problèmes et modifier les demandes. Le support/maintenance consiste à corriger les bogues et les problèmes (qui correspondent à la spécification d'origine, mais échouent en raison 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 n'offre rien de tout cela et s'attend à ce que vous fassiez face à cette myriade de demandes aléatoires et que vous soyez responsable, alors sérieusement, vous devez envisager de passer à autre chose. Le salaire est toujours médiocre au fond - dans mon premier emploi en programmation (il y a près de 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!). Dans les 2 ans suivant 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 des éperons, apprenez votre métier et quittez le navire dans un environnement plus chaud.
La réponse est d'essayer de l'expliquer en termes compréhensibles;
- C'est comme des changements d'huile. Ils ne sont pas urgents ... mais doivent être effectués régulièrement néanmoins
- Peignez par-dessus Rust et ça aura fière allure. Jusqu'à ce que ça saigne
- construire un nouveau bureau de toit-terrasse sans renforcer les supports. Cela fonctionnera peut-être pendant un certain temps. Ensuite, cela s'effondrera et blessera les gens et vous serez responsable.
- la climatisation est super. Une unité de fenêtre est idéale pour une ou deux pièces. Essayer de mettre 146 climatiseurs de fenêtre dans un immeuble et vous aurez ... des problèmes.
- Enseigner à 5 enfants, c'est bien. 10 n'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 O YOU VOUS OBTENEZ UNE OFFRE SUR L'ÉCRITURE, pas le lendemain! Une fois que vous AVEZ un nouvel emploi, partez avec un avis ZÉRO. Littéralement, ne venez pas ce jour-là. Mais assurez-vous d'avoir un collègue ou deux 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 DE GAUCHE EN 6 MOIS SANS TRAVAIL. Il a au moins fait une déclaration et a donné une fois à la personne qui quittait une bonne chance de dire: `` Ouais, gentil, dis-tu tous les jours, mais tu en es tellement plein, je ne te donne même pas la satisfaction de mon avis.
Enfin, sachez que cette affaire était le NORM et la norme il y a 20 ans avant que l'agile, le tdd, le bdd et le refactoring ne deviennent plus que la norme. Vous pouvez parler avec des personnes âgées qui répondent immédiatement "eh bien, je l'ai fait moi-même et cela a bien fonctionné, bla, bla, bla." Eh bien, certains chevaux et voitures ont bien fonctionné il y a 150 ans. Dans les domaines technologiques, les techniques d'il y a 20 ans sont aussi obsolètes que le transport d'il y a 150 ans. S'ils rejettent cette amende. Sachez simplement qu'ils n'embaucheront jamais de développeurs de technologies actuels décents qui resteront. Ils obtiendront le pire des pires et cela nuira terriblement à leur entreprise. S'ils dépendent de la technologie et ne peuvent pas s'adapter, ils échoueront et, finalement, cela pourrait être la meilleure récompense pour vous. C'est juste que cela peut prendre un certain temps, car les organisations dysfonctionnelles peuvent durer longtemps.
La seule façon de briser cette chaîne est de développer de nouvelles infrastructures conçues pour la flexibilité et testées en unité complète + intégration.
Si vous parvenez à vendre cela à la direction (signez d'autres développeurs et gestionnaires sur le concept lors de réunions 1: 1), vous pouvez lentement atteindre un état où la plupart du code des applications se trouve dans l'infrastructure et il est facile de étendre et maintenir, tandis 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 après un certain temps (peut prendre quelques années) de remplacer des applications entières.
À long terme, il peut réduire considérablement le temps de développement de nouvelles applications et le temps de maintenance des futures applications existantes.
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). 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 qui s'occupe de ces problèmes (en fonction de vos définitions et de votre conception) et faites appel à de nouveaux développeurs pour maintenir les anciennes choses pendant que vous les aidez si nécessaire (jusqu'à 10-20% des le temps). Si la direction accepte l'idée, vous pouvez demander à renégocier vos conditions. Soyez prêt à trouver un autre emploi s'ils refusent. (N'oubliez pas, votre travail nécessite des compétences, des connaissances et de l'expérience, vous n'êtes pas aussi facile à remplacer qu'ils vous le font croire.)
Peut-être êtes-vous en mesure d'aller voir un manager et de lui dire: "Ecoutez, 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 cela. Honnêtement, et sans intention de vous offenser, je vais sortir de cette pièce avec ceci soit fixe, soit 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 soit correct? "
Il semble que votre gestion ne vous respecte pas fondamentalement ou ne comprenne pas votre charge de travail.
Vous ne devez pas implémenter toutes les demandes de fonctionnalités reçues. Votre gestionnaire doit agir comme un tampon entre vous et les demandes entrantes (sauf peut-être la plus simple des demandes d'arrêt/correction). Ensuite, il ou elle devrait s'asseoir avec vous et déterminer la faisabilité et la priorité de toute demande approuvée.
De plus, vous devriez gagner probablement 2x (au moins) ce qu'ils vous paient.
Il semble qu'ils aient probablement vraiment besoin d'au moins 1 développeur de plus pour travailler à vos côtés, mais avec ce qu'ils vous paient, cela semble assez improbable.
S'ils ne sont pas disposés à vous payer adéquatement ou à vous aider à gérer votre charge de travail, je chercherais un nouvel emploi. Vous voulez travailler quelque part où vous faites partie d'une équipe, et où votre direction travaille avec vous pour mener à bien vos projets. Descendez de ce navire en perdition dès que vous le pouvez.
Être un héros dans une équipe d'un seul ne fera que vous épuiser.
Je ne suis qu'un étudiant (encore) mais c'est assez normal (d'après mon expérience de stage). C'est ce que vous obtenez lorsque vous travaillez dans le support et les applications Web.
Je vous conseille de comprendre ce que veut le client (manager) avant de commencer le codage. Cela pourrait être délicat car parfois ils ne le savent pas eux-mêmes, alors travaillez avec eux jusqu'à ce qu'ils soient d'accord sur quelque chose. Assurez-vous que vous êtes tous les deux d'accord sur la solution finale avant de la coder.
De plus, si vous êtes un responsable, vous pouvez à peu près tout changer dans le code - assurez-vous simplement qu'il ne change pas le comportement ou n'introduit pas de bogues. Je m'attends à ce que les gestionnaires ne vous "permettent" pas de changer quoi que ce soit car ils sont habitués et satisfaits de la façon dont cela se passe maintenant et 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 conseille de faire savoir aux gens que vous êtes débordé de travail 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 ils pourraient embaucher plus de personnes. Il n'y a pas d'autre moyen pour eux de savoir que le travail est trop pour une seule personne.
Il s'agit d'un problème de gestion de projet. Utilisez une sorte de gestion de projet pour décider de ce qui est prioritaire sur lequel travailler.
a) Vous avez besoin d'un arriéré d'articles pour travailler. Vous mettez votre plan d'amélioration du code dans le backlog.
b) Tous les bugs vont dans le backlog
c) L'arriéré est priorisé.
d) Vous faites tout cela par ordre de priorité.
Les bogues peuvent très bien être une priorité plus élevée, mais si une fois que vous corrigez tout ce que vous avez des cycles à dépenser sur de nouvelles fonctionnalités ou sur la refonte du design.
Il est plus simple de refactoriser les améliorations de manière incrémentielle, car vous passez les sections qui ont des problèmes/bugs à corriger. Ensuite, vous pouvez dire à la direction: "J'ai dû réparer A, mais B était fondamentalement cassé et j'ai dû faire la solution C pour tout réparer afin que D soit plus facile/moins cher à l'avenir" Où A = le bogue, B = le anti-motif, C = solution, D = gains futurs
Si vous ne pouvez pas justifier le travail comme un investissement qui en vaut la peine, les gens d'affaires ne l'accepteront jamais.
C'est comme d'habitude. Vous serez exploité tant que vous y travaillerez, semble-t-il. Il est dans l'intérêt de l'entreprise de continuer à utiliser ce modèle plutôt que de vous faire plaisir 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 seul homme, ils font certainement confiance à vous. Pourquoi changeraient-ils?
La bonne nouvelle dans tout cela, c'est que vous êtes un VIP pour eux même s'ils ne le savent pas. Ce que je suggère de faire est d'aligner plus d'opportunités avant de sauter du navire puis de les saisir par les boules et exiger un salaire plus élevé. Sinon passer à une meilleure opportunité. À mon avis, vous devriez trouver un travail plus excitant bientôt. Visez aussi haut que possible. Une fois que vous arrivez dans une boutique de développeur, vous serez beaucoup plus heureux comme Google ou une startup amusante où il existe une culture de développeur collaboratif où vous vous sentirez vraiment heureux.
Ce que j'ai fait personnellement, c'était d'utiliser une organisation d'entrepreneurs en chasseurs de têtes et j'ai rapidement acquis de nombreuses expériences formidables, passant de l'une à l'autre tout en conservant un emploi stable chez mon entrepreneur. Il vous empêche de vous ennuyer et vous met au défi. Finalement, pendant mon temps libre, j'ai créé une petite entreprise qui s'est transformée en véritable entreprise, puis j'ai quitté le navire pour faire du travail à contrat.