Existe-t-il un moyen d’accélérer la résolution des bugs? Je viens de recevoir un avertissement de mon patron [fermé]

Mon patron vient de me dire que je recevrai une évaluation de performance négative lundi. Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bugs est si bas.

J'adore programmer et résoudre des problèmes, mais je trouve mon travail très difficile.

En fait, je suis programmeur depuis environ 10 ans. Mais il s’agit de mon premier emploi multithreading sous Linux intégré. Je suis ici depuis 2 ans et il est évident pour tout le monde que je lutte toujours. Et je pense que je suis devenu tellement démoralisé et que je me sens tellement marginalisé que j'ai perdu beaucoup de feu que j'avais au début de mon travail.

Quelqu'un a-t-il déjà été dans une situation similaire et comment allez-vous augmenter votre taux de correction de bugs?

Mise à jour: j'ai eu l'examen. J'ai suivi un programme de développement des employés de 3 mois (du type mentionné par Dunk). Je ne sais pas si je peux changer cela. Mais même si je dois passer à autre chose, j'ai beaucoup appris de cette expérience.

Une autre mise à jour

Cela fait maintenant environ 6 semaines depuis le premier examen. Mon conseil à quiconque est confronté à la même situation est d'être assez humble pour accepter les critiques et apprendre de vos erreurs. Et pour ne pas avoir peur de paraître stupide. Poser des charges et des charges de questions. Faites savoir aux gens que vous essayez d'apprendre et continuez à demander jusqu'à ce que vous compreniez. Mais préparez-vous à ce que cela ne fonctionne pas. Je construis un portefeuille de code ... en plus de donner le meilleur de moi-même.

Encore une mise à jour

J'hésite à le mentionner ici, car je crains de ne pas pouvoir renvoyer les futurs employeurs vers mon profil de flux de données superposés. travail il y a quelques semaines. Je suis en train de mettre à jour toutes les compétences dont j'ai besoin - j'ai beaucoup profité des conseils donnés ici.

Beaucoup de réponses ont remis en question les méthodes / tactiques / métriques / etc. de votre patron. Mais ce n'est pas le sujet. Peut-être que vous êtes lent. Chaque salle de développeurs doit en avoir une qui est plus lente que les autres, non? (C'est juste la théorie des ensembles.) Alors supposons que c'est vous. La réponse est: pourquoi es-tu lent? (Clairement, c’est la question à laquelle vous devez répondre avant de pouvoir résoudre votre question sur la manière d’accélérer les choses.)

Il pourrait y avoir toutes sortes de raisons, mais voici quelques explications possibles à considérer:

1. Vous êtes moins intelligent qu'eux . C'est possible, non? ( Des études ont montré que nous TOUS sommes moins populaires , moins intéressant , et (il suivrions) moins intelligents que nos amis.) Alors , vous êtes peut - être juste lent cerveau. Là encore, dans votre cas, je pense que cela est peu probable. Un rapide coup d'œil sur votre profil StackOverflow montre que vous avez toujours posé des questions intelligentes sur un large éventail de sujets. Donc, vous êtes évidemment un penseur et probablement un bon penseur.

2. Vous êtes trop mince. Ce même profil SO indique que vos questions couvrent une très large gamme de technologies au cours de ces 2 dernières années (graphisme, Web, python, c ++, c, linux, embarqué, threads, sockets, etc.). Personnellement, je sais que lorsque je me suis retrouvé dans la situation de vouloir (ou de vouloir) me plonger dans une multitude de flux différents, je me suis retrouvé à nager très rapidement (ou plutôt très lentement ). Peut-être que ce dont vous avez vraiment besoin ici, c'est FOCUS . Et peut-être une bonne dose de priorisation . Y a-t-il un moyen de reléguer les pots moins importants au second plan et de chauffer davantage le plat principal?

