Esiste un modo per accelerare la risoluzione dei bug? Ho appena ricevuto un avviso dal mio capo [chiuso]

Il mio capo mi ha appena detto che lunedì riceverò una recensione negativa delle prestazioni. Vuole parlarmi del perché sono così lento e del perché il mio tasso di correzione dei bug è così basso.

Adoro programmare e risolvere i problemi, ma in realtà trovo davvero difficile il mio lavoro.

Sono stato programmatore per circa 10 anni. Ma questo è il mio primo lavoro Linux multithreading incorporato - Sono qui da 2 anni ed è ovvio per tutti che sto ancora lottando. E penso di essere diventato così demoralizzato e di sentirmi così emarginato che ho perso molto del fuoco che avevo all'inizio del lavoro.

Qualcuno è mai stato in una situazione simile e come si fa ad aumentare il tasso di correzione dei bug?

Aggiornamento: ho avuto la recensione. Sono stato messo su un "programma di sviluppo dei dipendenti" di 3 mesi (del tipo menzionato da Dunk). Non sono sicuro di poterlo cambiare. Ma anche se devo andare avanti, ho imparato molto da questa esperienza.

Un altro aggiornamento

Sono passate circa 6 settimane dalla prima recensione. Il mio consiglio a chiunque si trovi di fronte alla stessa situazione è di essere abbastanza umile da prendere le critiche e imparare dai propri errori. E non aver paura di sembrare stupido. Fai un sacco di domande. Fai sapere alle persone che stai cercando di imparare e continua a chiedere fino a quando non capisci. Ma preparati a non farlo funzionare. Sto costruendo un portfolio di codice ... oltre a dargli il massimo.

Ancora un altro aggiornamento

Sono titubante nel metterlo qui, dal momento che sono preoccupato che non sarò in grado di riferire i futuri datori di lavoro al mio profilo stackoverflow ... Ma comunque, potrebbe essere interessante per qualcuno che legge questa domanda, ma in realtà ho perso il mio lavoro qualche settimana fa. Sono nel bel mezzo di rispolverare tutte le abilità di cui ho bisogno - ho preso molto dai consigli forniti qui.

Molte risposte hanno messo in dubbio i metodi / tattiche / metriche / ecc. Del tuo capo. Ma questo è il punto. Forse SEI lento. Ogni stanza degli sviluppatori deve avere UNO che è più lento degli altri, giusto? (Questa è solo una teoria degli insiemi.) Quindi supponiamo che tu sia. La risposta è: PERCHÉ sei lento? (Chiaramente questa è la domanda a cui devi rispondere prima di poter risolvere la tua domanda dichiarata su come ottenere più velocemente.)

Potrebbero esserci molte ragioni, ma ecco alcune possibili spiegazioni da considerare:

1. Sei meno intelligente di loro . È possibile vero? (Gli studi hanno dimostrato che TUTTI siamo meno popolari , meno interessanti e (ne conseguirebbe) meno intelligenti dei nostri amici.) Quindi forse sei solo un cervello lento. Poi di nuovo, nel tuo caso penso che sia improbabile. Una rapida occhiata al tuo profilo StackOverflow mostra che hai una storia di domande intelligenti su una vasta gamma di argomenti. Quindi ovviamente sei un pensatore e probabilmente uno bravo in questo.

2. Ti sei sparsa troppo. Lo stesso tuo profilo SO mostra che le tue domande coprono una gamma molto ampia di tecnologie negli ultimi 2 anni (grafica, web, python, c ++, c, linux, embedded, thread, socket ecc.). Personalmente, so che quando sono stato messo nella situazione di dover (o desiderare) scavare in una moltitudine di flussi diversi, mi trovo a nuotare la corrente molto velocemente (o, piuttosto, molto lentamente ). Forse quello di cui hai davvero bisogno qui è FOCUS . E forse una buona dose di prioritizzazione . Esiste un modo per relegare le pentole meno importanti nel bruciatore posteriore e aumentare il calore sul piatto principale?

