Lidar com a frustração quando as coisas não funcionam [fechado]

Você sempre tenta implementar algo simples, mas por algum motivo estranho isso não funciona.

Então você tenta uma solução possível, mas outra coisa não funciona. Você continua tentando soluções diferentes, mas sempre que algo diferente não está funcionando.

Toda vez que você aproxima um passo, você também tem um (ou mais) passo a mais para resolver esse problema e agora faz 3 horas quando isso deveria levar 10 minutos. E ainda não está resolvido.

Não há ninguém na sua empresa que possa ajudar, e você está prestes a colocar seu punho na tela.

Nesse ponto, você está tão frustrado que não consegue mais pensar no problema com clareza. O que você deve fazer neste momento? Ou o que você pode fazer para evitar chegar a esse ponto?

Embora este seja um problema real, não é específico para programação. No entanto, é tão importante para o IMHO que merece um lugar neste fórum.

Minhas sugestões: faça uma pausa . Faça uma caminhada, medite, durma, faça atividade física * - faça algo completamente diferente para permitir que seu cérebro relaxe e saia da rotina mental , enquanto deixa seu subconsciente trabalhar em paz no problema. Geralmente, ele fornece resultados surpreendentemente rápidos - ele só precisa informar sobre isso. Mas, embora sua mente consciente esteja repetindo desesperadamente os mesmos ciclos de pensamentos repetidamente, ela não será capaz de ouvir mais nada.

o que você pode fazer para evitar chegar a esse ponto?

Técnicas de relaxamento e atenção plena são a chave para superar as reações ao estresse e permitir que sua mente se concentre claramente. E praticar isso realmente compensa. Quando alguém é experiente nisso, ele já pode perceber o nível de estresse subindo antes que a frustração possa assumir . Então, pode-se interromper o ciclo de pensamentos, por exemplo, respirando fundo algumas vezes ou praticando alguns minutos de relaxamento. Isso pode ser tudo o que é necessário nesse momento.

* beije seu parceiro, acaricie seu animal de estimação - sugestões da minha esposa :-)

agora faz 3 horas quando isso deveria levar 10 minutos.

A palavra mágica é deveria . Retire isso do seu vocabulário.

Quem disse que deve demorar 10 minutos? Quem especificamente? Qual foi a base factual para a reivindicação deles?

Se você já fez isso três vezes antes, e cada vez que estava perto de 10 minutos, você tem uma base racional para um dever .

Se você nunca fez isso antes, dizer que deveria é apenas se preparar para o fracasso. Você deve parar de usar deveria hoje.

Encontre alguém para usar como caixa de ressonância

Mesmo que ninguém tenha experiência exatamente no que está trabalhando, é uma boa ideia falar sobre essas coisas com frequência. Apenas o simples ato de usar alguém como caixa de ressonância pode fazer sua mente começar a girar. Você se verá pensando em coisas novas para tentar. Também aliviará seu estresse ao desabafar um pouco e potencialmente fazer um novo amigo. Também é saudável, em geral, que a equipe se sinta à vontade em compartilhar e se compadecer para gerar uma atmosfera orientada para a equipe para resolver esses tipos de problemas.

Afaste-se por um tempo e faça outra coisa. Tenha uma boa noite de sono e volte ao problema pela manhã.

Além disso, não se bata. Sua estimativa de dez minutos claramente não está correta, e isso acontece o tempo todo.

Eu tenho alguns passos quando chego a esse ponto. Normalmente, consigo descobrir uma solução se der um tempo para dar um passo atrás e refletir.

Etapa 1: Afaste-se do problema e limpe sua cabeça. Volte quando não estiver frustrado e consiga olhar para ele com uma mente renovada.

Etapa 2: volte para o código e veja se houve alguma coisa que você perdeu. Peça a alguém que venha e seja um segundo par de olhos, se você não puder fazer cara ou coroa.

Etapa 3: remova o código da equação. Qual é o problema que você está tentando resolver? Escreva em um pedaço de papel ou quadro branco. Converse com o problema com alguém para obter suas opiniões sobre o problema e a solução.

