Tuve el (probable) mismo problema hace muchos años, duró unos años y lo superé. Entonces, quizás le interese saber cómo lo logré, incluso si no estoy seguro de que mi camino también se aplique a usted.
También debería echar un vistazo aquí: Las siete etapas de 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é en algún punto entre la etapa 3 y la etapa 4 de la tecnología que está utilizando actualmente (el dominio de las habilidades depende de la tecnología, puede dominar algunas tecnologías mientras aprende otras).
Ahora empiezo con el testimonio biográfico.
Un poco de contexto. Tengo 47 años. Comencé a programar a las 12 en los años 80. Mientras estaba en la escuela secundaria también trabajé como programador de juegos profesional a tiempo parcial. Básicamente no me dio 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í 20 años, cada vez que comenzaba una tarea de programación, conocía muchas formas de resolver los problemas dados y era muy consciente de los muchos parámetros y dificultades, y los inconvenientes y límites de cualquier método.
En algunos momentos (digamos unos 26 años) se me hizo muy difícil escribir cualquier programa. Había tantas posibilidades abiertas que ya no podía elegir entre ellas. Durante unos años (que sea 6), incluso dejé de programar y me convertí en escritor técnico de noticias.
Sin embargo, nunca dejé 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: "Escribe lo más simple que posiblemente podría funcionar".
Básicamente me obligué a no preocuparme por la eficiencia del código (ese era mi obstáculo principal, evitar diseños ineficientes), pero simplemente seguí el camino más fácil. También me obligué a preocuparme menos por los errores, y retrasar el manejo de errores a un momento posterior, después de escribir las pruebas que provocan el error (realmente eso es TDD).
Eso es algo que aprendí cuando estaba escribiendo. Cuando no sabía qué escribir, o sabía que lo que estaba escribiendo era malo . Solo sigue. En realidad escribe las cosas malas. Eventualmente lo corregiré más tarde. O si es realmente tan malo borrarlo y reescribirlo, pero es más rápido escribir cosas dos veces que escriben algo perfecto la primera vez.
Realmente es muy probable que un código que crees que es bueno en la primera escritura necesite tanta mejora como uno realmente malo.
Si sigues el camino de la simplicidad también obtienes una bonificación adicional. Usted acepta fácilmente eliminar / cambiar el diseño / codificación inicial. Obtienes una mente más flexible.
También tuve la costumbre de poner un comentario temporal en el código, explicando lo que no estaba haciendo ahora y tenía la intención de hacer más adelante cuando el código sería funcional en el caso de uso normal.
También asistí a un XP Dojo y practiqué katas de código con otros programadores para internalizar las prácticas de XP. Eso ayudo. Hizo que los métodos formales anteriores fueran instintivos. La programación en pareja también ayudó. Trabajar con programadores jóvenes da un poco de impulso, pero con la experiencia también se ve lo que no. Por ejemplo, en mi caso, a menudo los veo involucrados en diseños demasiado complicados y sé la pesadilla de diseño que puede conducir a ellos. Se fue de esa manera. Hizo que. Tenía problemas.
El punto primordial para mí es mantener el flujo. Ser rápido realmente está logrando mantener el flujo.
Ahora estoy de vuelta 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. Practicando TDD Todavía puedo ser un poco más lento que cuando era un toro joven (y no probé nada), pero tampoco tengo miedo de refactorizar y ciertamente paso mucho menos tiempo depurando (casi nada de tiempo, hazlo menos del 10% del tiempo )
En resumen: superé mi bloque de código usando métodos ágiles (XP), buscando simplicidad, refactorizando y practicando para hacer eso instintivo. Funcionó para mi. No estoy seguro de que pueda generalizarse a nadie más.
En términos de nivel de adquisición de habilidades, aprendí principalmente a aceptar que cada vez que cambio la tecnología (aprendo un nuevo lenguaje, un nuevo marco, etc.) pasaré por una etapa cuando disminuya 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.
