Hace muchos años tuve el mismo problema (probablemente), duró algunos años y lo superé. Por lo tanto, tal vez sea de su interés saber cómo lo logré, incluso si no estoy seguro de que mi camino también se aplique a usted.
También deberías echar un vistazo aquí: Las siete etapas de la experiencia en Ingeniería de Software muestra que la productividad es, en gran parte, un efecto secundario del nivel de habilidad. Es posible que todavía estés en algún punto entre la etapa 3 y la etapa 4 sobre la tecnología que estás utilizando actualmente (el dominio de las habilidades depende de la tecnología, puedes dominar algunas tecnologías mientras aprendes otras).
Ahora comienzo con el testimonio biográfico.
Un poco de contexto. Tengo 47 años. Empecé a programar a los 12 en los 80's. Mientras estaba en la escuela secundaria también trabajé como programador de juegos profesional a tiempo parcial. Básicamente no me consiguió tanto dinero, solo lo suficiente para comprar hardware, pero lo disfruté y aprendí mucho. A los 18 años comencé un aprendizaje formal de informática.
Como resultado, cuando cumplí los 20 años, al comenzar cualquier tarea de programación, conocía muchas formas de resolver los problemas dados y era muy consciente de los muchos parámetros y dificultades en las manos, y los inconvenientes y límites de cualquier método.
En algunos puntos (digamos, unos 26 años) me resultó muy difícil escribir un programa. Se abrieron tantas posibilidades que ya no pude elegir entre ellas. Durante algunos años (que sea 6) incluso dejé de programar y me convertí en un redactor técnico de noticias.
Sin embargo, nunca dejé totalmente de intentar programar. Y en algún momento volvió. La clave para mí fue la programación extrema, más específicamente el principio de simplicidad: "Escriba lo más sencillo que podría funcionar".
Básicamente, me obligué a no preocuparme por la eficiencia del código (ese fue mi principal obstáculo, evitar los diseños ineficientes), sino simplemente ir por el camino más fácil. También me obligué a preocuparme menos por los errores, y retrasar el manejo de errores para un momento posterior, después de escribir las pruebas que provocan el error (en realidad es TDD).
Eso es algo que aprendí cuando estaba escribiendo. Cuando no sé qué escribir, o sabía que lo que estaba escribiendo era malo . Sólo sigue En realidad escribe las cosas malas. Eventualmente lo corregiré más tarde. O si realmente es tan malo, bórrelo y vuelva a escribirlo, pero es más rápido escribir cosas dos veces que escribir algo perfecto la primera vez.
Realmente es muy probable que un código que creas que es bueno al principio de la escritura necesite tanta mejora como uno realmente malo.
Si sigues la ruta de la simplicidad, también obtendrás una bonificación adicional. Usted acepta fácilmente eliminar / cambiar el diseño / codificación inicial. Obtienes una mente más flexible.
También me acostumbré a poner un comentario temporal en el código, explicando lo que no estaba haciendo ahora y la intención de hacerlo más adelante cuando el código funcionaría en el caso de uso normal.
También asistí a un Dojo de XP y katas de código practicados con otros programadores para internalizar las prácticas de XP. Eso ayudo. Hizo instintivos los métodos formales anteriores. La programación en pares también ayudó. Trabajar con programadores jóvenes le da algo de impulso, pero con la experiencia también puede ver lo que no hacen. Por ejemplo, en mi caso, a menudo los veo participar en diseños excesivamente complicados y conozco la pesadilla del diseño que puede llevar a. Se fue de esa manera. Hizo que. Tuve problemas.
El punto principal para mí es mantener el flujo. Ser rápido es realmente tener éxito en mantener el flujo.
Ahora he vuelto como programador profesional y creo que soy mejor y más rápido con una comprensión más profunda de lo que estoy haciendo. Si practico TDD, es posible que todavía sea un poco más lento que cuando era un toro joven (y no probé nada), pero tampoco tengo miedo de refactorizar y, ciertamente, dedico mucho menos tiempo a la depuración (casi sin tiempo, haz que sea menos del 10% del tiempo. ).
Resumidamente: superé mi bloque de código usando métodos ágiles (XP), yendo por simplicidad y refactorización, y practicando para hacer eso instintivo. Funciono para mi No estoy seguro de que pueda generalizarse a nadie más.
En cuanto al nivel de adquisición de habilidades, aprendí a aceptar que cada vez que cambio de tecnología (aprender un nuevo idioma, un nuevo marco, etc.) pasaré por una etapa en la que disminuiré la velocidad. Esto es normal y eventualmente lo superará. También puedo compensar eso con una buena metodología y habilidades de programación de propósito general y no será tanto un problema.
