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

129

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.

BeeBand
la source
170
Dites à votre chef que c’est vraiment gentil de sa part d’économiser pour votre évaluation au lieu de le mentionner quand il a remarqué que c’était un problème.
Blrfl
13
La programmation de maintenance nécessite un certain type de personne. Peut-être que ce n'est pas ton truc. De même, le nouveau développement nécessite encore un autre type de personne. Vous parlez de découvrir des outils / conseils / astuces. Combien de ces outils avez-vous créés pour votre propre usage? Si la réponse est non, alors je pense vraiment que vous n'êtes pas une personne du type programme de maintenance. Si vous avez manqué de performance entre plusieurs projets, considérez que vous n’êtes pas qualifié pour le poste dans lequel vous vous trouvez. Trouvez quelque chose qui vous convient mieux.
Dunk
40
Si vous devez deviner que vous êtes malmené à cause de votre performance, la direction fait quelque chose de mal. De même, si la première fois que vous entendez parler de votre sous-performance survient après 2 ans, la direction fait quelque chose de mal.
Michael Shaw
32
@ Abeille: Généralement, une fois que la critique est mauvaise, il est temps de partir. Ils peuvent vous mettre sur un "programme de développement des employés", mais je ne pense pas avoir jamais vu quelqu'un récupérer après avoir atteint ce stade. Le meilleur moment pour trouver un emploi, c'est quand vous en avez déjà un. Donc, si j'étais vous, je mettrais à jour mon CV et commencerais à chercher ailleurs très bientôt. Vous devez également faire très attention au type de travail que vous prenez. 7 ans d'expérience laisse encore des options. Une fois que vous atteignez 10, les entreprises vont s'attendre à une expertise dans des domaines particuliers. Choisissez un domaine que vous aimez et où vous êtes bon. Oups vient de vous voir frapper 10 déjà.
Dunk
8
Pas assez pour être une réponse, mais en ce qui concerne "la façon d'aller plus vite": vous dites que c'est un domaine dans lequel vous êtes nouveau. Serait-ce une façon de réparer, c'est trop d'essais et d'erreurs, sans vraiment savoir ce qui se passe "au fond"? Dans un tel cas, apprendre les bases à fond vous aidera à mieux cerner les problèmes potentiels.
Matsemann

Réponses:

80

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, - vous êtes un ingénieur en logiciel, mec! Déboguez-vous!

kmote
la source
2
quelle réponse brillante. Je pense que tous vos arguments m’appliquent (et en ce qui concerne le n ° 1, eh bien peut - être que je suis moins intelligent, j’entends dire qu’il existe différents types d’intelligence - alors c’est peut-être lié au n ° 4. mais peut-être que je suis meilleur en Web ... et maintenant j'y pense, cela pourrait être réaliste). de toute façon, vous êtes très perspicace.
BeeBand
14
3 et 4 sont plus gros (pour les programmeurs) que la plupart des patrons ne peuvent l'imaginer. Si un programmeur a le moral bas, il / elle ne peut pas se concentrer sur le travail. Pour un programmeur, le moral est l’élan et l’élan est primordial.
TimG
7
Excellente réponse. Déboguer vous - même est une excellente phrase, d'ailleurs. J'aimerais pouvoir vous inviter une seconde fois pour cela.
Kyeotic
2
Votre "cela suivrait" ne fonctionne pas au point 1 puisque le paradoxe de l'amitié modélise les relations entre deux personnes comme un simple bord bidirectionnel entre deux sommets d'un graphique, tandis qu'un graphique indiquant qui est "plus intelligent" que celui qui devrait envisager un une multitude d'autres facteurs, sans compter que les règles de transitivité ne s'appliquent pas. Je suis d'accord avec les points 2, 3 et 4. Dans le cas de l'OP, je pense que son patron est un imbécile qui souffre de l'effet de relance-krueger.
funkymushroom
1
programmeur, corrigez-vous vous-même. adore ça :) bonne réponse aussi. utile pour moi, non pas parce que je suis dans cette situation, mais parce que je vois maintenant comment l'éviter. +1
jammypeach
56

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 ...

