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

Com muita frequência, fico preso ao escolher a melhor decisão de design. Mesmo para pequenos detalhes, como definições de funções, fluxo de controle e nomes de variáveis, passo períodos extraordinariamente longos examinando os benefícios e as compensações de minhas escolhas.

Sinto que estou perdendo muita eficiência gastando minhas horas em detalhes insignificantes como esses. Mesmo assim, eu sei que posso mudar essas coisas se meu projeto atual não der certo, tenho problemas para decidir firmemente uma opção.

O que devo fazer para combater esse problema?

Duas regras simples:

1. Faça a coisa mais simples que possa funcionar.
2. Refatorar 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 responder às mudanças posteriormente.

Lembre-se de que provas futuras significam facilitar a alteração do código, não tentando prever todas as formas possíveis de alterar o código.

Normalmente, quando me sinto assim, significa que preciso tentar:

1. Levante-se, dê uma volta e verifique se toda a biologia está funcionando bem.
2. Vá 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ê possa conversar sobre o problema.

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

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

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

É melhor escolher uma solução decente e executá-la, do que ficar sentado sobre qual seria a melhor solução. A melhor solução é ilusória e, pior, subjetiva. Se os requisitos mudarem um pouco, sua solução pode ser pior do que uma solução que você descartou porque não era a melhor na época.

Também estou aprendendo a evitar a paralisia da análise, então parabéns para nós =) Isso geralmente acontece porque queremos fazer o "melhor design". Na realidade, o "melhor" está nos olhos de quem vê . Minha fórmula para evitar a paralisia da análise é aplicar o princípio de design suficientemente bom . Como eu faço isso? Eu trago variáveis ​​como restrições de tempo, agendamento 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, asseguro que seja testável e um aberto para extensão fechado para modificação (OCP)design também. O que quero dizer com testável e OCP? Bem, em vez de procurar o que eu considerava melhor, considerei um design que pode me dizer quando as coisas estão indo mal e tentar fazer apenas o código suficiente que me permita refatorar e melhorar mais tarde. Além disso, tente separar o código que será alterado pelo código que permanece o mesmo. A refatoração se torna mais fácil, porque o código que não deve ser alterado é mais seguro do seu futuro, você ou outra pessoa.

Que tal deixar seu instinto decidir por uma das opções? Isso deve ir muito rápido e combinar bem com o timeboxing , que a munição também propôs . Você pode tentar um limite de 1 minuto se as opções já estiverem estabelecidas ou 2 minutos se precisar defini-las primeiro. Ou o que parecer 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 com a possibilidade de escolher não-perfeitamente, aqui estão algumas idéias para abordar isso:

• Se houvesse uma opção com uma vantagem clara sobre as outras, você não se perguntaria qual escolher. Portanto, por esse raciocínio, sempre que você não tem certeza sobre alguma escolha em um assunto não muito complicado, isso indica que as opções são todas iguais; portanto, não há muito a perder apenas optando por qualquer um deles.
• Dito isto, a intuição não é aleatória, mas um palpite bastante bom e educado para a solução ideal. Muitas vezes, melhor do que aquilo que se poderia imaginar através de intermináveis ​​reviravoltas.
• Atendendo ao perfeccionismo, pode-se avaliar a rapidez da decisão maior que a idealidade da escolha ao avaliar semiconscientemente o desempenho. 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 tento imaginar como será a base de código muito mais à frente do que o necessário para superá-la. Faço a coisa mais simples possível que funcionará e depois seguirá em frente. Uma vez que o projeto tenha uma forma definida, as unidades de código repetitivo começam a se destacar e é fácil o suficiente abstrair os padrões repetitivos e simplificar o código.

Para superar sua relutância em decidir, aplique o timeboxing : defina um despertador para tocar em alguns 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, por isso não importa quais funções, nome da variável ou mesmo a grande arquitetura 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 de conclusão suficiente.

Por exemplo, quando eu escrevia o código de renderização, recebia um grande incentivo de conclusão porque sabia que, se eu continuasse com ele, veria o sistema em ação e pensaria em como eu era incrível ao texturar um quad, ou transformar uma vert. Mas agora que estou re-fatorando (tentativa 4, se você gostaria de saber), estou sofrendo porque dá muito trabalho e, mesmo que eu termine, vou ver o mesmo quad antigo. E eu realmente não quero ter que refatorar novamente e estou cansado de ver o mesmo velho quadriciclo repetidas vezes, e isso não é mais uma recompensa para mim.

Você precisa dividi-lo em componentes e se recompensar por terminá-los, mesmo que seja apenas com alguma E / S de console que mostre que está funcionando.

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

O problema com problemas mentais como esse é que eles não são fáceis de resolver, fazem parte de você e, obviamente, você se preocupa (talvez demais) com o seu trabalho, não tem confiança para concordar consigo mesmo, também inexperiente em considerar que sua primeira escolha estava certa o tempo todo, ou se estressa demais em acertar perfeitamente. Por que mais você se preocuparia com essas trivialidades ?!

