Eu tive o (provavelmente) mesmo problema há muitos anos, durou alguns anos e eu o superei. Talvez seja de seu interesse saber como eu consegui isso, mesmo que não tenha certeza de que meu caminho também se aplique a você.
Você também deve dar uma olhada aqui: As sete etapas da especialização em engenharia de software Isso mostra que a produtividade é em grande parte um efeito colateral do nível de habilidade. Pode ser que você ainda esteja em algum momento entre os estágios 3 e 4 da tecnologia que está usando atualmente (a proficiência em habilidades depende da tecnologia, você pode dominar algumas tecnologias enquanto ainda aprende outras).
Agora começo com o testemunho biográfico.
Um pouco de contexto. Tenho 47 anos. Comecei a programar aos 12 nos anos 80. Enquanto estava no ensino médio, também trabalhei como programador profissional de meio período. Basicamente, não me deu tanto dinheiro, apenas o suficiente para comprar hardware, mas eu gostei e aprendi muito. Aos 18 anos, iniciei um aprendizado formal de Ciência da Computação.
Como resultado, quando completei 20 anos, sempre que iniciei uma tarefa de programação, conheci muitas maneiras de resolver os problemas apresentados e estava muito consciente dos muitos parâmetros e armadilhas existentes, além das desvantagens e limites de qualquer método.
Em alguns momentos (digamos, cerca de 26 anos), tornou-se realmente difícil para mim escrever qualquer programa. Havia tantas possibilidades abertas que eu não pude mais escolher entre elas. Por alguns anos (faça 6), parei de programar e me tornei redator técnico de notícias.
Eu nunca parei totalmente de tentar programar, no entanto. E em algum momento voltou. A chave para mim foi a programação extrema, mais especificamente o princípio da simplicidade: "escreva a coisa mais simples que possa funcionar".
Basicamente, me forcei a não me importar com a eficiência do código (esse era o meu principal obstáculo, evitava designs ineficientes), mas seguia o caminho mais fácil. Também me forcei a me importar menos com os erros e atrasar o tratamento dos erros para mais tarde, depois de escrever testes que aumentavam o erro (na verdade, isso é TDD).
Isso é algo que aprendi quando estava escrevendo. Quando não sei o que escrever, ou soube que o que estava escrevendo era ruim . Apenas continue. Na verdade, escreva as coisas ruins. Acabarei corrigindo isso mais tarde. Ou se é realmente tão ruim apagá-lo e reescrevê-lo, mas é mais rápido escrever coisas duas vezes que escrevem algo perfeito da primeira vez.
Realmente, é muito provável que um código que você considere bom na primeira gravação precise de tantas melhorias quanto de um código realmente ruim.
Se você seguir o caminho da Simplicidade, também receberá um bônus adicional. Você aceita facilmente remover / alterar o design / codificação inicial. Você tem uma mente mais flexível.
Também adquiri o hábito de colocar um comentário temporário no código, explicando o que não estava fazendo agora e pretendia fazer mais tarde, quando o código fosse funcional no caso de uso normal.
Também participei de um XP Dojo e pratiquei katas de código com outros programadores para internalizar as práticas do XP. Ajudou. Tornou os métodos formais acima instintivos. A programação em pares também ajudou. Trabalhar com jovens programadores dá um impulso, mas com a experiência, você também vê o que eles não vêem. Por exemplo, no meu caso, muitas vezes os vejo se engajar em projetos excessivamente complicados e conheço o pesadelo que pode levar a isso. Foi assim. Fiz isso. Teve problemas.
O ponto primordial para mim é manter o fluxo. Ser rápido é realmente bem-sucedido em manter o fluxo.
Agora estou de volta como programador profissional e acredito que sou melhor e mais rápido com uma compreensão mais profunda do que estou fazendo. Praticando TDD Eu ainda posso ser um pouco mais lento do que quando eu era um touro jovem (e não testou nada), mas também não tenho medo de refatorar e certamente gasto muito menos tempo depurando (quase sem tempo, diminuindo 10% do tempo) )
Resumindo: superei meu código de bloqueio usando métodos ágeis (XP), buscando simplicidade, refatoração e praticando para tornar isso instintivo. Funcionou para mim. Não tenho certeza se pode ser generalizado para mais ninguém.
Em termos de nível de aquisição de habilidades, aprendi principalmente a aceitar que toda vez que mudar de tecnologia (aprender novo idioma, nova estrutura etc.), passarei por um estágio em que estou desacelerando. Isso é normal e acabará superando isso. Eu também posso compensar isso com boa metodologia e habilidades de programação de uso geral, e isso não será um problema.