3. Tu ne t'amuses pas. Lorsque le feu s’éteint, la machine à vapeur est destinée à ralentir. Vous avez admis dans votre message que votre moral a beaucoup souffert ces derniers temps. Malheureusement, vous avez été englouti dans le vortex des harmoniques négatives qui s’auto-renforcent - une force qui peut détruire les ponts . C'est une spirale bien connue: tâche difficile -> stress -> délai dépassé -> plus de stress -> mécanisme d'adaptation médiocre -> plus de stress -> procrastination -> plus de délais manqués -> critiques / commérages (réels ou imaginaires) - > encore plus de stress. Vous obtenez l'image. Cela mène rarement nulle part utile. Tirez une leçon de mes jours de rafting en eaux vives: lorsque vous êtes aspiré par un courant circulant à l'arrière d'un rapide de classe 4, votre gilet de sauvetage nevous ramener à la surface. La meilleure stratégie (bien que non intuitive) consiste à trouver le fond de la rivière et à sortir du riptide. Je vous conseille donc de: trouver un terrain , un mec (amis, église, nouvelles habitudes saines, etc.) et en profiter pour vous sortir du bain à remous.

4. Vous n'êtes pas dans votre zone. Michael Jordan a fait un joueur de baseball assez boiteux. (OK, il était toujours meilleur que moi, mais certainement un joueur mineur.) Peut-être que "multithreading Linux intégré" n'est tout simplement pas votre travail. Mais le développement de logiciels est un domaine extrêmement vaste (comme vous le savez bien; cf. n ° 2 ci-dessus). Votre entreprise est-elle suffisamment vaste pour que vous puissiez trouver un autre créneau? Dans mon dernier emploi, j'ai été embauché en tant que développeur SW intégré. (Je n'avais aucune expérience dans ce domaine, mais je leur ai dit que j'étais un "apprenant rapide".) J'ai rapidement sombré comme une pierre. Mais je continuais à travailler dur et continué à chercher des problèmes que j'ai faitsavoir comment résoudre pour eux. En fin de compte, j'ai été en mesure de migrer progressivement vers de nouvelles responsabilités au sein desquelles je pouvais briller et pour lesquelles j'ai finalement reçu des éloges considérables. Alors peut-être avez-vous besoin de changer de marque.

Le fait est que si vous êtes lent, il y a une raison. Mais, hé - vous êtes un ingénieur en logiciel, mec! Déboguez-vous!

Votre patron a peut-être raison: vous êtes peut-être sous-performant (plus à ce sujet dans une minute). Mais ce n’est peut-être pas uniquement votre niveau de compétence qui est à blâmer. Je ne pense pas qu'il serait raisonnable de suggérer que des forces indépendantes de votre volonté vous causent du stress, ce qui a un effet négatif sur votre performance.

Examinons quelques-unes des raisons pour lesquelles votre patron pourrait maintenant en parler:

Culture et politique

Il se peut que des forces incontrôlables obligent votre chef à exprimer maintenant ses préoccupations. Il est important de comprendre le système dans lequel vous travaillez. Votre travail consiste à donner à votre patron une belle apparence. La seule façon de le faire est de comprendre les pressions qu’il subit.

Aptitude

Il est possible que cette capacité ne soit pas à la hauteur, comme vous le dites ouvertement. Voici ce que je ferais dans cette situation:

Obtenez des commentaires spécifiques de votre patron sur la manière dont il mesure la performance. Ne fermez-vous pas autant de bugs que la personne X? Y at-il un nombre défini de bugs que vous devriez résoudre? Si vous travaillez seul, vous devez vous assurer que les personnes qui mesurent votre performance le mesurent équitablement et non en fonction d'une idée préconçue.

Si votre performance est lente et basée sur un écart réel, identifiez-le et établissez un plan détaillé avec votre supérieur en vue de le combler.

Cet avis est également une bonne occasion d’évoquer le fait que vous n’êtes pas heureux. C'est bien que vous ayez constaté que vous n'aimiez pas ce travail. Mais comprendre pourquoi. Quelle partie de votre travail aimez-vous et qu'est-ce que vous ne faites pas? Il se peut que ce travail ne vous concerne pas ...