Ton
la source
2
c'est une excellente réponse. J'ai quelques réflexions à faire sur pourquoi je ne profite pas de ce travail. Ce sont principalement les fichiers journaux qu’ils nous fournissent pour accompagner les bogues. Je suis venu pour les haïr plus que quiconque; Je pense que c'est ce sentiment 'dans le noir' que je déteste.
BeeBand
4
À moins que quelqu'un n'ait rencontré un problème similaire sur le même projet, la plupart des gens démarrent "dans le noir" lorsqu'ils obtiennent un nouveau bogue. Ensuite, en fonction des symptômes, vous déterminez comment recréer le problème, ce qui devrait vous donner une idée de l'endroit où commencer à deviner la cause du problème. Vous continuez pas à pas. Rien de magique, rien à haïr. Vous dites que vous détestez les fichiers journaux. Avez-vous créé vous-même des outils pour automatiser l'analyse de ces fichiers journaux? En ignorant le fait que les fichiers journaux devraient être utiles, s'ils ne l'étaient pas, je n'aurais pas tardé à créer un outil pour les analyser plus facilement.
Dunk
1
@Dunk Oui, j'ai créé un outil pour analyser les fichiers journaux de différentes manières. J'ai découvert par la suite que quelqu'un en avait déjà créé un il y a environ un an.
BeeBand
@ Abeille: votre création d'un outil montre une initiative requise. Quelqu'un ne vous donne-t-il pas un aperçu de l'environnement de développement lorsque vous passez d'un projet à l'autre? Si des outils existent, il semblerait que le responsable du projet aurait dû vous en informer.
Dunk
@Dunk re aperçu - Nope. Mon premier responsable d’équipe m’a montré un outil en particulier, mais n’a pas indiqué qu’il était utile pour corriger des bugs d’un type spécifique ou qu’il pouvait être utilisé pour d’autres projets. Lorsque j'ai été transféré dans ce nouveau projet de maintenance, personne ne m'a parlé de l'environnement de développement - je n'avais qu'à demander. Ce n’est qu’après avoir eu du mal à construire mon propre outil que j’ai demandé à un collègue de me dire comment utiliser l’outil original. (NB c'est un outil différent de mon commentaire précédent).
BeeBand
38

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.

naftalimich
la source
2
J'ai vu des équipes dans ma carrière professionnelle qui sont exactement comme vous l'avez décrit. Le code qu'ils gèrent est vaste et crypté, et les informations sur son fonctionnement sont jalousement protégées. Les nouveaux membres de l’équipe sont laissés à eux-mêmes et finissent par être mutés pour sauver leur carrière.
Anthony Giorgio
31

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é

Mathew Foscarini
la source
11
Il est illégal de ne pas donner de commentaires négatifs de la performance, mais ils ne doivent être objectifs et convenir des critères possibles pour le travail et vous soutenir.
pjc50
9
J'ai pensé, peut-être que je réagissais de manière excessive, lorsque j'ai posté cette réponse, mais la lecture de votre message résonnait avec mes propres expériences. La correction de bogues n'est pas quelque chose qui peut être mesuré avec un contexte de performance. J'ai passé 3 mois une fois pour résoudre un seul bug. Habituellement, ce sont les gars intelligents qui attrapent les bugs difficiles.
Reactgular
9
Je ne vote pas car je ne vois aucune preuve que vous soyez un avocat et prétendez donner des conseils juridiques. De plus, si d’autres employés corrigent X bugs en moyenne par mois, mais que le PO corrige X / 10, c’est tout à fait objectif et raisonnable.
Andy
7
@Andy merci de partager pourquoi vous avez voté à la baisse. Je conviens que les rapports de correction de bugs sont un indicateur, mais qu’il est objectif de dire à quelqu'un le vendredi qu’il aura une critique négative le lundi suivant. Autre que de leur faire faire preuve de tact pendant le week-end. N'est-il pas prudent de supposer que le résultat souhaité serait que l'employé ne se présente pas lundi pour l'examen? Cela ne serait-il pas qualifié de congédiement déguisé? J'espère pouvoir changer votre point de vue, car le licenciement constructif est un problème persistant dans notre secteur.
Reactgular
7
Il n’ya aucun moyen pour un juge de dire qu’il s’agit d’un congédiement déguisé. Vous pouvez voir la lettre de la loi, mais ce type de loi est là pour les cas où un employé est harcelé ou maltraité, une situation activement hostile. D'après ce que dit le PO, ils ont été informés qu'ils obtiendraient un avis négatif parce qu'il ne se mesurait pas à ses pairs en ce qui concerne le taux de correction des bogues. C’est une situation difficile, mais à peine hostile et certainement pas illégale. Le patron aurait peut-être pu faire preuve de plus de tact, mais les commentaires ne doivent pas nécessairement être limités aux évaluations de performances officielles
pdubs
26

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!