3. Non ti stai divertendo. Quando il fuoco si spegne, il motore a vapore è destinato a rallentare. Hai ammesso nel tuo post che il tuo morale ha subito un duro colpo ultimamente. Sfortunatamente sei stato inghiottito dal vortice succhiante delle armoniche negative auto-rinforzanti, una forza che può distruggere i ponti . È una spirale fin troppo familiare: compito difficile -> stress -> scadenza mancata -> più stress -> meccanismo di coping scadente -> più stress -> procrastinazione -> scadenze più mancate -> critica / gossip (reale o immaginato) - > ancora più stress. Ottieni l'immagine. Questo raramente conduce ovunque utile. Prendi una lezione dai miei giorni nel rafting in acque bianche: quando vieni risucchiato sott'acqua da una corrente circolante sul retro di un rapido di classe 4, il giubbotto di salvataggio NONti riporta in superficie. La migliore strategia (anche se non intuitiva) è quella di trovare il fondo del fiume ed uscire dalla ripida marea. Quindi il mio consiglio per te è: trova un po 'di terra , amico, (amici, chiesa, sane nuove abitudini, ecc.) E usalo per darti una spinta fuori dal vortice.

4. Non sei nella tua zona. Michael Jordan ha creato un giocatore di baseball piuttosto zoppo. (OK, era ancora meglio di me, ma sicuramente un minore-leaguer.) Forse "linux embedded multithreading" non è il tuo concerto. Ma lo sviluppo software è un campo estremamente ampio (come ben sapete; cfr. N. 2 sopra). La tua azienda è abbastanza ampia da poter trovare un'altra nicchia? Nel mio ultimo lavoro sono stato assunto come sviluppatore di SW incorporato. (Non avevo esperienza in quel regno, ma dissi loro che ero uno "studente veloce"). Affondai rapidamente come una pietra. Ma ho continuato a lavorare sodo e ho continuato a cercare i problemi che ho fattosaper risolvere per loro. A quanto pare, sono stato gradualmente in grado di migrare verso nuove responsabilità per le quali potevo brillare e per le quali alla fine ho ricevuto un notevole elogio. Quindi forse devi marchiare te stesso.

Il punto è: se sei lento, c'è un motivo. Ma, ehi , sei un ingegnere del software, amico! Debug te stesso!

Il tuo capo potrebbe essere corretto: potresti essere "poco performante" (ne parleremo più avanti tra un minuto). Ma potrebbe non essere la colpa del tuo livello di competenza. Non penso che sarebbe possibile suggerire che forze al di fuori del tuo controllo ti stanno causando stress, il che sta avendo un effetto negativo sulle tue prestazioni.

Diamo un'occhiata ad alcuni dei motivi per cui il tuo capo potrebbe ora sollevarlo:

Cultura e politica

Potrebbero esserci forze al di fuori del tuo controllo che richiedono al tuo capo di esprimere la sua preoccupazione. È importante capire il sistema in cui stai lavorando. Il tuo compito è quello di far apparire bene il tuo capo. L'unico modo per farlo è capire le pressioni a cui è sottoposto.

Capacità

È possibile che l'abilità non sia all'altezza, come dici che ha dichiarato apertamente. Ecco cosa farei in questa situazione:

Ricevi un feedback specifico dal tuo capo su come misura le prestazioni. Non stai chiudendo tutti i bug della persona X? C'è un numero fisso di bug che dovresti risolvere? Se lavori da solo, devi assicurarti che le persone che misurano la tua performance la stiano misurando equamente e non basandosi su un'idea preconcetta.

Se la tua performance è lenta e basata su un gap reale, identifica quel gap e metti insieme un piano dettagliato con il tuo capo con l'obiettivo di colmarlo.

Questa recensione è anche una buona opportunità per far apparire il fatto che non sei felice. È positivo che tu abbia identificato che non ami questo lavoro. Ma scopri perché. Quale parte del tuo lavoro ti piace e cosa no? Potrebbe essere che questo lavoro non fa per te ...

