Como faço para lidar com paralisia de análise?

Duas regras simples:

1. Faça a coisa mais simples possível.
2. Refatore continuamente.

Ao começar a fazer cada uma dessas coisas, você ganhará confiança de que pode tomar decisões simples agora sem comprometer sua capacidade de reagir às mudanças mais tarde.

Lembre-se de que a verificação futura significa tornar o código fácil de alterar, não tentando antecipar todas as formas possíveis de alterar seu código.

Normalmente, quando me sinto assim, preciso tentar:

1. Levante-se, ande por aí e certifique-se de que toda a biologia esteja funcionando bem.
2. Passe para um quadro branco e desenhe até que eu tenha uma sensação de confiança.
3. Encontre um "amigo de reclamação de design" com quem você pode simplesmente falar sobre o problema.

Se o problema envolver sintaxe e pequenos pedaços, então:

1. Satisfaça-se de que, mesmo que seja feio, está bem encapsulado em algum lugar e representa um tipo puramente local de lixo.
2. Adicione marcadores TODO ou apenas comentários que expliquem por que o código incomoda você.
3. Siga para a próxima tarefa.

É muito fácil pensar em inação. Mesmo que você consiga, de alguma forma, criar a melhor solução agora que poderia mudar facilmente antes de concluir o projeto, e depois?

É melhor escolher uma solução decente e executar com ela, do que ficar sentado e hesitante sobre qual seria a solução melhor . A melhor solução é ilusória e pior, subjetiva. Se os requisitos mudarem mesmo que levemente, sua solução poderá ser pior do que uma solução que você descartou porque não era a melhor no momento.

Estou aprendendo a evitar a paralisia da análise também, então parabéns para nós =) Isso geralmente acontece porque queremos fazer o "melhor design". Na realidade, "melhor" está no olho do observador . Minha fórmula para evitar a paralisia da análise é aplicar o princípio bom o suficiente . Como eu faço isso? Eu trago variáveis como restrição de tempo, cronograma e me pergunto qual é o design mais simples que pode fazer o trabalho (isso não significa o mais fácil) sem comprometer a qualidade, mas ao mesmo tempo, eu me certifico de que é um testável e um projeto aberto para extensão fechada para modificação (OCP) . O que quero dizer com testável e OCP? Bem, em vez de procurar o que eu considero melhor, considerei um design que pode me dizer quando as coisas estão indo mal e tentar fazer apenas código suficiente que me permita refatorar e melhorar mais tarde. Além disso, tente separar o código que irá mudar com o código que permanece o mesmo. A refatoração se torna mais fácil, porque o código que não deveria mudar é mais seguro do seu futuro você ou outra pessoa.

Que tal deixar o seu instinto decidir por uma das opções? Isso deve ser muito rápido e combinar bem com timeboxing , que também proposto . Você pode tentar um limite de 1 minuto se as opções já estiverem estabelecidas ou 2 minutos se tiver que defini-las primeiro. Ou o que parece apropriado (definido de antemão). Ao aprender a ouvir seu instinto, sua escolha intuitiva se tornará mais rápida e melhor com a prática .

Caso você seja atormentado por preocupações sobre a possibilidade de escolher não perfeitamente, aqui estão alguns pensamentos para abordar isso:

• Se houvesse uma opção com uma vantagem clara sobre as outras, você não se perguntaria qual delas escolher. Assim, por esse raciocínio, sempre que você não está decidido sobre alguma escolha em uma questão não muito complicada, isso indica que as opções são todas completamente iguais; então não há muito a perder apenas optando por qualquer um deles.
• Dito isto, a intuição não é aleatória, mas um bom bom palpite, para a solução ideal. Muitas vezes melhor do que o que se poderia imaginar através de uma busca sem fim.
• Atendendo ao perfeccionismo, pode-se avaliar a rapidez de decisão mais elevada do que a otimalidade de escolha ao avaliar semiconscientemente o desempenho de alguém. O que faz todo o sentido com escolhas sem importância, mas não é trivial ter em mente.

Boa sorte! :)