Certains environnements de travail sont impraticables. J'ai vu des environnements dans lesquels personne ne pouvait survivre (à l'exception de ceux qui étaient au début) parce qu'il y avait tellement de choses sans papiers et que les questions étaient découragées avec véhémence.

Vous devez vraiment être honnête avec vous-même en ce qui concerne les attentes et les ressources fournies pour vous aider à les satisfaire. Le problème peut ne pas être toi.

Vous avez mentionné que des personnes exerçant des fonctions similaires aux vôtres n’avaient, selon moi, pas de difficultés, mais qu’elles avaient plus de 5 ans d’expérience. Comment vous sentez-vous par rapport à vos pairs? Sont-ils des rock stars qui vous surclassent totalement (à cet égard) ou sont-ils tout simplement comme vous? Peut-être ont-ils appris à connaître le système à une époque où il était plus simple ... Vous avez parlé de 8 années d’expérience en programmation avant de travailler dans ce domaine. Comment vous y êtes vous rendu? Si vous avez bien fait, cela devrait vous dire quelque chose.

La partie qui m'a frappé est le fait que vous vous décrivez comme étant dans le noir par rapport à tous les insectes qui se présentent à vous. Il se peut que la base de codes soit si vaste et si inexploitée que les attentes ne soient pas raisonnables.

Avoir réussi dans la mesure de vos moyens signifie avoir fait quelque chose de bien et avoir quelque chose pour vous.

En bout de ligne, je pense que vous devez vous sentir bien dans votre peau et dans ce que vous faites. Et si cela signifie passer à autre chose, qu’il en soit ainsi.

Mieux vaut partir que d’avoir un emploi qui ruine votre vie.

Tout d’abord, remarque: cette réponse ne peut s’appliquer qu’à certaines régions où il est illégal de licencier un employé sans indemnité de licenciement. Cela dit...

Cela pourrait être un cas de licenciement constructif et qui est illégal.

La tactique consiste à démoraliser et à réduire l'estime de soi d'un employé jusqu'à ce qu'il quitte son emploi. C'est un moyen pour l'entreprise d'économiser de l'argent en évitant de payer une indemnité de licenciement ou en résolvant le problème de devoir confronter un employé et le congédier.

Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bugs est si bas.

Cette faute est très ambiguë. Il est impossible pour aucun des partis de prétendre que l'autre est mauvais. Vous avez pris un mois pour corriger un bogue. Et alors! Cela vous place dans une position défensive, car vous devez présenter des faits à l'appui de votre affirmation selon laquelle un mois était requis. Compte tenu de vos compétences, de votre expérience et de vos connaissances actuelles. En tant qu'employeur, c'est à l'employeur de gérer le temps et les efforts de ses employés. L'employeur doit être la personne qui court le risque associé à la correction des bugs. Pas l'employé. Il a toujours eu le choix d'attribuer le bogue à quelqu'un d'autre.

Si vous êtes un entrepreneur et que votre contrat stipule que vous serez responsable de la correction des bogues, la situation est complètement différente.

L'employeur a-t-il tort de se plaindre que vous prenez trop de temps? Absolument pas, mais il ne peut pas vous en rendre responsable, et il ne peut pas vous virer pour cela. Il peut vous dire "Nous n'avons plus de bogues qui nécessitent vos compétences et vous êtes mis en congé", mais ils doivent vous avertir dès qu'un nouveau problème survient que vous pouvez résoudre. Sinon, ils doivent se terminer avec indemnité. Ce qu'il ne peut pas faire, c'est vous donner un travail que vous ne pouvez pas gérer, puis vous en plaindre. Je pense que c'est illégal.

J'adore programmer et résoudre des problèmes, mais je trouve mon travail très difficile.

Il y a une grande différence entre accepter un emploi que vous trouvez difficile et donner à votre employeur un travail trop difficile. Si vous estimez que les tâches qui vous sont confiées ont été accomplies pour vous décourager de faire carrière dans l'entreprise, cela pourrait être illégal.

