Por que pensar em um bug às vezes ajuda a resolvê-lo? [fechadas]

Ontem, passei boa parte da tarde tentando consertar um bug, que achei trivial. Eu estava andando em círculos, sem ter idéia do que estava errado. Reescrevendo grandes partes do código. Verificando SO. Ainda sem alegria.

Então fui para casa, passei com o cachorro, assisti um pouco de TV e pouco antes de dormir, bingo, percebi o erro óbvio que estava cometendo. Esta manhã demorou cerca de 10 minutos para consertar.

Enquanto estava em casa, não estava pensando ativamente no problema. No entanto, sair da situação me permitiu resolvê-la.

Não é a primeira vez que isso acontece, e eu sei que é uma maneira bastante comum de resolver um problema de programação. Eu até ouvi falar de pessoas sonhando com as respostas.

Por que isso funciona?

Talvez o mais importante seja, existe um bom guia sobre quando você deve interromper um problema, quanto tempo deve ser o intervalo e depois de quanto tempo a saída de um problema deixa de ser eficaz?

Suponho que estou tentando descobrir como otimizar esse processamento subconsciente (ou o que quer que esteja acontecendo)

Estar muito focado em um problema impede que você dê um passo atrás. Ao depurar seu código, você tende a repetir desnecessariamente os mesmos testes.

Quanto mais você tenta, mais você falha e fica muito frustrado. Maior estresse e frustração pioram as coisas.

É por isso que, com frequência, um colega pode, por acaso, olhar por cima do ombro e apontar o problema (e a solução) em alguns segundos.

Eles não estão no mesmo estado mental que você.

Costumo tentar parar de cuidar de um certo período de tempo e voltar com uma mente mais calma algumas horas depois.

Mas a técnica mais poderosa é apenas ... pedir ajuda .

Se você está trabalhando em um problema há algum tempo, sua mente segue os padrões que você configura durante o desenvolvimento. Em outras palavras, você desenvolve "pontos negros" temporários para coisas fora do quadro mental que você cria.

Tirar sua mente do problema por um tempo ajuda a remover esse filtro e permite ponderar as coisas sem o filtro no lugar.

O que muitas vezes me ajudou em casos como esses é explicar a outra pessoa por que deveria funcionar (quando não funciona) - normalmente, no meio da explicação, você perceberá onde errou no raciocínio ou qual etapa perdeu.

Além de desenvolver um filtro mental durante o trabalho de desenvolvimento, o seu cérebro é massivamente multiencadeado e muitas vezes continua passando por um problema como parte de processos inconscientes. Às vezes, uso isso aprendendo tudo o que posso sobre um problema em uma tarde e deixando o problema repousar por um dia ou dois antes de trabalhar em uma solução.

Eu não sou psicólogo, mas quando você está concentrado demais em um único problema (encontrar o bug), tende a perder a visão para o sistema maior. Mas muitas vezes a resposta não é "lá em baixo" onde você está procurando atualmente, mas em outro lugar - que você não pode ver naquele momento.

Então, o que você realmente precisa fazer é sair das trincheiras e começar a examinar todo o sistema de um ponto de vista mais geral - novamente. A pessoa tende a ignorar esse fato pensando: "Eu realmente sei que está aqui, apenas não o encontrei ainda". Isso acontece com todos nós, o tempo todo. Chego até ao ponto em que sei "Não consigo encontrar o bug usando uma boa técnica de depuração, por isso deve estar em outro lugar" e ainda assim não toma a coisa certa e faz uma pausa - o cérebro humano é tão coisa engraçada.

No entanto, realmente não exige muito do que você faz - seja no banheiro, conversando com um colega de trabalho ou passeando com o cachorro. Eu costumava ir a uma loja próxima para comprar alguns doces quando estava preso e assim que colocava minha jaqueta na solução entrava na minha cabeça - quase sempre. Também pode ser bom beber muita água durante o tempo que você estiver programando. Obriga você a fazer uma pausa de vez em quando para visitar o banheiro e zap, há a razão que o força a sair das trincheiras.

Pela minha experiência pessoal e pelo que testemunhei nos desenvolvedores juniores que treino, todos abordamos um problema com suposições e expectativas. Assumimos que a função x executa a tarefa y para produzir o resultado z. Sempre mudou, então por que isso deveria mudar? À medida que nos concentramos cada vez mais em um problema, assumimos que abordamos o básico e o problema deve ser realmente muito mais complicado do que quando o abordamos originalmente. Anexe o cansaço a uma lista crescente de coisas que supomos verdadeiras, mas que ainda não foram verificadas, e você se prepara para um momento completo de "WTF" mais tarde.