Eu acho que vai embora com um pouco de experiência. A maior parte da minha paralisia acontece porque eu tento imaginar como a base de código ficará muito mais à frente do que o necessário para superá-la. Eu apenas faço a coisa mais simples possível que funcione e depois prossiga. Uma vez que o projeto tenha alguma forma definida, as unidades de código repetitivo começam a se destacar e é bastante fácil abstrair os padrões repetitivos e simplificar o código.

Para superar sua relutância em decidir, aplique timeboxing : defina um despertador para sair em poucos minutos; atormenta sua mente até então, mas quando o alarme disparar, escolha a melhor opção que você encontrou até então.

Crie um protótipo. Lembre-se, um protótipo é feito para ser jogado fora, então não importa quais funções, nome da variável ou mesmo arquitetura grandiosa que você usa. Você acabou de construí-lo para provar que funciona.

Depois de criá-lo e jogá-lo fora, eu estaria disposto a apostar que você teria mais facilidade para tomar essas decisões.

Eu também sofro desse problema. O que eu diria é que você não tem incentivo suficiente para a conclusão.

Por exemplo, quando eu estava escrevendo código de renderização, tive um grande incentivo de conclusão porque eu sabia que, se eu seguisse com isso, veria o sistema em ação e pensaria em como eu era incrível para texturizar um quad, ou transformando um vert. Mas agora que estou re-factoring (tentativa 4, se você gostaria de saber), então eu estou sofrendo porque é muito trabalho e mesmo se eu terminar, eu só vou ver o mesmo quad antigo. E eu realmente não quero ter que refatorar novamente e estou cansada de ver o mesmo quadrilátero de novo e de novo, e isso não é mais uma recompensa para mim.

Você precisa dividi-lo em componentes e recompensar a si mesmo por terminá-los, mesmo que seja apenas com um i / o de console que mostre que está funcionando.

Eu estava lendo a sua pergunta e pensando as coisas ao longo da linha dos outros cartazes: você não é adequado para este trabalho; dê a si mesmo um limite de tempo; faça outra coisa por um momento. Depois de alguma reflexão, não tenho certeza se alguma das respostas é realmente útil

Agora eu tenho problemas semelhantes, mas não com código tanto .. geralmente é o que ter para o jantar .. pizza ou curry .. hmm ... pizza, mas depois curry é bom, mas eu me sinto como um curry, pizza é mais barata, mas você ganha mais curry, mas ... e assim por diante. :)

Então eu pensei - por que eu não tenho problemas semelhantes com codificação, e acho que é simplesmente porque eu tenho um conjunto de padrões que eu uso regularmente. Se eu precisar de uma definição de função, é fácil ... será na mesma linha que qualquer outra definição de função que eu já tenha codificado. Se eu precisar de um fluxo de controle, primeiro decido se preciso de um loop for ou while e, em seguida, criar o mesmo código antigo que usei na última vez em que precisei de uma dessas coisas. O mesmo vale para tudo, eu quero uma fila? Claro - vamos cortar e colar o meu código de fila 'padrão' (retirado do último projeto em que trabalhei, ou qualquer um que eu possa lembrar usando uma dessas coisas). Resultado final ... Eu só me preocupo com coisas novas e, para ser sincera, é um prazer.

Então, meu conselho é começar a criar uma biblioteca de trechos de código - eu costumava enviá-los para mim mesmo e colocá-los em uma pasta, mas o que você trabalha é melhor - e então você começará a saber o que fazer . Você sempre vai ao código antigo que você escreveu e elimina o problema, pronto para o próximo problema. Você descobrirá que se tornou um desenvolvedor muito mais rápido (seriamente, essa é a única maneira de ganhar a produtividade do programador) e, com sorte, encontrará tempo para os momentos divertidos, e não para o dia-a-dia triste que você já resolveu muitas vezes acabou.

Naturalmente, a última parte de tudo isso também é importante - quanto mais trabalho você tiver, menos luxo terá para gastar tempo pensando.

Aqui está uma estratégia que combina as sugestões de Rein Henrichs ( começar simples, refatorar ) e ammoQ ( timeboxing ):