En fait, je suis programmeur depuis environ 10 ans. Mais il s’agit de mon premier emploi multithreading sous Linux intégré. Je suis ici depuis 2 ans et il est évident pour tout le monde que je lutte toujours.

C'est pourquoi je pense que vous vous êtes retrouvé au milieu d'un congédiement constructif. Ils ne sont pas heureux avec vous, alors ils vous en chargent jusqu'à votre départ.

Et je pense que je suis devenu tellement démoralisé et que je me sens tellement marginalisé que j'ai perdu beaucoup de feu que j'avais au début de mon travail.

Un employeur est responsable de fournir un environnement de travail positif et sûr. Sans plus d'informations (probablement personnelles), il est difficile pour les étrangers de dire ce qui se passe réellement ici. Demandez à un avocat en droit du travail pour une consultation gratuite. Ils pourront vous dire si vous êtes en train de jouer.

Références

Je ne suis pas avocat, mais Google a écrit quelques documents sur le licenciement constructif qui méritent d'être lus avant que vous n'entamiez votre commentaire lundi. Le point essentiel ici est de veiller à une réduction de salaire, à l’humiliation et à des changements soudains dans votre carrière au sein de la société.

Faits pertinents à surveiller:

• Défaut d'aider correctement un employé dans des conditions de travail difficiles
• Discipline excessive exercée sur un employé Imposant un changement de lieu de travail des employés à bref délai
• Imposition d'une réduction de salaire

Questions juridiques: licenciement abusif

Motifs de demande de congédiement déguisé

Wikipédia

éléments d'un congédiement déguisé

Peut-être êtes-vous comparé à l'un des programmeurs d'origine d'un projet. Je sais qu'en tant que développeur original de l'un des projets sur lesquels je travaille, j'ai un avantage considérable en corrigeant des bugs. Je ne pense pas que ce soit à cause d'un manque de documentation, c'est simplement que je peux intuitivement sauter aux problèmes potentiels car mon cerveau connaît tout le code.

Si vous êtes comparés à cela, vous ne pourrez tout simplement pas vous mesurer. Il vous faudra toujours plus de temps pour vous mettre au fait du projet et vous ne saurez pas où se trouvent tous les points d'interaction potentiels.

J'ai lu votre commentaire sur le fait de ne pas découvrir les outils et astuces que d'autres programmeurs utilisent pour résoudre des problèmes. Peut-être que pour votre prochaine correction de bogue, vous devez essayer la programmation en binôme. Cela peut être incroyablement utile. À tour de rôle, conduisez le clavier. Parlez beaucoup .

Vous pouvez utiliser un bloc-notes ou un tableau blanc pour tracer les chemins des fonctions, les threads et les durées de vie, et indiquer les endroits où vous observez différents comportements et où vous pouvez insérer de nouvelles sondes.

La résolution de ce type de problèmes de threading de bas niveau peut être très difficile et j'ai beaucoup de sympathie pour vous. J'ai dû analyser plusieurs gigaoctets de fichiers journaux avant de détecter un problème de deux lignes. Et tu sais quoi? Je l'ai observé pendant des jours avant d'avoir demandé l'aide d'un ingénieur junior qui avait été stagiaire l'année précédente. Il a proposé une nouvelle approche et a repéré le problème en une heure. Donc, après avoir passé du temps dans un bogue, jetez un œil neuf sur celui-ci. Cela peut aider beaucoup!

L'un des dysfonctionnements de gestion les plus courants dans cette industrie est la non-compréhension du fait que le débogage est intrinsèquement difficile . J'ai près de 20 ans d'expérience et je encore avoir régulièrement passer une semaine à trouver l'erreur d' une ligne qui rend le plantage du programme une fois sur cinquante. Et puis, si mon responsable ne comprend pas ces choses, il me dérange d'avoir pris une semaine pour changer une ligne de code.

Que peux-tu y faire?

