Existe alguma maneira de acelerar a solução de bugs? Acabei de receber um aviso do meu chefe [fechado]

Acabei de me dizer pelo meu chefe que vou receber uma avaliação de desempenho negativa na segunda-feira. Ele quer falar comigo sobre por que sou tão lenta e por que minha taxa de correção de bugs é tão baixa.

Adoro programar e resolver problemas, mas realmente acho meu trabalho muito difícil.

Na verdade, sou programador há cerca de 10 anos. Mas este é o meu primeiro trabalho de linux incorporado multithreading - estou aqui há 2 anos e é óbvio para todos que ainda estou lutando. E acho que fiquei tão desmoralizado e me sinto tão marginalizado que perdi muito do fogo que tinha no início do trabalho.

Alguém já esteve em uma situação semelhante e como você aumenta sua taxa de correção de bugs?

Atualização: Eu tive a revisão. Fiz um 'programa de desenvolvimento de funcionários' de três meses (do tipo mencionado por Dunk). Não tenho certeza se eu posso mudar isso. Mas mesmo que eu tenha que seguir em frente, aprendi muito com essa experiência.

Outra atualização

Já se passaram 6 semanas desde a primeira revisão. Meu conselho para quem enfrenta a mesma situação é ser humilde o suficiente para receber críticas e aprender com seus erros. E não ter medo de parecer idiota. Faça muitas perguntas. Informe as pessoas que você está tentando aprender e continue perguntando até você entender. Mas esteja preparado para não dar certo. Estou construindo um portfólio de códigos ... e também dando o meu melhor.

Mais uma atualização

Hesito em colocar isso aqui, pois estou preocupado em não poder encaminhar futuros empregadores para o meu perfil de stackoverflow ... Mas, de qualquer forma, pode ser interessante para alguém que está lendo esta pergunta, mas na verdade perdi minha conta. trabalho há algumas semanas. Estou no meio de aperfeiçoar todas as habilidades necessárias - segui muito os conselhos dados aqui.

Muitas respostas questionaram os métodos / táticas / métricas / etc do seu chefe. Mas isso não vem ao caso. Talvez você seja lento. Toda sala de desenvolvedores precisa ter UM que é mais lento que o resto, certo? (Isso é apenas uma teoria dos conjuntos). Então, vamos supor que seja você. A resposta é: por que você está lento? (Claramente, essa é a pergunta que você deve responder antes de poder resolver sua pergunta declarada sobre como acelerar).

Pode haver todos os tipos de razões, mas aqui estão algumas explicações possíveis a serem consideradas:

1. Você é menos inteligente do que eles . É possível né? (Os estudos mostraram que TODOS somos menos populares , menos interessantes e (a seguir) menos inteligentes do que nossos amigos.) Então, talvez você seja um cérebro lento. Então, novamente, no seu caso, acho isso improvável. Uma rápida olhada no seu perfil do StackOverflow mostra que você tem um histórico de perguntas inteligentes sobre uma ampla variedade de tópicos. Então você é obviamente um pensador e provavelmente um bom nisso.

2. Você está espalhado muito magro. Esse mesmo perfil SO mostra que suas perguntas abrangem uma gama muito ampla de tecnologias nos últimos 2 anos (gráficos, web, python, c ++, c, linux, incorporado, threads, soquetes etc.). Pessoalmente, sei que, quando me coloco na situação de ter (ou querer) mergulhar em uma infinidade de correntes diferentes, me vejo nadando em correnteza muito rápido (ou melhor, muito devagar ). Talvez o que você realmente precise aqui seja o FOCO . E talvez uma dose saudável de priorização . Existe alguma maneira de relegar os potes menos importantes para o segundo plano e aumentar o calor do prato principal?

3. Você não está se divertindo. Quando o fogo se apaga, o motor a vapor está destinado a desacelerar. Você admitiu em sua postagem que seu moral sofreu um sério golpe recentemente. Infelizmente, você foi engolido pelo vórtice sugador de harmônicos negativos auto-reforçadores - uma força que pode destruir pontes . É uma espiral muito familiar: tarefa difícil -> estresse -> prazo perdido -> mais estresse -> mecanismo de enfrentamento deficiente -> mais estresse -> procrastinação -> prazos mais perdidos -> críticas / fofocas (reais ou imaginárias) - > ainda mais estresse. Você entendeu a foto. Isso raramente leva a qualquer lugar útil. Tome uma lição dos meus dias em rafting em águas brancas: quando você é sugado para debaixo d'água por uma corrente circulante na parte traseira de uma classe 4 rápida, seu colete salva-vidas NÃObóia você de volta à superfície. A melhor estratégia (embora não intuitiva) é encontrar o fundo do rio e sair da correnteza. Portanto, meu conselho para você é: encontre um terreno , cara (amigos, igreja, novos hábitos saudáveis, etc.) e use-o para se afastar da banheira de hidromassagem.