1. Conceda um limite de tempo bastante rigoroso para uma primeira solução que simplesmente funcione. Por exemplo. 30 segundos para um nome de variável. Você poderia primeiro criar algo como x , depois refiná-lo para string e, em seguida, name até o tempo acabar.
2. Em seguida, continue com outras tarefas por um período especificado, por exemplo, 10 minutos.
3. Só então, permita-se outra caixa de tempo para melhorar ainda mais a sua decisão, por ex. codificar%

Possíveis benefícios desta abordagem:

• o conhecimento de voltar a isso mais tarde pode aliviar o desapontamento do problema por enquanto
• enquanto continua com outras tarefas, você pode encontrar uma solução satisfatória sem vasculhar o tempo
• depois de deixar o passo 1 e estar no fluxo do passo 2 , pode ser fácil manter o passo 3 realmente rápido, pois você deseja continuar com o passo 2, e assim, felizmente, basta escolher uma solução decente e aceitá-la

Quando eu fiz a pesquisa e não tive nenhuma melhor escolha, eu me dou um limite de tempo (geralmente 5 minutos) para escolher uma, então apenas avance com ela . Mesmo quando você se deparar com obstáculos, neste momento, não há garantia, você não teria atingido um obstáculo igual ao tomar uma decisão diferente. Não consigo pensar em um momento em que me arrependi da minha decisão.

Normalmente, o motivo pelo qual você não pode decidir é que a diferença é insignificante ou você não tem informações suficientes.

No caso a) Defina um limite de tempo para propor opções razoáveis a considerar. Não decida qual deles ainda. No final do tempo, escolha uma (aleatoriamente, se não houver preferência clara) das opções identificadas e outro limite de tempo. Se nenhuma decisão clara for tomada no final do tempo, a escolhida já é. Comece a codificar e refatorie se você errou claramente. Se o chefe perguntar por que, digamos "eu joguei uma moeda, você tem um jeito melhor?"

No caso b) - você precisa de mais informações, e ficar sentado com seu grande e gordo A .... o dia todo não vai fornecer isso. Saia do modo de design e entre no modo de coleta de informações. Protótipos, fazer perguntas, ler revistas técnicas. Seja o que for, não durma muito tempo.

Muitas vezes, a melhor solução é tentar explicar sua decisão a um colega. No entanto, como você não quer fazer isso com muita frequência, a melhor coisa a seguir é pensar no papel - seja com papel / caneta ou com uma janela vazia do bloco de notas.

Comece escrevendo qualquer coisa - só para entrar no ritmo da escrita. Em uma janela de bloco de notas, você pode simplesmente digitar "Estou pensando no papel" e depois continuar com um fluxo de consciência. Depois de alguns segundos, você estará no ritmo da escrita, então pressione enter algumas vezes e comece a explicar seu dilema.

Indique o problema, indique as possíveis soluções, o que há de bom em cada uma, etc.

Eu sofro do mesmo problema. Para pequenos problemas, a maneira que eu tento lidar com isso é ir com o primeiro design que eu acho que não é estúpido. Não adianta tentar encontrar um design ideal; É difícil, senão impossível, raciocinar sobre todas as nuances de qualquer design que você possa imaginar sem escrevê-lo. Conforme você codifica, descobrirá que pode fazer pequenas melhorias. Feito corretamente, acho bastante fácil convergir em uma solução razoavelmente boa dessa maneira.

Para problemas maiores, acho que há mérito em pensar em suas opções primeiro, mas no tempo limite. Grandes problemas têm grandes espaços de solução, você não pode avaliar todas as possibilidades, nem você deve tentar.

TLDR; Escolha uma solução razoável, melhore-a conforme você for.

Isso também é relevante:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

de link .

Eu nunca entendi isso. Quando eu era instrutor, eu dizia algo como:

"OK, create an integer variable and assign the return value of strlen() to it."

Não é muito complicado, você pode pensar, e 95% das pessoas escreveram algo como:

int x;   // or y, or len, or whatever
x = strlen( s );

Mas, ocasionalmente, havia alguém que se sentava como um coelho paralisado nos faróis. Eu simpaticamente perguntaria qual era o problema, e eles diriam "não sei como chamá-lo!".

Estas são as pessoas que devem procurar outra carreira. Como talvez você deveria.