• Prenez des notes pendant que vous déboguez. Ayez toujours une fenêtre d'éditeur ouverte et écrivez votre flux de conscience. Cela n'a pas de sens pour personne d'autre que vous. Vous constaterez peut-être que cela vous aide à déboguer plus rapidement, mais cela signifie également que vous avez quelque chose de concret à démontrer pour démontrer que vous n'avez pas joué à Nethack toute la semaine.

• Comparez les notes avec tous vos collègues. Combien de temps leur faut-il généralement pour réparer les bugs? Est-ce que leurs insectes restent fixes? Combien de fois changent-ils une petite chose et se retrouvent-ils ensevelis sous un tas de conséquences en cascade? Les réponses à ces questions vous permettront de savoir si vous êtes vraiment en difficulté par rapport au reste du ministère.

• Faites vous des amis avec les gens de QA et les gens de support client. Ce sont eux qui ont la meilleure idée de l’ importance des bugs. Souvent, cela a peu ou pas de corrélation avec la difficulté des bogues, vous pouvez donc jouer un peu au système et essayer d’obtenir tous les bogues de haute importance et de faible difficulté. (Ce n'est pas vraiment tricher. Une équipe bien organisée s'attaque toujours en premier à ces bugs.)

• Si votre patron ne vous a pas donné de retour d'information suffisant sur votre performance pendant deux années consécutives, c'est un problème que vous devez d'abord aborder lors de cette évaluation de performance, puis, lorsque vous obtenez une vue d'ensemble, relancer avec le patron de votre patron. Soyez poli, et surtout ne leur laissez pas voir à quel point vous êtes en colère, mais recevez des critiques spécifiques par écrit.

Si vous aimez programmer et résoudre des problèmes, vous pouvez vous demander si vous appliquez bien ce que vous apprenez à d'autres domaines. Est-ce que l'un des quelque 12 derniers bogues que vous avez corrigés est suffisamment similaire pour que ce qui vous a aidé à corriger l'un soit utile sur un autre? Cela fait partie de l'examen de ce que vous avez fait et du temps qu'il a fallu pour y parvenir. Juste une idée à considérer.

Deuxièmement, je regarderais comment tu fais ton travail. Êtes-vous régulièrement interrompu et lorsque vous essayez de corriger le bogue A, on vous dit que les bogues B et C ont une priorité plus élevée? Réfléchissez bien aux types de changements dans votre travail qui pourraient vous aider, car cela fait probablement partie de ce que votre patron voudra savoir.

Certains lieux de travail m'ont dit qu'ils n'aimaient pas le temps qu'il me fallait pour accomplir certains de mes travaux. Bien sûr, c’étaient les endroits où, si j’avais une chose à faire, 5 nouvelles choses seraient larguées sur mes genoux et il était donc facile de se sentir dépassé. Bien que je puisse ne plus travailler là-bas, je n'avais pas de bonne solution pour attirer mon attention sur quelques points afin que je ne me sente pas comme si j'essayais de maîtriser 1 000 éléments en même temps. Si je peux savoir quelques choses clés à faire et comment mon travail sera jugé, alors je suis bien meilleur que si j'ai une liste de choses à faire qui est longue et que personne ne semble s'en soucier si je reçois des parties de fait. Ainsi, il se peut que cela comporte un élément culturel au sein de l’organisation, même si je ferais bien attention de ne pas demander que les choses changent ici.

Après deux ans de travail, tout le monde (vous, votre patron, vos collègues) devrait savoir où vous vous situez. C'est-à-dire que vous ne devriez jamais découvrir que vous vous êtes mal débrouillé une fois par an; un environnement de travail idéal fournira une rétroaction continue.

Quoi qu'il en soit, en ce qui concerne la façon de déboguer du code multithread: vous n'avez pas indiqué s'il s'agissait de votre code ou de celui de quelqu'un d'autre. De nouveaux débogueurs et analyseurs statiques peuvent gérer la concurrence. Mais vraiment, sachant que les modèles seront votre meilleur pari puisque vous saurez quoi rechercher.