Etapa 4: entre em contato com a comunidade para ver se eles têm uma solução ou se alguém já atingiu o mesmo muro.

Basicamente, eles podem ser resumidos como 'Pare de invadir e se afaste do código'.

Gostaria de fazer uma pergunta aqui e pedir à comunidade que o resolva. Menos estressante assim.

Eu tenho um tipo diferente de solução - DORMIR !!

Quando você está frustrado com um problema, não consegue sair facilmente dele. Portanto, é melhor se você se sentir tão cansado tentando resolver o problema e depois adormecer.

Ao acordar, você terá uma nova sensação e, novamente, poderá pensar claramente no problema. Eu faço isso algumas vezes.

Encontrar algo para ajudar a recuperar a confiança é o que costumo fazer quando chego a esse ponto. Isso pode ser resolver um quebra-cabeça de Sudoku ou Kenken, executar algumas tarefas administrativas irracionais, como preencher minha folha de ponto ou sair para dar uma volta. A chave aqui é que eu tenha uma sensação de conquista em qualquer pequena distração lateral que me ajude a me animar o suficiente para voltar ao cavalo e cavalgar no azul selvagem do outro lado, para misturar algumas metáforas lá.

Quanto a evitar ficar tão ruim, eu provavelmente sugeriria ter alguma estratégia de boxe para que, se você acredita que algo leva 10 minutos e, de repente, uma hora depois, sem muito progresso, eu pare e tenha uma pequena pausa ao invés de tentar continuar batendo minha cabeça contra a parede.

Eu tenho um nome especial para esse tipo de situação: batalha épica de programação .

Se eu não tive pelo menos uma batalha épica de programação com uma linguagem ou ferramenta específica de programação e resolvi o problema, não posso dizer para mim mesmo que posso usar essa linguagem ou ferramenta de programação.

Portanto, existe a minha solução: mentalize-a como uma luta e um teste de coragem e resistência . Se não consigo resolver o problema, " vivo para lutar outro dia ".

Pode parecer um pouco ridículo, mas será mais divertido e gratificante pensar nisso nestes termos (como se fosse algum tipo de jogo que você deve vencer) em vez de sofrer todo o caminho, porque você precisa enfrentar o fato de que você não sei tudo .

Bem ... acho que você precisa de uma nova carreira ou de um conjunto completamente novo de expectativas. Embora certamente não seja frequente, levar 3, 4, 8, 10 ou 40 horas para fazer o que você originalmente pensava que seria um trabalho de 10 minutos certamente não é incomum no negócio de software. Tenho certeza de que a maioria dos desenvolvedores que trabalham em algo de complexidade moderada tiveram tarefas de 2 dias se transformando em tarefas de 1 mês depois que se aprofundaram e entenderam o problema.

Parte de ser um bom desenvolvedor envolve ser paciente; caso contrário, o computador vencerá e você acabará incorporando algum tipo de truque de correção rápida que mal parece funcionar, mas inevitavelmente quebrará algo em que você não pensava. Se pequenos atrasos causam tanto estresse, você provavelmente não deveria estar nessa linha de trabalho.

Duas sugestões:

1. A pessoa mais inteligente que eu conheço, que tem dois doutorados e tem o cargo "Pesquisador", em uma pequena empresa privada, diz isso

   Se você pensa sobre isso há 15 minutos e não tem a resposta, está fazendo errado.

   Pare de pensar nisso.

   Tirar uma soneca. (dê um passeio ou algo assim)

   A resposta estará lá quando você acordar.

2. Obtenha o livro de David J Agan "Debugging" . Provavelmente, ele ensinará mais sobre depuração, para que, quando as coisas não funcionem, você possa depurá-la rapidamente.

Sempre que me deparo com algo que não está funcionando, lembro-me sempre desta citação:

Quando você estiver no inferno, continue andando, pois é a melhor coisa que pode ser feita nesse momento.