4. Você não está na sua zona. Michael Jordan fez um jogador de beisebol esfarrapado. (OK, ele ainda era melhor do que eu, mas definitivamente era um pouco menor.) Talvez "linux incorporado multithreading" simplesmente não seja o seu show. Mas o desenvolvimento de software é um campo extremamente amplo (como você bem sabe; cf # 2 acima). Sua empresa é ampla o suficiente para encontrar outro nicho? No meu último emprego, fui contratado como desenvolvedor de software embarcado. (Eu não tinha experiência nesse domínio, mas disse a eles que era um "aprendiz rápido".) Eu afundei rapidamente como uma pedra. Mas continuei trabalhando duro e continuei procurando problemas que eu faziasabe como resolver para eles. Como se viu, fui gradualmente capaz de migrar para novas responsabilidades nas quais pude brilhar e pelas quais recebi elogios consideráveis. Então, talvez você precise mudar sua marca.

O ponto é: se você for lento, há uma razão. Mas, ei - você é um engenheiro de software, cara! Depure você mesmo!

Seu chefe pode estar correto: você pode estar "com baixo desempenho" (mais sobre isso em um minuto). Mas pode não ser apenas o seu nível de competência que deve ser responsabilizado. Eu não acho que seria possível sugerir que forças fora do seu controle estão causando estresse, o que está afetando negativamente o seu desempenho.

Vamos dar uma olhada em alguns dos motivos pelos quais seu chefe pode estar trazendo isso à tona agora:

Cultura e Política

Pode haver forças além do seu controle exigindo que seu chefe agora expresse sua preocupação. É importante entender o sistema em que você está trabalhando. Seu trabalho é fazer com que seu chefe tenha uma boa aparência. A única maneira de fazer isso é entender as pressões sob as quais ele está.

Habilidade

É possível que a habilidade não esteja ao mesmo nível, como você diz abertamente. Aqui está o que eu faria nesta situação:

Obtenha feedback específico do seu chefe sobre como ele mede o desempenho. Você não está fechando tantos bugs quanto a pessoa X? Existe um número definido de bugs que você deve resolver? Se você está trabalhando sozinho, precisa garantir que as pessoas que medem seu desempenho o medem de maneira justa e não com base em alguma ideia preconcebida.

Se o seu desempenho for lento e baseado em uma lacuna real, identifique essa lacuna e coloque um plano detalhado junto com seu chefe, com o objetivo de eliminá-la.

Esta revisão também é uma boa oportunidade para mostrar que você não é feliz. É bom que você tenha identificado que não ama este trabalho. Mas descubra o porquê. Que parte do seu trabalho você gosta e o que não gosta? Pode ser que este trabalho não seja para você ...

Alguns ambientes de trabalho são impraticáveis. Vi ambientes em que ninguém poderia sobreviver (exceto aqueles que estavam no começo) porque muita coisa não era documentada e as perguntas eram tão veementemente desencorajadas.

Você realmente precisa ser honesto consigo mesmo com relação às expectativas e aos recursos fornecidos para ajudá-lo a atendê-las. O problema pode não ser você.

Você menciona que existem pessoas fazendo trabalhos semelhantes aos seus que, presumo, não estão tendo dificuldades, mas que têm mais de 5 anos de experiência em seus 2. Como você se sente em comparação com seus colegas? Eles são estrelas do rock que superam você completamente (a esse respeito) ou são como você? Talvez eles tenham acabado de conhecer o sistema quando era mais simples ... Você mencionou ter 8 anos de experiência em programação antes dessa linha de trabalho. Como você fez lá? Se você se saiu bem, isso deve lhe dizer uma coisa.

A parte que me impressionou é o fato de você se descrever como estando no escuro com relação a todos os bugs que aparecem no seu caminho. Pode ser que a base de código seja tão vasta e desconhecida que as expectativas possam não ser razoáveis.

Para você ter chegado o mais longe possível, significa que fez algo certo e tem algo a seu favor.

O ponto principal, eu acho, é que você precisa se sentir bem consigo mesmo e com o que está fazendo. E se isso significa seguir em frente, que assim seja.

Melhor seguir em frente do que ter um emprego arruinando sua vida.

Primeiro, observe: essa resposta pode se aplicar apenas a determinadas regiões onde é ilegal demitir um funcionário sem indenização. Dito isto...

Pode ser um caso de demissão construtiva e ilegal.

A tática é desmoralizar e diminuir a auto-estima de um funcionário até que ele saia do emprego. É uma maneira de a empresa economizar dinheiro por não ter que pagar indenização ou resolver o problema de ter que confrontar o funcionário e demiti-lo.

Ele quer falar comigo sobre por que sou tão lenta e por que minha taxa de correção de bugs é tão baixa.

Essa falha é muito ambígua. É impossível que um dos lados da parte afirme que o outro está errado. Você levou um mês para consertar um bug. E daí! Isso o coloca em uma posição defensiva, ao apresentar fatos para apoiar sua reivindicação de que um mês foi necessário. Dada sua habilidade, experiência e conhecimento atuais como fatores. Como empregador, é tarefa do empregador gerenciar o tempo e os esforços de seus funcionários. O empregador deve ser a pessoa envolvida no risco associado à correção dos erros. Não é o empregado. Ele sempre teve a opção de atribuir o bug a outra pessoa.

Se você é um contratado e afirma no seu contrato que será responsável pela correção de bugs, é uma história completamente diferente.

É errado o empregador reclamar que você está demorando demais? Absolutamente não, mas ele não pode responsabilizá-lo por isso, e ele não pode demiti-lo por isso. Ele pode lhe dizer: "Não temos mais bugs que exijam suas habilidades e você é dispensado", mas eles devem informar no momento em que surgir um novo problema que você poderá corrigir. Caso contrário, eles devem terminar com indenização. O que ele não pode fazer é fornecer um trabalho que você não pode lidar e depois reclamar. Eu acho que isso é ilegal.

Adoro programar e resolver problemas, mas realmente acho meu trabalho muito difícil.

Há uma grande diferença entre aceitar um emprego que você acha difícil e seu empregador oferecer um trabalho que é muito difícil. Se você acha que as tarefas atribuídas a você foram realizadas para desencorajá-lo a ter uma carreira na empresa, isso pode ser ilegal.

Na verdade, sou programador há cerca de 10 anos. Mas este é o meu primeiro trabalho de linux incorporado multithreading - estou aqui há 2 anos e é óbvio para todos que ainda estou lutando.

É por isso que acho que você se viu no meio de uma demissão construtiva. Eles não estão felizes com você, então empilham a porcaria em você até você sair.

E acho que fiquei tão desmoralizado e me sinto tão marginalizado que perdi muito do fogo que tinha no início do trabalho.

Um empregador é responsável por fornecer um ambiente de trabalho seguro e positivo. Sem mais informações (provavelmente pessoais), é difícil para quem está de fora dizer o que realmente está acontecendo aqui. Peça a um advogado de emprego para uma consulta gratuita. Eles poderão dizer se você está sendo jogado.

Referências

Não sou advogado, mas o Google encontrou alguns documentos discutindo o tópico Demissão construtiva que valem a pena ser lidos antes de você escrever sua opinião na segunda-feira. O ponto principal aqui é observar uma redução no salário, humilhação e mudanças repentinas na sua carreira na empresa.

Fatos relevantes atentos a:

• Falha em apoiar adequadamente um funcionário durante condições difíceis de trabalho
• Disciplina excessiva de um funcionário Impor uma mudança no local de trabalho dos funcionários a curto prazo
• Imposição de redução de ordenados ou salários

Perguntas e respostas legais: Demissão construtiva

Razões para pedir demissão construtiva

Wikipedia

elementos de uma demissão construtiva

Talvez você esteja sendo comparado a um dos programadores originais de um projeto. Sei que, como desenvolvedor original de um dos projetos em que trabalho, tenho uma enorme vantagem ao corrigir bugs. Eu não acho que seja por falta de documentação, é só que eu posso intuitivamente pular para problemas em potencial porque meu cérebro conhece todo o código.

Se você está sendo comparado a isso, simplesmente não está à altura. Sempre levará mais tempo para você se familiarizar com o projeto e não saberá onde estão todos os possíveis pontos de interação.

Li o seu comentário sobre não descobrir ferramentas e truques que outros programadores estão usando para resolver problemas. Talvez para a sua próxima correção de bug, você precise tentar a programação em pares. Isso pode ser incrivelmente útil. Se revezam dirigindo o teclado. Converse bastante .

Você pode usar um notebook ou um quadro branco para traçar caminhos de função, threads e vida útil do bloqueio, e marcar onde observa vários bits de comportamento e onde pode inserir novos probes.

Resolver esses tipos de problemas de encadeamento de baixo nível pode ser muito difícil e tenho muita simpatia por você. Eu tive que analisar vários gigabytes de arquivos de log antes para identificar um problema de duas linhas. E sabe de uma coisa? Fiquei olhando isso por dias antes de pedir ajuda a um engenheiro júnior que havia sido estagiário no ano anterior, e ele surgiu com uma nova abordagem e descobriu o problema em uma hora. Então, depois de dedicar algum tempo a um bug, coloque novos olhos nele. Isso pode ajudar muito!

Uma das disfunções de gerenciamento mais comuns nesse setor é não entender que a depuração é intrinsecamente difícil . Tenho quase 20 anos de experiência e ainda tenho que passar regularmente uma semana inteira descobrindo o erro de uma linha que faz o programa travar uma vez em cada cinquenta. E então, se meu gerente não entender essas coisas, ele me incomodará por levar uma semana para alterar uma linha de código.

O que você pode fazer sobre isso?

• Faça anotações ao depurar. Apenas sempre abra uma janela do editor e anote seu fluxo de consciência. Não precisa fazer sentido para ninguém além de você. Você pode achar que isso ajuda a depurar mais rapidamente, mas também significa que você tem algo concreto para apontar para demonstrar que não estava jogando Nethack a semana toda.

• Compare anotações com todos os seus colegas de trabalho. Quanto tempo normalmente leva para corrigir bugs? Seus bugs permanecem corrigidos? Com que frequência eles mudam uma coisinha e se vêem enterrados sob uma pilha de consequências em cascata? As respostas a essas perguntas lhe darão uma idéia de se você está realmente lutando em relação ao resto do departamento.

• Faça amizade com o pessoal de controle de qualidade e o suporte ao cliente. Eles são os que têm a melhor idéia de quão importantes são os bugs. Geralmente, isso tem pouca ou nenhuma correlação com a dificuldade dos bugs, para que você possa brincar um pouco com o sistema e tentar receber todos os bugs de alta importância e baixa dificuldade. (Isso não é realmente trapaça. Uma equipe bem organizada sempre procura esses bugs primeiro.)

• Se o seu chefe não fornece feedback adequado sobre o seu desempenho há dois anos consecutivos, esse é um problema a ser apresentado nesta revisão de desempenho e, depois, quando você recebe a resposta, para aumentar com o chefe do seu chefe. Seja educado e, especialmente, não permita que eles vejam como você está com raiva, mas receba críticas específicas por escrito.

Embora você goste de programar e resolver problemas, pode haver a questão de quão bem você está aplicando o que está aprendendo em outras áreas. Algum dos últimos doze erros corrigidos foi semelhante o suficiente para ajudar o usuário a corrigir um deles? Isso faz parte de uma retrospectiva do que você fez e quanto tempo levou para fazê-lo. Apenas uma ideia a considerar.

Em segundo lugar, eu examinaria como você está fazendo seu trabalho. Você está sendo interrompido regularmente e, ao tentar corrigir o erro A, é informado que os erros B e C são de maior prioridade? Considere com cuidado que tipos de mudanças na maneira como você faz seu trabalho podem ajudá-lo aqui, pois isso provavelmente faz parte do que seu chefe deseja saber.

Alguns locais de trabalho me disseram que não gostavam de quanto tempo levava para concluir um pouco do meu trabalho. É claro que esses eram os lugares onde, se eu fizesse uma coisa, 5 coisas novas seriam jogadas no meu colo e, portanto, era fácil ficar sobrecarregado. Embora eu possa não mais trabalhar lá, não tive uma boa solução para chamar minha atenção para algumas coisas, de modo que não sinto que estou tentando dominar mil coisas de uma só vez. Se eu puder saber algumas coisas importantes a serem feitas e como meu trabalho será julgado, então eu sou muito melhor do que se eu tivesse uma lista de "tarefas pendentes" com uma milha de comprimento e ninguém parece se importar se eu conseguir partes dele feitas. Assim, pode ser que haja um componente cultural nisso dentro da organização, embora eu tenha cuidado ao pedir que as coisas aqui mudem.

Depois de dois anos no trabalho, deve ser óbvio para todos (você, seu chefe, seus colegas) qual a sua posição. Ou seja, você nunca deve descobrir que está se saindo mal apenas uma vez por ano; um ambiente de trabalho ideal fornecerá feedback contínuo.

Enfim, sobre como depurar código multithread: você não mencionou se esse é o seu código ou de outra pessoa. Existem alguns novos depuradores e analisadores estáticos que podem lidar com simultaneidade. Mas, na verdade, conhecer os padrões será sua melhor aposta, pois você saberá o que procurar.

Se você entender como seções críticas e condições de corrida e impasse funcionam, estará em uma posição melhor para identificar coisas inesperadas. Se você vir "comunicação" entre dois threads sem variáveis ​​de condição, ou se os recursos forem mutexados sem uma ordem específica, ou se uma variável local for declarada staticsem motivo aparente, você terá um bug em potencial! Portanto, aprenda as melhores práticas do seu domínio e estará em uma posição melhor para julgar quando algo está fora do comum.

Não lute sozinho, a menos que você precise. Recrute colegas. Faça com que eles ajudem na caça aos insetos. Pergunte a eles sobre seu processo de pensamento e ferramentas. Talvez mencione isso em sua análise como parte de seu plano de melhoria. Se todos ao seu redor estão se saindo melhor nesse sistema , talvez eles saibam algo específico?

Acabei de me dizer pelo meu chefe que vou receber uma avaliação de desempenho negativa na segunda-feira. Ele quer falar comigo sobre por que sou tão lenta e por que minha taxa de correção de bugs é tão baixa.

Esteja ciente de que em qualquer empresa não disfuncional as coisas não acontecem nessa ordem. Se o seu chefe estiver preocupado com o seu desempenho, ele deve definir metas de curto prazo e conversar sobre os resultados para descobrir onde está o problema.

Em vez disso, ele decide fazer uma crítica negativa e descobrir o motivo. Parece que ele não está disposto a se envolver no problema, e ele só quer resultados na tabela.

Não tente resolver erros mais rapidamente. Procure avaliar sua capacidade, verifique como seus colegas trabalham, como eles sabem o que sabem e esteja ciente de que essa não é uma empresa ideal.

Quanto às dicas práticas, eu uso trechos de código e minha própria mediawiki para fazer anotações. Sempre tenho em mente quais livros ler a seguir e que direção seguir para continuar meu aprendizado. Aprender é o caminho para um emprego melhor e uma vida mais feliz.

Primeiro, um aumento de confiança:

Por que sofrer? Você pode facilmente encontrar um emprego em que eles pensem que você é "deus", apenas porque você pode fazer qualquer coisa incorporada ao Linux, independentemente da sua taxa de correção de bugs.

De qualquer forma, é impossível estabelecer um limite de tempo para caçar um bug. A caça a insetos é uma habilidade, sem dúvida, e a eficiência é altamente valiosa.

Você pode estar perdendo algum truque básico que os outros conhecem, o que o torna mais lento.

Por exemplo, se você e eu estamos trabalhando em algum middleware Linux, e estou usando o Valgrind para encontrar problemas de corrupção de memória e condições de corrida de dados, enquanto você está apenas confiando no gdb e no printf, provavelmente vou chutar sua bunda, mesmo que você é mais esperto que eu.

Além disso, como você entende a concorrência ? Se você está desenvolvendo há dez anos, mas a maior parte dessa experiência não foi com código multithread, isso pode ser um problema.

Você deve estudar o multithreading em detalhes: mais do que apenas saber como usar as APIs, mas realmente "obtê-las" em um nível profundo. Se você estiver fazendo programação multithread, você deve ser o desenvolvedor que pode olhar para uma base de código a uma milha de distância e identificar cenários de condições de corrida, impasses, inversões de prioridade, fome ...

Recentemente, li o livro Trabalhando Efetivamente com o Código Legado e isso me deu um impulso significativo de confiança ao lidar com um problema em qualquer base de código.

Se o código com o qual você está trabalhando for algo menos que perfeito, acho que este livro seria útil. Descobri que, na maioria das vezes, para corrigir um erro, primeiro preciso refatorar o código ao redor para entendê- lo e, depois que eu entender o código, e espero torná-lo testável, rastreando e corrigir o problema é menos uma provação. (Às vezes, até reescrevi o código apenas para entendê-lo, mas depois reverto minhas alterações para reduzir o risco de introdução de novos bugs. Depois insiro minha correção de bugs. Essa técnica é baseada em um truque do livro.)

Acho que minha sugestão aborda apenas parte do seu problema, e de certa forma indiretamente, mas vale a pena ler o livro, não importa o que aconteça, pois trabalhar com código legado é uma inevitabilidade para qualquer desenvolvedor.

Pergunte ao seu superior qual é a sua velocidade de correção de bugs e qual a velocidade média da equipe para corrigir bugs. Mais importante, pergunte a ele como é medida a velocidade de correção de bugs ...

Esse tipo de métrica não é realmente uma métrica; se fosse, seria ainda mais confiável que o LOC (embora medindo coisas diferentes). E sem uma medida adequada, não há razão para acusá-lo de qualquer coisa.

Reconheça que você trabalha COM empregadores e / ou cliente, NÃO para eles. Não hesite em mencionar isso nas entrevistas, apenas para esclarecer as coisas desde o início.

Você é um profissional com muito investimento em sua pequena empresa, ou seja, você mesmo.

Você está disposto a trabalhar enquanto houver um sindicato de interesses levando-o para fora da prateleira todos os dias.

Se essa propulsão não existir por um período de tempo, siga em frente.

Você está desperdiçando seu tempo e energia em um empregador que não mantém seu interesse / habilidades atualizadas / tarefas desafiadoras e / ou interessantes para você trabalhar. Esse é o trabalho da gerência. Fora isso, eles são pura sobrecarga .....

Mantenha sua paixão, pois essa é a chave.

Estive em situações semelhantes porque tinha medo de pedir ajuda. A julgar pelo que você disse neste comentário ...

"Mas o que é frustrante é que existem certas ferramentas / dicas / truques que eu só descobri depois de estar lá um ano e meio. Eu mudei de equipe para equipe (acho que porque eu estava com baixo desempenho) e estou descobrindo essas ferramentas 'ocultas' de vez em quando. "

... você pode ter tido o mesmo problema que eu. A depuração é tão fácil quanto escrever código que não requer tanta depuração em primeiro lugar. Observar outros desenvolvedores trabalhando com um problema de depuração pode ser altamente educativo. Peça ajuda a eles quando tiver problemas para resolver algo. Especialmente se você estiver cobrindo um terreno que não tinha antes. E faça-o idealmente antes que seja hora de entrar em pânico, porque você não está fazendo nada.

Dito isto, concordo com os comentários de que a gerência estava fazendo algo errado. Se alguém está lutando com alguma coisa, deve obter ajuda antes que a diversão negativa da revisão comece. Inferno, se alguém em uma equipe está lutando e nunca recebe ajuda, eu diria que todos os membros dessa equipe estão fazendo algo errado (embora isso possa ser um resultado direto de pessoas observando suas taxas de correção de erros excessivamente).

O que está faltando no OP é qualquer menção a um processo ou método repetível que está sendo seguido para resolver bugs.

Então, primeiro, documente o processo que você segue. Certifique-se de documentar o que cada etapa do processo deve alcançar.

Você pode descrever o processo como tendo tarefas como esta:

1. Certifique-se de entender exatamente qual é o problema que está sendo relatado.
2. Tente reproduzir o problema.
3. Comece a dividir o problema em pedaços menores
4. Pense nas possíveis causas do problema.
5. Teste essas hipóteses

Seria útil saber se os erros existem há muito tempo ou estão sendo introduzidos com alterações recentes. Se os erros foram introduzidos com alterações recentes, fazer revisões de código e / ou apenas ler o código que as pessoas estão criando pode ajudar.

Eu acho que se você pode definir claramente o problema, por exemplo, "Eu tenho problemas para pensar em hipóteses a serem testadas ao tentar resolver bugs", então você pode obter conselhos mais focados.