Si vous comprenez comment les sections critiques, les conditions de course et les blocages fonctionnent, vous serez alors mieux placé pour repérer les imprévus. Si vous voyez "communication" entre deux threads sans variable de condition, ou si les ressources sont mutées sans ordre particulier, ou si une variable locale est déclarée staticsans raison apparente, alors vous avez un bug potentiel! Alors apprenez les meilleures pratiques de votre domaine et vous serez mieux à même de juger lorsque quelque chose sort de l'ordinaire.

Ne luttez pas seul sauf si vous devez le faire. Recruter des collègues. Demandez-leur d'aider à chasser les insectes. Interrogez-les sur leurs processus de réflexion et leurs outils. Peut-être en parler dans votre critique dans le cadre de votre plan d'amélioration. Si tout le monde autour de vous s'en sort mieux avec ce système , peut-être savent-ils quelque chose de spécifique?

Mon patron vient de me dire que je recevrai une évaluation de performance négative lundi. Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bugs est si bas.

Sachez que dans toute entreprise non dysfonctionnelle, rien ne se passe avec cette commande. Si votre patron est préoccupé par vos performances, il doit définir des objectifs à court terme et discuter de vos résultats pour déterminer où se situe le problème.

Au lieu de cela, il décide de vous donner une critique négative, puis découvrez pourquoi. On dirait qu'il ne veut pas s'impliquer dans le problème et il veut juste des résultats dans le tableau.

Ne cherchez pas à résoudre les bugs plus rapidement. Vise à évaluer tes propres capacités, vérifie le fonctionnement de tes collègues, comment ils savent ce qu’ils savent, et sache que cette entreprise n’est pas idéale.

En ce qui concerne les astuces pratiques, j'utilise des extraits de code et mon propre mediawiki pour prendre des notes. Je pense toujours aux livres à lire ensuite et aux instructions à suivre pour continuer mon apprentissage. L'apprentissage est la voie vers un meilleur travail et une vie plus heureuse.

Tout d'abord, un coup de pouce de confiance:

Pourquoi souffrir? Vous pouvez facilement trouver un emploi où ils penseront que vous êtes "dieu" simplement parce que vous pouvez faire n'importe quoi avec Linux, quel que soit votre taux de correction de bugs.

Quoi qu'il en soit, il est impossible de fixer une limite de temps pour la recherche d'un bogue. La chasse aux insectes est une compétence, sans aucun doute, et son efficacité est très précieuse.

Il se peut que vous manquiez un truc de base que d'autres connaissent, ce qui vous ralentit.

Par exemple, si vous et moi travaillons sur un middleware Linux et que j'utilise Valgrind pour résoudre les problèmes de corruption de mémoire et de concurrence, alors que vous ne vous fiez qu'à gdb et printf, je vais probablement vous botter le cul, même si tu es plus intelligent que moi.

En outre, comment est votre compréhension de la concurrence ? Si vous développez depuis dix ans, mais que la plupart de ces expériences ne concernaient pas du code multithread, cela pourrait poser problème.

Vous devriez étudier le multithreading en détail: il ne suffit pas de savoir utiliser les API, mais de le "comprendre" à un niveau plus profond. Si vous faites de la programmation multithread, vous devriez être ce développeur qui peut consulter une base de code à un kilomètre et voir des scénarios de conditions de course, de blocages, d'inversions de priorité, de famine ...

Récemment, j'ai lu le livre Working efficacement with Legacy Code , qui m'a permis de gagner beaucoup de confiance en moi lorsque je traite un problème dans n'importe quelle base de code.

Si le code avec lequel vous travaillez est loin d'être parfait, je pense que ce livre pourrait vous être utile. J'ai souvent constaté que pour corriger un bogue, je devais d'abord refactoriser le code environnant afin de le comprendre , puis une fois que je comprenais le code, et si tout va bien, je pourrais le tester, le traquer et le résoudre le problème est moins une épreuve. (Parfois, je réécris même le code juste pour le comprendre, mais je reviens sur mes modifications pour réduire le risque d'introduction de nouveaux bogues. Ensuite, j'insère ma correction de bogue. Cette technique est basée sur une astuce du livre.)

