Eu tive o (provavelmente) mesmo problema há muitos anos, durou alguns anos e eu superei. Então, talvez seja de algum interesse para você saber como consegui isso, mesmo que não tenha certeza de que o meu caminho também se aplica a você.
Você também deve dar uma olhada aqui: Os sete estágios do conhecimento 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 ponto entre o estágio 3 e o estágio 4 na tecnologia que você está usando atualmente (proficiência em habilidades depende da tecnologia, você pode dominar algumas tecnologias enquanto ainda aprende outras).
Agora eu começo com um testemunho biográfico.
Um pouco de contexto. Tenho 47 anos. Comecei a programar em 12 nos anos 80. Enquanto cursava o ensino médio, também trabalhei como programador profissional em meio período. Basicamente, isso não me deu muito 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 fiz 20 anos, sempre que comecei qualquer tarefa de programação, eu sabia muitas maneiras de resolver os problemas dados e estava muito consciente dos muitos parâmetros e armadilhas nas mãos, e desvantagens e limites de qualquer método.
Em alguns pontos (digamos, cerca de 26 anos de idade) tornou-se realmente difícil para mim escrever qualquer programa. Havia tantas possibilidades abertas que não consegui mais escolher entre elas. Por alguns anos (até 6) eu até parei de programar e me tornei um redator técnico de notícias.
Eu nunca parei de tentar programar mesmo assim. 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 poderia possivelmente funcionar".
Basicamente, eu me forcei a não me importar com a eficiência do código (que era meu principal obstáculo, evite projetos ineficientes), mas siga o caminho mais fácil. Eu também me forcei a me importar menos com erros, e atrasar o tratamento de erros para um momento posterior, depois de escrever testes para aumentar o erro (realmente isso é TDD).
Isso é algo que aprendi quando estava escrevendo. Quando eu não sei o que escrever, ou eu sabia o que estava escrevendo era ruim. Apenas continue. Na verdade, escreva as coisas ruins. Eu eventualmente irei corrigi-lo 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 na primeira vez.
Realmente, é muito provável que um código que você acredite ser bom na primeira escrita precise melhorar tanto quanto realmente ruim.
Se você seguir o caminho da Simplicidade, você também receberá um bônus adicional. Você aceita facilmente remover / alterar o design / codificação inicial. Você tem uma mente mais flexível.
Eu também tive o hábito de colocar um comentário temporário no código, explicando o que eu não estava fazendo agora e pretendia fazer mais tarde, quando o código fosse funcional no caso de uso normal.
Eu também participei de um XP Dojo e pratiquei katas de código com outros programadores para internalizar as práticas do XP. Ajudou. Isso tornou os métodos formais acima instintivos. A programação em pares também ajudou. Trabalhar com jovens programadores dá algum impulso, mas com a experiência você também vê o que eles não fazem. Por exemplo, no meu caso, muitas vezes os vejo envolvidos em projetos excessivamente complicados e conheço o pesadelo de design que pode levar a. Foi assim. Fez isso. Tive problemas.
O ponto principal 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 novato (e não testei nada), mas também não tenho medo de refatorar e certamente gastar muito menos tempo depurando (quase sem tempo, faça menos de 10% de tempo ).
Resumindo: eu superei meu codeblock usando métodos ágeis (XP), buscando simplicidade e refatorando, e praticando para tornar isso instintivo. Isso funcionou para mim. Não tenho certeza se pode ser generalizado para qualquer outra pessoa.
Em termos de nível de aquisição de habilidades, eu aprendi principalmente a aceitar que toda vez que eu mudo de tecnologia (aprendo nova linguagem, novo framework, etc.) eu vou passar por um estágio quando estou desacelerando. Isso é normal e acabará por superar isso. Eu também posso compensar isso com boa metodologia e habilidades de programação de propósito geral e não será um problema tão grande.