É apenas mais tarde, quando você se desconecta do problema, que as suposições podem ser descartadas e refazidas. Além disso, geralmente lidamos com um problema por trás de um problema diferente que acabamos de resolver. Consertei A, mas ele quebrou B, agora preciso consertar B. Portanto, já temos um momento e uma direção em que estamos viajando (o que torna nossas suposições ainda mais difíceis de desassociar). Quando você volta à solução do problema B, o problema A não está mais fresco em sua mente, bloqueando possíveis possibilidades. Você é capaz de resolver o problema sem preconceitos, e isso abre novos caminhos de pensamento e novos ângulos de visão do problema.

Agora, sempre que um júnior me pede ajuda, eles sabem que a primeira pergunta que precisam responder é "Quais são suas suposições?". Mesmo tentar responder a esse problema pode ajudar a remover você de seus bloqueios mentais.

Eu acho que seu cérebro, como músculos, fica cansado. Fazer uma pausa permite que ela descanse, complete com oxigênio / combustível, etc. e comece a trabalhar novamente.

Sair para passear ou fazer exercícios geralmente é uma boa abordagem quando você está realmente preso a alguma coisa. Mesmo se você não tiver um momento "eureka", geralmente poderá voltar e adotar uma nova abordagem para resolver o problema.

Eu gosto de chamar isso de tempo de incubação de idéias e problemas.

Sua subconsciência ainda continua a processar o problema da sua consciência em uma abordagem não linear. Isso é muito semelhante ao que acontece quando você aprende algo novo antes de tirar uma soneca. Sua mente tem tempo para 'desfragmentar' as informações de maneiras que possam ser abordadas com maior flexibilidade.

Além disso, outra dica útil para superar o travamento de um bug é chamada de eliminação de bugs confessional . É aqui que você aborda outra pessoa que não conhece o problema e começa a explicar o problema. Acho com mais frequência que, ao dizer o problema em voz alta, a solução vem à mente.

confira estes links psicológicos: dicas de criatividade e problemas com cochilos

" Às vezes todos nós somos picados por uma rosa . Infelizmente, quando nos concentramos tanto na dor que esquecemos da beleza da rosa."

Corrigi vários bugs críticos em minha carreira, durante o banho.

Eu não sou psicólogo, mas acho que a diferença é:

• sentado em frente ao computador, vejo códigos-fonte, pontos de interrupção, printfsaídas ...

• no banheiro, códigos correm na minha mente.

Eu experimentei o mesmo fenômeno e o atribuí a olhar para o problema com uma perspectiva diferente, à medida que passo o tempo longe dele (mais tempo afastado implica uma perspectiva mais distante, aproximadamente).

Mas há outro truque que acho que realiza a mesma coisa na maioria das vezes: explicar o código a um colega de trabalho. Não é para eles pegar o seu bug, embora possam; é forçar você a dar um passo atrás e explicar a lógica do código em todos os níveis relevantes. Eu nunca (apesar de um aviso justo - o tamanho da amostra é limitado) fui capaz de resolver subconscientemente um bug que escapou desse tratamento de descrição para colega de trabalho.

Recentemente, tenho usado a técnica pomodoro, graças a uma sugestão de alguém neste site, e acho que ela fornece uma boa resposta para sua pergunta sobre o tempo e a duração dos intervalos. Basicamente, você trabalha focado em um problema por 25 minutos, seguido de um intervalo curto de 3-5 minutos e depois de um intervalo mais longo a cada 4 ciclos. Eles citam alguns estudos para apoiá-lo, mas, curiosamente, achei esses intervalos muito eficazes.

Eu pensava que os intervalos de 25 minutos me impediriam de "entrar na zona", que as pessoas afirmam levar 15 minutos ou mais. Pelo contrário, com esse tempo, chego à zona quase imediatamente. Eu acho que é porque é muito mais fácil evitar me distrair quando sei que só preciso mantê-lo por 25 minutos. Também é mais fácil adiar interrupções externas por apenas 25 minutos. Era muito difícil antes, quando eu estava tentando prender por 4 horas de trabalho antes do almoço.