Je pense que ma suggestion ne traite qu’une partie de votre problème, et de manière quelque peu indirecte, mais le livre mérite d’être lu quoi qu’il en soit, car travailler avec du code hérité est une fatalité pour tout développeur.

Demandez à votre supérieur quelle est votre vitesse de correction des bugs et quelle est la vitesse moyenne de l'équipe pour la correction des bugs. Plus important encore, demandez-lui comment la vitesse de correction des bugs est mesurée ...

Cette sorte de métrique n'est pas vraiment une métrique; si c'était le cas, ce serait encore plus peu fiable que LOC (bien que mesurant des trucs différents). Et sans une mesure appropriée, il n'y a aucune raison de vous accuser de rien.

Reconnaissez que vous travaillez AVEC des employeurs et / ou des clients, PAS pour eux. N'hésitez pas à le mentionner dans les interviews, juste pour mettre les choses au clair dès le début.

Vous êtes un professionnel avec beaucoup investi dans votre petite entreprise, à savoir vous-même.

Vous êtes disposé à travailler pendant qu’une union d’intérêts vous propulse chaque jour.

Si cette propulsion n'est pas là pendant un certain temps, passez à autre chose.

Vous perdez votre temps et votre énergie sur un petit employeur qui ne maintient pas votre intérêt / vos compétences à jour / vos missions à jour et / ou sur lesquelles vous pouvez travailler. C'est le travail de la direction. Autre que cela, ils sont purement frais généraux .....

Gardez votre passion, car c'est la clé.

J'ai vécu des situations similaires parce que j'avais peur de demander de l'aide. A en juger par ce que vous avez dit dans ce commentaire ...

"Mais ce qui est frustrant, c’est qu’il ya certains outils / trucs / astuces que je n’ai découverts qu’après y être restés un an et demi. On m’a déplacé d’équipe en équipe (je suppose parce que j’étais sous performant) et ces outils "cachés" de temps en temps ".

... vous avez peut-être eu le même problème que moi. Le débogage est autant un métier que l'écriture de code qui ne nécessite pas autant de débogage. Regarder d'autres développeurs travailler à travers un problème de débogage peut être très instructif. Demandez-leur de l'aide lorsque vous avez du mal à résoudre un problème. Surtout si vous couvrez un terrain que vous n'aviez pas auparavant. Et faites-le idéalement avant qu'il ne soit temps de paniquer, car vous ne faites rien.

Cela dit, je suis d’accord avec les commentaires selon lesquels la direction faisait quelque chose de mal. Si quelqu'un se débat avec quelque chose, il devrait obtenir de l'aide avant que le plaisir de l'examen négatif ne commence. Bon sang, si quelqu'un dans une équipe est en difficulté et ne reçoit jamais d'aide, je dirais que chaque membre de cette équipe fait quelque chose de mal (bien que cela puisse être une conséquence directe du fait que les gens surveillent leurs taux de correction de bugs de trop près).

Ce qui manque dans l'OP, c'est la mention d'un processus ou d'une méthode répétable qui est suivi pour résoudre les bogues.

Commencez par documenter le processus que vous suivez. Assurez-vous de documenter les objectifs de chaque étape du processus.

Vous pouvez définir le processus comme suit:

1. Assurez-vous de bien comprendre le problème qui est signalé.
2. Essayez de reproduire le problème.
3. Commencez à décomposer le problème en morceaux plus petits
4. Pensez aux causes possibles du problème.
5. Testez ces hypothèses

Il serait utile de savoir si les bogues existent depuis longtemps ou s'ils ont été introduits avec les modifications récentes. Si les bogues ont été introduits avec les modifications récentes, il peut être utile de réviser le code et / ou de simplement lire le code créé par les utilisateurs.

Je pense que si vous parvenez à définir clairement le problème, par exemple, "j’ai du mal à penser aux hypothèses à vérifier pour tenter de résoudre les bugs", vous pouvez obtenir des conseils plus ciblés.