Alcuni ambienti di lavoro non sono realizzabili. Ho visto ambienti in cui nessuno poteva sopravvivere (tranne quelli che erano all'inizio) perché così tanto era privo di documenti e le domande erano scoraggiate in modo così veemente.

Devi davvero essere onesto con te stesso riguardo alle aspettative e alle risorse fornite per aiutarti a soddisfarle. Il problema potrebbe non essere tu.

Dici che ci sono persone che svolgono lavori simili ai tuoi che, presumo, non hanno difficoltà, ma che hanno più di 5 anni di esperienza nei tuoi 2. Come ti senti rispetto ai tuoi coetanei? Sono rockstar che ti superano del tutto (a questo proposito) o sono proprio come te? Forse hanno appena avuto modo di conoscere il sistema quando era più semplice ... Hai detto di avere 8 anni di esperienza di programmazione prima di questa linea di lavoro. Come hai fatto lì? Se sei stato bravo, allora questo dovrebbe dirti qualcosa.

La parte che mi ha colpito è il fatto che ti descrivi come se fossi al buio rispetto a tutti gli insetti che ti vengono incontro. È possibile che la base di codice sia così vasta e inesplorata che le aspettative potrebbero non essere ragionevoli.

Per te averlo fatto per quanto hai significa che hai fatto qualcosa di giusto e hai qualcosa che va per te.

In conclusione, penso, è che devi sentirti bene con te stesso e con quello che stai facendo. E se ciò significa andare avanti, allora così sia.

Meglio andare avanti che avere un lavoro che rovina la tua vita.

In primo luogo, nota: questa risposta può applicarsi solo ad alcune regioni in cui è illegale licenziare un dipendente senza licenziamento. Detto ciò...

Questo potrebbe essere un caso di licenziamento costruttivo e che è illegale.

La tattica è di demoralizzare e ridurre l'autostima di un dipendente fino a quando non ha lasciato il lavoro. È un modo per l'azienda di risparmiare denaro senza dover pagare la liquidazione o risolvere il problema di dover affrontare il dipendente e licenziarlo.

Vuole parlarmi del perché sono così lento e del perché il mio tasso di correzione dei bug è così basso.

Questa colpa è molto ambigua. È impossibile per entrambe le parti affermare che l'altra è sbagliata. Hai impiegato un mese per correggere un bug. E allora! Questo ti mette in una posizione difensiva, dovendo presentare fatti a supporto della tua richiesta di un mese. Data la tua attuale abilità, esperienza e conoscenza come fattori. Come datore di lavoro è compito del datore di lavoro gestire il tempo e gli sforzi dei suoi dipendenti. Il datore di lavoro deve essere la persona coinvolta nel rischio associato alla correzione dei bug. Non l'impiegato. Ha sempre avuto la scelta di assegnare il bug a qualcun altro.

Se sei un appaltatore e nel tuo contratto si afferma che sarà responsabile della correzione degli errori, quindi è una storia completamente diversa.

È sbagliato per il datore di lavoro lamentarsi del fatto che stai impiegando troppo tempo? Assolutamente no, ma non può considerarti responsabile per questo, e non può licenziarti per questo. Può dirti "Non abbiamo più bug che richiedono le tue abilità e sei messo in congedo", ma devono dirti nel momento in cui si presenta un nuovo problema che puoi risolvere. Altrimenti, devono terminare con separazione. Quello che non può fare è darti un lavoro che non puoi gestire e poi lamentarti. Penso che questo sia illegale.

Adoro programmare e risolvere i problemi, ma in realtà trovo davvero difficile il mio lavoro.

C'è una grande differenza tra un lavoro che trovi difficile e il tuo datore di lavoro che ti dà un lavoro troppo difficile. Se ritieni che i compiti che ti sono stati assegnati siano stati svolti per scoraggiarti dall'avere una carriera in azienda, questo potrebbe essere illegale.

Sono stato programmatore per circa 10 anni. Ma questo è il mio primo lavoro Linux multithreading incorporato - Sono qui da 2 anni ed è ovvio per tutti che sto ancora lottando.

Questo è il motivo per cui penso che ti sia ritrovato nel mezzo di un licenziamento costruttivo. Non sono contenti di te, quindi ti ammucchiano fino a che non te ne vai.

E penso di essere diventato così demoralizzato e di sentirmi così emarginato che ho perso molto del fuoco che avevo all'inizio del lavoro.

Un datore di lavoro è responsabile di fornire un ambiente di lavoro sicuro e positivo. Senza ulteriori informazioni (molto probabilmente personali) è difficile per gli estranei dire cosa sta realmente succedendo qui. Chiedi a un avvocato del lavoro una consulenza gratuita. Saranno in grado di dirti se stai giocando.

Riferimenti

Non sono un avvocato, ma Google ha fatto alcuni documenti che trattano l'argomento del licenziamento costruttivo che vale la pena leggere prima di inserire la tua recensione lunedì. Il punto principale qui è fare attenzione a una riduzione di stipendio, umiliazione e improvvisi cambiamenti nella tua carriera con l'azienda.

I fatti rilevanti sono attenti a:

• Mancato supporto adeguato di un dipendente in condizioni di lavoro difficili
• Disciplina eccessiva di un dipendente Imporre un cambiamento nel luogo di lavoro dei dipendenti con breve preavviso
• Imposizione di una riduzione di stipendio o salari

Domande e risposte legali: licenziamento costruttivo

Motivi per richiedere un licenziamento costruttivo

Wikipedia

elementi di un licenziamento costruttivo

Forse verrai confrontato con uno dei programmatori originali di un progetto. So che come sviluppatore originale di uno dei progetti su cui lavoro, ho un enorme vantaggio nel correggere i bug. Non penso che sia a causa della mancanza di documentazione, è solo che posso saltare intuitivamente a potenziali problemi perché il mio cervello conosce tutto il codice.

Se vieni confrontato con quello, allora non hai intenzione di misurarti. Ti occorrerà sempre più tempo per accelerare il progetto e non saprai dove sono tutti i potenziali punti di interazione.

Ho letto il tuo commento sul non scoprire strumenti e trucchi che altri programmatori stanno usando per risolvere i problemi. Forse per la prossima correzione di bug devi provare a programmare la coppia. Questo può essere incredibilmente utile. A turno guidando la tastiera. Parla molto .

È possibile utilizzare un notebook o una lavagna per tracciare tracciati di percorsi di funzioni, thread e bloccare la durata di vita e contrassegnare dove osservare vari bit di comportamento e dove è possibile inserire nuove sonde.

Risolvere questi tipi di problemi di threading a basso livello può essere davvero difficile e ho molta simpatia per te. Ho dovuto analizzare diversi gigabyte di file di registro prima di individuare un problema a due righe. E tu sai cosa? L'ho fissato per giorni prima di chiedere aiuto a un ingegnere junior che era stato uno stagista l'anno prima, e ha trovato un nuovo approccio e individuato il problema in un'ora. Quindi, dopo aver dedicato un po 'di tempo a un bug, guardalo con attenzione. Può aiutare molto!

Una delle disfunzioni di gestione più comuni in questo settore non è capire che il debug è intrinsecamente difficile . Ho quasi 20 anni di esperienza e devo ancora passare regolarmente un'intera settimana a trovare l'errore di una riga che fa crashare il programma una volta su cinquanta. E poi, se il mio manager non capisce queste cose, mi danno fastidio per aver impiegato una settimana a cambiare una riga di codice.

Cosa puoi fare al riguardo?

• Prendi appunti mentre esegui il debug. Tieni sempre aperta una finestra dell'editor e scrivi il tuo flusso di coscienza. Non ha senso per nessuno tranne te. Potresti scoprire che questo ti aiuta a eseguire il debug più velocemente, ma significa anche che hai qualcosa di concreto da indicare per dimostrare che non avresti giocato a Nethack per tutta la settimana.

• Confronta le note con tutti i tuoi colleghi. Quanto tempo impiegano in genere a correggere i bug? I loro bug rimangono corretti? Quante volte cambiano una piccola cosa e si trovano sepolti sotto una pila di conseguenze a cascata? Le risposte a queste domande ti daranno un senso se stai davvero lottando rispetto al resto del dipartimento.

• Fai amicizia con le persone addette al controllo qualità e con l'assistenza clienti. Sono quelli con la migliore idea di quanto siano importanti i bug. Spesso questo ha poca o nessuna correlazione con quanto siano difficili i bug, quindi puoi giocare un po 'il sistema e provare a ottenere assegnato tutti i bug di grande importanza e bassa difficoltà. (Questo non è in realtà un imbroglio. Una squadra ben organizzata insegue sempre prima quei bug.)

• Se il tuo capo non ti ha dato un feedback adeguato sulle tue prestazioni per due anni consecutivi, questo è un problema da affrontare prima in questa revisione delle prestazioni, e poi quando ti viene dato il capovolgimento su di esso, per aumentare con il capo del tuo capo. Sii educato e soprattutto non far loro vedere quanto sei arrabbiato, ma ricevi critiche specifiche per iscritto.

Mentre potresti amare la programmazione e la risoluzione dei problemi, potrebbe esserci la questione di quanto stai applicando ciò che stai imparando ad altre aree. Qualche delle ultime dozzine di bug che hai risolto sono abbastanza simili da rendere utile ciò che ti ha aiutato a risolverne una? Questo fa parte del ripensare a ciò che hai fatto e al tempo impiegato per farlo. Solo un'idea da considerare.

In secondo luogo, darei un'occhiata a come stai facendo il tuo lavoro. Vieni interrotto regolarmente e così mentre provi a correggere il bug A, ti viene detto che i bug B e C hanno la priorità più alta? Considera attentamente quali tipi di cambiamenti nel modo in cui svolgi il tuo lavoro potrebbero esserti di aiuto in quanto ciò è probabilmente parte di ciò che il tuo capo vorrà sapere.

Ho avuto alcuni posti di lavoro che mi dicevano che non gli piaceva quanto tempo impiegavo a svolgere un po 'del mio lavoro. Ovviamente questi erano quei posti in cui se avessi fatto una cosa, 5 cose nuove sarebbero cadute in grembo e quindi sarebbe stato facile essere sopraffatto. Anche se potrei non lavorare più lì, non avevo una buona soluzione su come attirare la mia attenzione su alcune cose in modo da non sentirmi come se stessi cercando di padroneggiare 1.000 cose contemporaneamente. Se posso sapere alcune cose chiave da fare e come sarà giudicato il mio lavoro, allora sono molto meglio di se avessi un elenco di "cose ​​da fare" che è lungo un miglio e a nessuno sembra importare se riesco parti di esso fatto. Quindi, potrebbe essere che ci sia una componente culturale in questo all'interno dell'organizzazione, anche se starei attento a chiedere che le cose qui cambino.

Dopo due anni di lavoro, dovrebbe essere ovvio per tutti (tu, il tuo capo, i vostri colleghi) su dove vi trovate. Cioè, non dovresti mai scoprire che stai facendo male solo una volta all'anno; un ambiente di lavoro ideale fornirà feedback continui.

Ad ogni modo, riguardo a come eseguire il debug del codice multithread: non hai menzionato se questo è il tuo codice o quello di qualcun altro. Esistono alcuni nuovi debugger e analizzatori statici in grado di gestire la concorrenza. Ma davvero, conoscere gli schemi sarà la tua scommessa migliore poiché saprai cosa cercare.

Se capisci come funzionano sezioni critiche, condizioni di gara e deadlock, allora sarai in una posizione migliore per individuare cose inaspettate. Se vedi "comunicazione" tra due thread senza variabili di condizione, o se le risorse sono mutex senza un ordine particolare, o se una variabile locale viene dichiarata staticsenza motivo apparente, allora hai un potenziale bug! Quindi impara le migliori pratiche del tuo dominio e sarai in una posizione migliore per giudicare quando qualcosa è fuori dal comune.

Non lottare da solo a meno che non sia necessario. Recluta colleghi. Falli aiutare nelle cacce ai bug. Chiedi loro del loro processo di pensiero e dei loro strumenti. Forse menzionalo nella tua recensione come parte del tuo piano di miglioramento. Se tutti intorno a te stanno facendo meglio su questo sistema , forse sanno qualcosa di specifico?

Il mio capo mi ha appena detto che lunedì riceverò una recensione negativa delle prestazioni. Vuole parlarmi del perché sono così lento e del perché il mio tasso di correzione dei bug è così basso.

Tieni presente che in qualsiasi azienda non disfunzionale le cose non accadono in questo ordine. Se il tuo capo è preoccupato per le tue prestazioni, dovrebbe fissare obiettivi a breve termine e parlare dei tuoi risultati per scoprire dove si pone il problema.

Invece, decide di darti una recensione negativa, quindi scoprire perché. Sembra che non sia disposto a impegnarsi nel problema e vuole solo risultati nella tabella.

Non mirare a risolvere i bug più velocemente. Punta a valutare le tue capacità, controlla come lavorano i tuoi colleghi, come sanno ciò che sanno e sii consapevole che questa non è una società ideale.

Per quanto riguarda i consigli pratici, uso frammenti di codice e il mio mediawiki per prendere appunti. Ho sempre in mente quali libri leggere e quale direzione seguire per continuare il mio apprendimento. L'apprendimento è la strada per un lavoro migliore e una vita più felice.

Innanzitutto, un aumento della fiducia:

Perché soffrire Puoi facilmente trovare un lavoro in cui penseranno che sei un "dio" solo perché puoi fare qualsiasi cosa con Linux, indipendentemente dalla tua velocità di correzione dei bug.

Ad ogni modo, è impossibile stabilire un limite di tempo per la caccia di un bug. La caccia agli insetti è un'abilità, senza dubbio, e l'efficienza è estremamente preziosa.

Potresti perdere alcuni trucchi di base che altri conoscono, il che ti rende più lento.

Ad esempio, se tu e io stiamo lavorando su alcuni middleware Linux e sto usando Valgrind per trovare problemi di corruzione della memoria e condizioni di competizione dei dati, mentre fai affidamento solo su gdb e printf, probabilmente ti darò un calcio nel culo, anche se sei più intelligente di me.

Inoltre, come è la tua comprensione della concorrenza ? Se stai sviluppando da dieci anni, ma la maggior parte di quella esperienza non era con il codice multithread, questo potrebbe essere un problema.

Dovresti studiare il multithreading in dettaglio: non solo sapere come utilizzare le API, ma "ottenerlo" davvero a un livello profondo. Se stai facendo una programmazione multithread, dovresti essere quello sviluppatore che può guardare una base di codice a un miglio di distanza e individuare scenari di condizioni di gara, deadlock, inversioni di priorità, fame ...

Di recente ho letto il libro Lavorare efficacemente con il codice legacy e mi ha dato un notevole impulso di fiducia quando affrontavo un problema in qualsiasi base di codice.

Se il codice con cui stai lavorando è qualcosa di meno che perfetto, penso che questo libro sarebbe di aiuto. Ho scoperto che molte volte per correggere un bug, devo prima refactoring il codice circostante per persino capirlo , e poi una volta compreso il codice, e spero di renderlo testabile, rintracciare e risolvere il problema è meno di un calvario. (A volte riscrivo anche il codice solo per capirlo, ma poi annullo le mie modifiche per ridurre il rischio di introdurre nuovi bug. Quindi inserisco la mia correzione di bug. Quella tecnica si basa su un trucco del libro.)

Penso che il mio suggerimento affronti solo una parte del problema, e in qualche modo indirettamente, ma vale la pena leggere il libro in ogni caso, poiché lavorare con il codice legacy è inevitabile per qualsiasi sviluppatore.

Chiedi al tuo superiore qual è la tua velocità nel correggere i bug e qual è la velocità media del team nel correggere i bug. Ancora più importante, chiedigli come viene misurata la velocità di correzione dei bug ...

Questo tipo di metrica non è in realtà una metrica; se lo fosse, sarebbe persino più inaffidabile di LOC (sebbene misurasse cose diverse). E senza una misurazione adeguata non c'è motivo di accusarti di nulla.

Riconosci che lavori con i datori di lavoro e / o il cliente NON per loro. Non esitate a menzionarlo nelle interviste, solo per stabilire il record direttamente dall'inizio.

Sei un professionista con molti investimenti nella tua piccola impresa, vale a dire te stesso.

Sei disposto a lavorare mentre c'è un'Unione di Interessi che ti spinge fuori dal rack ogni giorno.

Se quella propulsione non è lì per un lungo periodo di tempo, allora vai avanti.

Stai sprecando il tuo tempo ed energia su un datore di lavoro che non mantiene il tuo interesse / competenze aggiornate / incarichi stimolanti e / o interessanti su cui lavorare. Questo è il lavoro della direzione. Diverso da quello che sono pure spese generali .....

Mantieni viva la tua passione, poiché questa è la chiave.

Sono stato in situazioni simili perché avevo paura di chiedere aiuto. A giudicare da quello che hai detto in questo commento ...

"Ma la cosa frustrante è che ci sono alcuni strumenti / suggerimenti / trucchi che ho scoperto solo dopo essere stato lì un anno e mezzo. Sono stato spostato da una squadra all'altra (immagino perché stavo sottoperformando) e sto scoprendo questi strumenti "nascosti" ogni tanto ".

... potresti aver avuto lo stesso problema che ho fatto io. Il debug è tanto un mestiere quanto scrivere codice che non richiede tanto debug in primo luogo. Guardare altri sviluppatori lavorare attraverso un problema di debug può essere altamente educativo. Chiedi loro aiuto quando hai problemi a risolvere qualcosa. Soprattutto se stai coprendo un terreno che non hai mai visto prima. E fallo idealmente prima che sia il momento di andare nel panico perché non stai facendo nulla.

Detto questo, concordo con i commenti secondo cui la direzione stava facendo qualcosa di sbagliato. Se qualcuno sta lottando con qualcosa, dovrebbe essere d'aiuto prima che inizi il divertimento con la recensione negativa. Inferno, se qualcuno in una squadra sta lottando e non ottiene mai aiuto, direi che ogni membro di quella squadra sta facendo qualcosa di sbagliato (anche se questo potrebbe essere un risultato diretto della gente che osserva i loro tassi di correzione dei bug eccessivamente da vicino).

Ciò che manca all'OP è qualsiasi menzione di un processo o metodo ripetibile che viene seguito per risolvere i bug.

Quindi, per prima cosa, documenta il processo che segui. Assicurati di documentare ciò che ogni passaggio del processo è destinato a raggiungere.

È possibile delineare il processo con attività come questa:

1. Assicurati di capire esattamente qual è il problema segnalato.
2. Prova a riprodurre il problema.
3. Inizia a scomporre il problema in pezzi più piccoli
4. Pensa alle possibili cause del problema.
5. Metti alla prova queste ipotesi

Sarebbe utile sapere se i bug esistono da molto tempo o vengono introdotti con modifiche recenti. Se i bug sono stati introdotti con modifiche recenti che fanno revisioni del codice e / o semplicemente leggono il codice che le persone stanno creando possono aiutare.

Penso che se riesci a definire chiaramente il problema, ad esempio "Ho difficoltà a pensare alle ipotesi da verificare quando provo a risolvere i bug", puoi ottenere consigli più mirati.