Zan Lynx
la source
3
C'est une réponse fantastique. Je suis très impressionné.
Daniel Hollinrake
26

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.

zwol
la source
4
"Le débogage est deux fois plus difficile que d'écrire le code en premier lieu." - Brian Kernigan (père de C, UNIX)
TimG
4
@ Timg: Et comme tous les autres programmeurs, Kernigan sous-estimait la difficulté.
mu est trop court
Wow, j'aimerais souligner que c'est une question très difficile et je suis vraiment surpris de voir une réponse aussi bonne et perspicace ici. Merci.
Maksymko
12

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.

JB King
la source
2
ended up getting micromanaged until I was terminated- Eh bien, je viens de regarder votre profil SO et vous avez clairement rebondi, alors je trouve votre réponse encourageante. Je vais parler de votre premier point lundi - je reçois des bugs provenant de domaines très disparates.
BeeBand
10

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.

Chrisaycock
la source
2
oui, ce n'est pas mon code - c'est un vaste système intégré, conçu pour la première fois il y a 10 ans. Je pense que vous avez raison en ce qui concerne les modèles - je dois revenir à la base.
BeeBand
1
@BeeBand, il serait bon de savoir comment vous vous en sortez. J'espère que les choses vont s'arranger.
Daniel Hollinrake
10

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?

pjc50
la source
Il serait intéressant de savoir si BeeBand l'a déjà fait. En lisant les commentaires et les réponses, il semble que l’environnement soit assez hostile.
Daniel Hollinrake
1
Eh bien, je peux sympathiser avec cela. Je sais que c'est comme être dans une entreprise où l'équipe de développement est submergée de travail. Heureusement, bien que dans mon cas, je travaille avec d'excellents collègues et que nous nous surveillions les uns les autres. Y a-t-il quelqu'un avec qui tu peux te mettre? Le temps passé à vous former et à devenir plus productif sera rentable pour tout le monde. Au son des choses qui vous préoccupent et qui sont consciencieuses, votre entreprise aurait intérêt à vous garder.
Daniel Hollinrake
8

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.

utilisateur2106285
la source
7

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 ...

Kaz
la source
1
Le plus gros problème de la concurrence est qu’il est beaucoup plus facile d’écrire du code exempt de bogues que de le réparer. Surtout si le code est presque correct. Et les bugs ne sont généralement pas dans un endroit, mais distribués sur plusieurs.
gnasher729
5

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.

Jason Swett
la source
Je suis en train de le lire sur votre recommandation.
BeeBand
3

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.

m3th0dman
la source
Vraisemblablement, cela se mesure en nombre de problèmes fermés / unité de temps . Il serait peut-être raisonnable de dire «certains bogues prennent plus de temps que d’autres», mais à moins que le PO ne fonctionne dans une partie particulièrement difficile du code et que tout le monde fasse des choses faciles, cela ne va probablement pas retenir l’eau.
Caleb
3

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é.

dennisk1718
la source
2

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).

Erik Reppen
la source
2

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.

dcaswell
la source