Existe-t-il un moyen d'accélérer la résolution des bogues? Je viens de recevoir un avertissement de mon patron
Mon patron vient de me dire que je recevrai une évaluation des performances négative lundi. Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bogues est si bas.
J'adore programmer et résoudre des problèmes mais je trouve vraiment mon travail vraiment difficile.
En fait, je suis programmeur depuis environ 10 ans. Mais c'est mon premier travail Linux embarqué multithread - je suis ici depuis 2 ans et il est évident pour tout le monde que je continue de me battre. Et je pense que je suis devenu tellement démoralisé et me sens tellement marginalisé que j'ai perdu beaucoup de feu que j'avais au début du travail.
Quelqu'un a-t-il déjà été dans une situation similaire et comment allez-vous augmenter votre taux de correction de bogues?
Mise à jour: j'ai eu l'examen. J'ai été mis sur 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 continuer, j'ai beaucoup appris de cette expérience.
Une autre mise à jour
Cela fait maintenant environ 6 semaines depuis le premier examen. Mon conseil à toute personne confrontée à la même situation est d'être assez humble pour accepter les critiques et apprendre de ses erreurs. Et pour ne pas avoir peur d'avoir l'air stupide. Posez des tas de questions. Faites savoir aux gens que vous essayez d'apprendre et continuez de demander jusqu'à ce que vous compreniez. Mais préparez-vous à ce que cela ne fonctionne pas. Je suis en train de construire un portefeuille de code ... ainsi que de lui donner mon meilleur coup.
Encore une autre mise à jour
J'hésite à mettre cela ici, car je crains de ne pas pouvoir référer les futurs employeurs à mon profil stackoverflow ... Mais de toute façon, cela pourrait être intéressant pour quelqu'un qui lit cette question, mais j'ai en fait perdu mon il y a quelques semaines. Je suis en train de rafraîchir toutes les compétences dont j'ai besoin - j'ai beaucoup tiré parti des conseils donnés ici.
De nombreuses réponses ont remis en question les méthodes/tactiques/mesures/etc. de votre patron. Mais ce n'est pas le sujet. Vous êtes peut-être lent. Chaque salle de développeurs doit en avoir UN qui est plus lent que les autres, non? (C'est juste une théorie des ensembles.) Supposons donc que c'est vous. La réponse est: POURQUOI êtes-vous lent? (C'est clairement la question à laquelle vous devez répondre avant de pouvoir résoudre la question que vous avez posée sur la façon d'aller plus vite.)
Il peut y avoir toutes sortes de raisons, mais voici quelques explications possibles à considérer:
Vous êtes moins intelligent qu'eux . C'est possible, non? (Des études ont montré que nous [~ # ~] tous [~ # ~] sont moins populaires , moins intéressants =, et (il s'ensuivrait) moins intelligent que nos amis.) Alors peut-être que vous êtes juste un cerveau lent. Là encore, dans votre cas, je pense que cela est peu probable. Un rapide coup d'œil de votre profil StackOverflow montre que vous avez l'habitude de poser des questions intelligentes sur un large éventail de sujets. Vous êtes donc évidemment un penseur et probablement un bon dans ce domaine.
Vous êtes trop mince. Ce même SO profil de la vôtre montre 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 quand on m'a mis dans la situation d'avoir (ou de vouloir) me plonger dans un multitude de flux différents, je me retrouve à remonter le courant très rapidement (ou plutôt, vraiment lentement ). Peut-être que ce dont vous avez vraiment besoin ici est [ ~ # ~] focus [~ # ~] . Et peut-être une bonne dose de priorisation . Y a-t-il de toute façon vous pouvez reléguer les pots les moins importants à l'arrière brûleur et montez la chaleur sur le plat principal?
Vous ne vous amusez pas. Lorsque le feu s'éteint, la machine à vapeur est destinée à ralentir. Vous avez admis dans votre message que votre moral a subi un coup dur récemment. Malheureusement, vous avez été englouti dans le vortex aspirant des harmoniques négatives auto-renforçantes - une force qui peut détruire les ponts . C'est une spirale bien trop familière: tâche difficile -> stress -> échéance manquée -> plus de stress -> mauvais mécanisme d'adaptation -> plus de stress -> procrastination -> plus de délais manqués -> critique/commérages (réels ou imaginaires) - > encore plus de stress. Vous obtenez l'image. Cela mène rarement à un endroit utile. Prenez une leçon de mes jours en rafting: lorsque vous êtes aspiré sous l'eau par un courant circulant à l'arrière d'un rapide de classe 4, votre gilet de sauvetage ne sera PAS vous ramène à la surface. La meilleure stratégie (bien que non intuitive) est de trouver le fond de la rivière et de sortir du riptide. Donc, mon conseil est: trouvez du terrain , mec (amis, église, nouvelles habitudes saines, etc.) et profitez-en pour vous promener hors du bain à remous.
Vous n'êtes pas dans votre zone. Michael Jordan a fait un joueur de baseball assez boiteux. (OK, il était encore meilleur que moi, mais certainement un mineur). Peut-être que "Linux embarqué multithreading" n'est tout simplement pas votre concert. Mais le développement logiciel est un domaine extrêmement large (comme vous le savez bien; cf # 2 ci-dessus). Votre entreprise est-elle suffisamment large 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 coulé comme une pierre. Mais j'ai continué à travailler dur et à chercher des problèmes que je savais comment résoudre pour eux. Il s'est avéré que j'ai progressivement pu migrer vers de nouvelles responsabilités où je pouvais briller et pour lesquelles j'ai finalement reçu des éloges considérables. Alors peut-être que vous devez vous renommer.
Le fait est que si vous êtes lent, il y a une raison. Mais, hé - vous êtes un ingénieur logiciel, mec! Déboguez-vous!
Votre patron a peut-être raison: vous pouvez être "sous-performant" (plus à ce sujet dans une minute). Mais ce n'est peut-être pas seulement votre niveau de compétence qui est à blâmer. Je ne pense pas que ce serait une portée de suggérer que des forces indépendantes de votre volonté vous causent du stress, ce qui a un effet négatif sur vos performances.
Voyons quelques-unes des raisons pour lesquelles votre patron peut maintenant en parler:
Culture et politique
Certaines forces indépendantes de votre volonté peuvent obliger votre patron à exprimer maintenant son inquiétude. 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.
Capacité
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 commentaires spécifiques de votre patron sur la façon dont il mesure les performances. Ne fermez-vous pas autant de bugs que la personne X? Y a-t-il un nombre fixe de bogues que vous devriez résoudre? Si vous travaillez seul, vous devez vous assurer que les personnes qui mesurent votre performance la mesurent équitablement et ne sont pas basées sur une idée préconçue.
Si votre performance est lente et basée sur un écart réel, identifiez cet écart et préparez un plan détaillé avec votre patron dans le but de le combler.
Cet examen est également une bonne occasion de souligner le fait que vous n'êtes pas satisfait. C'est bien que vous ayez identifié que vous n'aimez pas ce travail. Mais comprenez pourquoi. Quelle partie de votre travail aimez-vous et qu'aimez-vous pas? Il se peut que ce travail ne soit pas pour vous ...
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 que tant de documents étaient sans papiers et que les questions étaient découragées avec tant de véhémence.
Vous devez vraiment être honnête avec vous-même concernant les attentes et les ressources fournies pour vous aider à les satisfaire. Le problème n'est peut-être pas vous.
Vous mentionnez qu'il y a des gens qui font un travail similaire au vôtre qui, je présume, n'ont pas de difficulté, mais qui ont plus de 5 ans d'expérience dans votre 2. Comment vous sentez-vous par rapport à vos pairs? Sont-ils des rockstars qui vous surclassent entièrement (à cet égard), ou sont-ils comme vous? Peut-être qu'ils ont juste appris à connaître le système quand il était plus simple ... Vous avez mentionné avoir 8 ans d'expérience en programmation avant cette ligne de travail. Comment as-tu fait là-bas? Si vous avez réussi, cela devrait vous dire quelque chose.
La partie qui m'a frappé est le peu où vous vous décrivez comme étant dans le noir par rapport à tous les bugs qui se présentent à vous. Il se pourrait que la base de code soit si vaste et inexplorée que les attentes ne soient pas raisonnables.
Pour que vous ayez réussi aussi loin que possible, cela signifie que vous avez fait quelque chose de bien et que vous avez quelque chose pour vous.
En fin de compte, je pense que vous devez vous sentir bien dans votre peau et dans ce que vous faites. Et si cela signifie aller de l'avant, qu'il en soit ainsi.
Mieux vaut continuer que d'avoir un emploi qui ruine votre vie.
Tout d'abord, notez: cette réponse ne peut s'appliquer qu'à certaines régions où il est illégal de licencier un employé sans indemnité de départ. 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é ou de résoudre le problème de confronter l'employé et de le licencier.
Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bogues est si bas.
Cette faute est très ambiguë. Il est impossible pour l'un ou l'autre des partis de prétendre que l'autre a tort. Vous avez mis un mois à 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 nécessaire. Compte tenu de vos compétences, expérience et connaissances actuelles en tant que facteurs. En tant qu'employeur, c'est le travail de 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 bogues. Pas l'employé. Il avait toujours le choix d'attribuer le bug à quelqu'un d'autre.
Si vous êtes un entrepreneur et que votre contrat indique la responsabilité de la correction des bogues, alors c'est une tout autre histoire.
Est-ce mal pour l'employeur de se plaindre que vous prenez trop de temps? Absolument pas, mais il ne peut pas vous en tenir 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 dire dès qu'un nouveau problème survient que vous pouvez corriger. Sinon, ils doivent se terminer avec une indemnité de départ. Ce qu'il ne peut pas faire, c'est vous donner du 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 vraiment mon travail vraiment difficile.
Il y a une grande différence entre prendre un travail que vous trouvez difficile et votre employeur vous donner un travail trop dur. Si vous pensez que les tâches qui vous ont été confiées ont été effectuées pour vous décourager de faire carrière dans l'entreprise, cela peut être illégal.
En fait, je suis programmeur depuis environ 10 ans. Mais c'est mon premier travail Linux embarqué multithread - je suis ici depuis 2 ans et il est évident pour tout le monde que je continue de me battre.
C'est pourquoi je pense que vous vous êtes retrouvé au milieu d'un licenciement déguisé. Ils ne sont pas satisfaits de vous, alors ils vous empilent la merde jusqu'à votre départ.
Et je pense que je suis devenu tellement démoralisé et me sens tellement marginalisé que j'ai perdu beaucoup de feu que j'avais au début du travail.
Un employeur est responsable de fournir un environnement de travail sûr et positif. Sans plus d'informations (très probablement personnelles), il est difficile pour les étrangers de dire ce qui se passe vraiment ici. Demandez à un avocat du travail une consultation gratuite. Ils pourront vous dire si vous jouez.
Références
Je ne suis pas avocat, mais j'ai publié sur Google certains documents sur le thème du licenciement déguisé qui valent la peine d'être lus avant que vous ne soumettiez votre avis lundi. Le point principal ici est de faire attention à une réduction de salaire, à l'humiliation et à des changements soudains dans votre carrière dans l'entreprise.
Les faits pertinents font attention:
- Défaut de soutenir correctement un employé dans des conditions de travail difficiles
- Discipline excessive d'un employé Imposer un changement de lieu de travail des employés à court terme
- Imposition d'une réduction de traitement ou de salaire
Q&R juridique: licenciement déguisé
Vous êtes peut-être comparé à l'un des programmeurs d'origine d'un projet. Je sais qu'en tant que développeur d'origine de l'un des projets sur lesquels je travaille, j'ai un énorme avantage lorsque je corrige des bogues. Je ne pense pas que ce soit à cause du manque de documentation, c'est juste que je peux intuitivement sauter vers des problèmes potentiels parce que mon cerveau connaît tout le code.
Si vous êtes comparé à cela, alors vous n'allez pas vous mesurer. Cela vous prendra toujours plus de temps pour vous mettre au courant 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 les astuces que d'autres programmeurs utilisent pour résoudre les problèmes. Peut-être que pour votre prochaine correction de bug, vous devrez essayer la programmation par paires. Cela peut être extrêmement utile. Tournez le clavier à tour de rôle. Faites un beaucoup de parler.
Vous pouvez utiliser un bloc-notes ou un tableau blanc pour tracer les chemins de fonction, les threads et verrouiller les durées de vie, et marquer où vous observez les différents comportements et où vous pouvez insérer de nouvelles sondes.
Résoudre ces types 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 repérer un problème sur deux lignes. Et tu sais quoi? J'ai regardé cela pendant des jours avant de demander l'aide d'un ingénieur junior qui avait été stagiaire l'année précédente, et il a trouvé une nouvelle approche et a repéré le problème en une heure. Donc, après avoir mis du temps dans un bogue, jetez un œil nouveau sur lui. Ça peut aider beaucoup!
L'un des dysfonctionnements de gestion les plus courants dans cette industrie est de ne pas comprendre que le débogage est intrinsèquement difficile. J'ai près de 20 ans d'expérience et je encore dois régulièrement passer une semaine entière à trouver l'erreur d'une ligne qui fait planter le programme une fois sur cinquante. Et puis, si mon manager 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 lorsque vous déboguez. Ayez toujours une fenêtre d'éditeur ouverte et notez votre courant de conscience. Cela n'a de sens que pour vous. Vous pouvez constater que cela vous aide à déboguer plus rapidement, mais cela signifie également que vous avez quelque chose de concret à montrer pour montrer que vous n'avez pas joué à Nethack toute la semaine.
Comparez les notes avec tous vos collègues. Combien de temps faut-il généralement pour corriger les bogues? Leurs bugs restent-ils fixes? À quelle fréquence changent-ils une petite chose et se retrouvent-ils enfouis sous un tas de conséquences en cascade? Les réponses à ces questions vous permettront de savoir si vous avez vraiment des difficultés par rapport au reste du département.
Faites-vous des amis avec les gens de l'assurance qualité et les gens du service client. Ce sont eux qui ont la meilleure idée de la façon dont important les bogues sont. Souvent, cela n'a que peu ou pas de corrélation avec la façon dont difficile les bogues, vous pouvez donc jouer un peu au système et essayer de vous attribuer tous les bogues de haute importance et de faible difficulté. (Ce n'est pas vraiment de la triche. Une équipe bien organisée s'attaque toujours d'abord à ces bugs.)
Si votre patron ne vous a pas donné de commentaires adéquats sur vos performances pendant deux années consécutives, c'est un problème à aborder d'abord lors de cette évaluation des performances, puis lorsque vous recevez le tour d'horizon à ce sujet, à augmenter avec le patron de votre patron. Soyez poli, et surtout ne les laissez pas voir à quel point vous êtes en colère, mais recevez des critiques spécifiques par écrit.
Bien que vous aimiez peut-être programmer et résoudre des problèmes, il se peut que vous vous demandiez dans quelle mesure vous appliquez ce que vous apprenez à d'autres domaines. Est-ce que la dernière douzaine de bogues que vous avez corrigés est suffisamment similaire pour que ce qui vous a aidé à en corriger un soit utile pour un autre? Cela fait partie de la rétrospective de ce que vous avez fait et du temps qu'il a fallu pour le faire. Juste une idée à considérer.
Deuxièmement, je regarderais comment tu fais ton travail. Êtes-vous régulièrement interrompu et, alors que 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 façon de travailler qui peuvent vous aider ici, 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 faire une partie de mon travail. Bien sûr, c'étaient ces endroits où si je faisais une chose, 5 nouvelles choses tomberaient sur mes genoux et donc c'était facile d'être dépassé. Bien que je ne puisse plus y travailler, je n'avais pas de bonne solution pour attirer mon attention sur quelques choses, de sorte que je n'ai pas l'impression d'essayer de maîtriser 1000 choses en même temps. Si je peux savoir quelques choses clés à faire et comment mon travail sera jugé, alors je suis beaucoup mieux que si j'ai une liste de choses à faire qui fait un mile de long et que personne ne semble s'en soucier si je reçois parties de celui-ci fait. Ainsi, il se pourrait qu'il y ait une composante culturelle à cela au sein de l'organisation bien que je ferais attention à ne pas demander que les choses changent ici. Je me souviens d'un lieu de travail où j'ai demandé des commentaires plus fréquents et j'ai fini par être microgéré jusqu'à ce que je sois licencié parce que je ne me contentais pas de ce qui était sur ma liste de choses à faire.
Après deux ans de travail, il devrait être évident pour tout le monde (vous, votre patron, vos collègues) de savoir où vous en êtes. C'est-à-dire que vous ne devriez jamais découvrir que vous vous en sortez mal une seule fois par an; un environnement de travail idéal fournira une rétroaction continue.
Quoi qu'il en soit, concernant la façon de déboguer le code multithread: vous n'avez pas indiqué si c'est votre code ou celui de quelqu'un d'autre. Il existe de nouveaux débogueurs et analyseurs statiques qui peuvent gérer la concurrence. Mais vraiment, connaître les patterns sera votre meilleur pari puisque vous saurez quoi chercher.
Si vous comprenez comment fonctionnent les sections critiques, les conditions de course et l'impasse, vous serez alors mieux placé pour repérer les choses inattendues. Si vous voyez une "communication" entre deux threads sans variables de condition, ou si les ressources sont mutexées sans ordre particulier, ou si une variable locale est déclarée static sans raison apparente, alors vous avez un bug potentiel! Apprenez donc les meilleures pratiques de votre domaine et vous serez mieux placé pour juger quand quelque chose sort de l'ordinaire.
Ne luttez pas seul, sauf si vous le devez. Recrutez des collègues. Demandez-leur de vous aider lors de la chasse aux bogues. Demandez-leur quel est leur processus de réflexion et leurs outils. Peut-être le mentionner dans votre examen dans le cadre de votre plan d'amélioration. Si tout le monde autour de vous fait mieux sur ce système, peut-être qu'ils connaissent quelque chose de spécifique?
Mon patron vient de me dire que je recevrai une évaluation des performances négative lundi. Il veut me dire pourquoi je suis si lent et pourquoi mon taux de correction de bogues est si bas.
Sachez que dans toute entreprise non dysfonctionnelle, il ne se passe rien sur cette commande. Si votre patron est préoccupé par vos performances, il doit se fixer des objectifs à court terme et parler de vos résultats pour savoir où se situe le problème.
Au lieu de cela, il décide de vous donner un avis négatif, puis de découvrir 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 visez pas à résoudre les bogues plus rapidement. Visez à évaluer vos propres capacités, vérifiez comment vos collègues travaillent, comment ils savent ce qu'ils savent et sachez que ce n'est pas une entreprise idéale.
En ce qui concerne les conseils pratiques, j'utilise des extraits de code et mon propre mediawiki pour prendre des notes. J'ai toujours à l'esprit quels livres lire ensuite et quelle direction prendre pour continuer mon apprentissage. L'apprentissage est le chemin vers un meilleur emploi et une vie plus heureuse.
Tout d'abord, un regain de confiance:
Pourquoi souffrir? Vous pouvez facilement trouver un travail où ils penseront que vous êtes "dieu" juste parce que vous pouvez faire n'importe quoi sous Linux, quel que soit votre taux de correction de bogues.
Quoi qu'il en soit, il est impossible de fixer une limite de temps pour chasser un bug. La chasse aux insectes est sans aucun doute une compétence et son efficacité est très précieuse.
Vous pourriez manquer une astuce 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 trouver des problèmes de corruption de mémoire et des conditions de concurrence de données, alors que vous ne comptez que sur gdb et printf, je vais probablement vous botter le cul, même si tu es plus intelligent que moi.
En outre, comment comprenez-vous simultanéité ? Si vous développez depuis dix ans, mais la plupart de cette expérience n'était pas avec du code multithread, cela pourrait être un problème.
Vous devez étudier le multithreading en détail: bien plus que simplement savoir comment utiliser les API, mais vraiment le "développer" de manière approfondie. Si vous faites de la programmation multithread, vous devriez être ce développeur qui peut regarder une base de code à un kilomètre et repérer des scénarios de conditions de course, de blocages, d'inversions de priorité, de famine ...
J'ai récemment lu le livre Travailler efficacement avec le code hérité et cela m'a donné un regain de confiance important lorsque je m'attaque à un problème dans n'importe quel base de code.
Si le code avec lequel vous travaillez est loin d'être parfait, je pense que ce livre serait utile. J'ai constaté que la plupart du temps, pour corriger un bogue, je dois d'abord refactoriser le code environnant afin de même comprendre le, puis une fois que je comprends le code, et si tout va bien rendre le code testable, traquer et résoudre le problème est moins une épreuve. (Parfois, je réécris même le code juste pour le comprendre, mais je reviens ensuite 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 répond qu'à une partie de votre problème, et quelque peu indirectement, mais le livre mérite d'être lu quoi qu'il en soit, car travailler avec du code hérité est inévitable pour tout développeur.
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 remettre les pendules à l'heure dès le départ.
Vous êtes un professionnel investi dans votre petite entreprise, à savoir vous-même.
Vous êtes prêt à travailler pendant qu'une Union d'intérêts vous propulse chaque jour hors du rack.
Si cette propulsion n'est pas là pendant une longue période, alors continuez.
Vous perdez votre temps et votre énergie sur un foutu employeur qui ne maintient pas votre intérêt/vos compétences mises à jour/vos missions difficiles et/ou intéressantes pour vous. C'est le travail de la direction. A part ça, ils sont de purs frais généraux .....
Gardez votre passion, car c'est la clé.
Demandez à votre supérieur quelle est votre vitesse de correction des bogues et quelle est la vitesse moyenne de l'équipe pour corriger les bogues. Plus important encore, demandez-lui comment est mesurée la vitesse de correction des bugs ...
C'est une sorte de métrique qui n'est pas vraiment une métrique; si c'était le cas, ce serait encore plus peu fiable que LOC (bien que mesurer des choses différentes). Et sans une mesure appropriée, il n'y a aucune raison de vous accuser de quoi que ce soit.
J'ai été dans 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 y a certains outils/trucs/astuces que je n'ai découverts qu'après un an et demi. J'ai été transféré d'une équipe à l'autre (je suppose que j'étais sous-performant) et je découvre 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 en premier lieu. Regarder d'autres développeurs travailler à travers un problème de débogage peut être très éducatif. Demandez-leur de l'aide lorsque vous avez du mal à trier quelque chose. Surtout si vous recouvrez 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 a du mal avec quelque chose, il devrait obtenir de l'aide avant de commencer le test négatif. Enfer, si quelqu'un dans une équipe se débat et n'obtient jamais d'aide, je dirais que chaque membre de cette équipe fait quelque chose de mal (bien que cela puisse être le résultat direct de personnes surveillant de trop près leurs taux de correction de bugs).
Ce qui manque dans l'OP est toute mention d'un processus ou d'une méthode reproductible qui est suivi pour résoudre les bogues.
Donc, tout d'abord, documentez le processus que vous suivez. Assurez-vous de documenter ce que chaque étape du processus est censée accomplir.
Vous pouvez décrire le processus comme ayant des tâches comme celle-ci:
- Assurez-vous de comprendre exactement quel est le problème signalé.
- Essayez de reproduire le problème.
- Commencez à décomposer le problème en petits morceaux
- Pensez aux causes possibles du problème.
- Testez ces hypothèses
Il serait utile de savoir si les bogues existent depuis longtemps ou sont introduits avec des modifications récentes. Si les bogues ont été introduits avec des modifications récentes, la révision du code et/ou la simple lecture du code que les gens créent peut aider.
Je pense que si vous pouvez définir clairement le problème, par exemple, "J'ai du mal à penser aux hypothèses à tester lorsque vous essayez de résoudre des bugs", alors vous pouvez obtenir des conseils plus ciblés.