Agora eu tenho problemas semelhantes, mas não tanto com código .. geralmente é o que ter para 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 pensei: por que não tenho problemas semelhantes com a codificação e acho que é simplesmente porque tenho um conjunto de padrões que uso regularmente. Se eu precisar de uma definição de função, é fácil .. estará na mesma linha que todas as outras definições de função que eu já codifiquei. Se eu precisar de um fluxo de controle, primeiro decido se preciso de um loop for ou while, e depois crio 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 recortar e colar meu código de fila 'padrão' (arquivado no último projeto em que trabalhei ou em qualquer um em que me lembro de usar uma dessas coisas). Resultado final ... Só me preocupo com coisas novas e, para ser sincero, é um prazer.

Portanto, meu conselho é começar a criar uma biblioteca de trechos de código - eu costumava enviá-los por e-mail para mim e colocá-los em uma pasta, mas o que quer que você trabalhe é o melhor - e então você começará a saber o que fazer todas as vezes. Você sempre acessará o código antigo que escreveu e resolverá o problema, pronto para o próximo problema. Você descobrirá que se tornou um desenvolvedor muito mais rápido (sério, esta é a única maneira de obter produtividade do programador) e, com sorte, encontrará tempo para os momentos divertidos, não para as coisas cotidianas sombrias que você já resolveu muitas vezes sobre.

Obviamente, a última parte de tudo o que é importante também - 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 ( inicie simples, refatorar ) e ammoQ ( timeboxing ):

1. Dê a si mesmo um prazo bastante rigoroso para uma primeira solução que simplesmente funcione. Por exemplo, 30 segundos para um nome de variável. Você pode primeiro criar algo como x, depois refinar string, nameaté que o tempo acabe.
2. Em seguida, prossiga para outras tarefas por um tempo especificado, por exemplo, 10 minutos.
3. Somente então permita-se outra caixa de tempo para melhorar ainda mais sua decisão, por exemplo,userHandle

Possíveis benefícios dessa abordagem:

• o conhecimento de voltar a isso mais tarde pode facilitar a abertura do problema por enquanto
• Enquanto continua outras tarefas, você pode simplesmente encontrar uma solução satisfatória sem vasculhar demoradamente
• depois de deixar a etapa 1 e seguir o fluxo da etapa 2 , pode ser fácil manter a etapa 3 realmente rápida, pois você deseja continuar com a etapa 2 e, assim, felizmente, basta escolher uma solução decente e aceitá-la

Quando eu fiz a pesquisa e não tenho a melhor opção, eu me dou um limite de tempo (geralmente 5 minutos) para escolher uma, e apenas passo adiante. Mesmo quando você se depara 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.

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

No caso a) Defina um prazo para apresentar opções razoáveis ​​a serem consideradas. Não decida qual ainda. No final do tempo, escolha uma (aleatoriamente, se não houver uma preferência clara) das opções identificadas e outro limite de tempo. Se nenhuma decisão clara for tomada no final do tempo, a já escolhida será. Comece a codificar e refatorar se você claramente entendeu errado. Se o chefe perguntar por que, diga "Eu joguei uma moeda, você tem um jeito melhor?"

No caso b) - você precisa de mais informações, e ficar sentado na sua grande gordura 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, faça perguntas, leia revistas técnicas. O que quer que você faça, não durma por muito tempo.

Freqüentemente, a melhor solução é tentar explicar sua decisão a um colega. No entanto, como você não deseja fazer isso com muita frequência, a próxima melhor coisa é pensar no papel - com um papel / caneta ou uma janela vazia do bloco de notas.

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

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

Embora nem sempre funcione, o processo de obter pensamentos fora da sua cabeça (RAM) e na mídia externa (o documento do bloco de notas) oferece mais liberdade para fazer novas conexões e ver a decisão sob diferentes perspectivas.

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

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

TLDR; Escolha uma solução razoável, melhore-a à medida que avança.

Isso também é relevante:

O professor de cerâmica anunciou no dia da abertura que estava dividindo a turma em dois grupos. Todos os que estavam no lado esquerdo do estúdio, disse ele, seriam classificados apenas na quantidade de trabalho que produziram, todos aqueles no lado direito apenas em sua qualidade. Seu procedimento era simples: no último dia de aula, ele trazia suas balanças de banheiro e pesava o trabalho do grupo "quantidade": cinquenta libras de panelas com classificação "A", quarenta libras com "B" e assim por diante. Aqueles classificados em "qualidade", no entanto, precisavam produzir apenas um pote - ainda que perfeito - para obter um "A".

Bem, chegou a hora da classificação e surgiu um fato curioso: os trabalhos de mais alta qualidade foram todos produzidos pelo grupo avaliado por quantidade. Parece que, enquanto o grupo "quantidade" estava ocupado produzindo pilhas de trabalho - e aprendendo com seus erros -, o grupo "qualidade" continuava teorizando sobre a perfeição e, no final, tinha pouco mais a mostrar por seus esforços do que teorias grandiosas e uma pilha de argila morta.

em http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

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 haveria alguém sentado como um coelho paralisado nos faróis. Eu simpaticamente perguntava qual era o problema e eles diziam "eu não sei como chamá-lo!".

Essas são as pessoas que devem procurar outra carreira. Como talvez você devesse.