Faça uma pausa, tente se refrescar e se concentre no problema com um novo nível de energia.

ecoando as recomendações de outras pessoas:

• essa situação é quase sempre algo trivial que você simplesmente não vê ; dar um tempo
• outro par de olhos ou até mesmo explicar o problema ao seu gato pode ajudar

e adicionando:

• reexamine suas suposições, especialmente as não declaradas; é provável que você esteja latindo para a árvore errada
• inverta a situação: assuma que o comportamento atual é o resultado desejado, então o que você teria que fazer com o código para que isso acontecesse?
• escreva algum código de teste (declarações ou log ou pontos de interrupção condicionais - mantenha-o simples) para verificar suas suposições ao longo do caminho da execução

Às vezes, é melhor não apenas tentar solucionar um problema. Reserve um tempo e escreva em pseudo-código o que você precisa fazer. Sei que há pressão para que as coisas sejam feitas o mais rápido possível, mas, pelo que vi, esse estilo de codificação leva ao tipo de situação que você descreve. Se alguém escrever um código que funcionará apenas com um pequeno conjunto de condições e que esse conjunto seja alterado, o código interromperá ou fará coisas inesperadas.

Além disso (eu odeio admitir que meus professores estavam certos nisso ...), a documentação e os testes de unidade ajudam. Isso tornaria mais fácil saber o que uma seção de código lançará, dado o conjunto de entradas. Então, seria mais fácil ver que efeito uma alteração na entrada de seções causará.

Fadiga ou falta de sono nunca é um problema para mim. Estou mais frustrado com a falta de organização dentro do setor como um todo e, em geral, com os baixos padrões que estabelecemos para nós mesmos. Aqui estão cinco coisas que me frustram:

1. APIs que são complicadas em design. É como aprender uma nova linguagem de programação. De fato, algumas APIs são muito mais difíceis de aprender do que aprender novas linguagens de programação. Admiro sua inteligência, mas você poderia ter me poupado tempo colocando na documentação que eu precisava de um doutorado em engenharia de software ou ciência da computação para entendê-lo.

2. Falta de boa documentação. Nunca consigo superar o fato de que muitos designers de API gastam muito tempo criando uma API apenas para lançá-la com o mínimo de documentação. Obrigado, mas como faço para usar isso? O que fazer nessa situação? etc.

3. Implementações proprietárias. Algumas implementações proprietárias estão bem, mas se existirem padrões, para o bem da humanidade, siga esses padrões. Nada mais frustrante do que gastar tempo imaginando por que algo não funciona apenas para descobrir que a implementação não segue os padrões normais.

4. Ambientes em caixa de areia / Restrições. Ok, talvez isso ajude a manter as pessoas más fora, mas, na minha opinião, as restrições sobre o que um programador pode fazer apenas limitam a criatividade e o progresso tecnológico. Muitas das grandes idéias que tive foram destruídas depois de descobrir que não tenho permissão para fazer algo. O setor de programação é realmente feito para produzir aplicativos do dia a dia, não um software inovador e inovador. Portanto, se você decidir ser um programador, estará realmente escolhendo ser um grunhido dos dias modernos, a menos que queira se tornar um acadêmico solitário.

5. Discussões modernas. As pessoas hoje ainda debatem sobre a feiúra dos parênteses Lisp, ou o mérito da limpeza de Pythons, ou como algumas línguas como Cobol ou Fortran estão se extinguindo, etc. etc. É sobre isso que debatemos? Vamos falar sobre paralelismo, ou melhores maneiras de projetar sistemas mais seguros, ou como a programação lógica pode melhorar nossas vidas. Vamos parar de pensar como codificadores e começar a pensar como designers do mundo de amanhã.

Então, eu pessoalmente não programa muito mais devido a essas frustrações. Até que o setor decida que deseja fazer mais do que apenas criar o próximo Facebook ou reinventar o processador de texto, estou pronto. Vou deixar para vocês. Honestamente, nenhuma ofensa significava, é um bom dinheiro.