Pensé que era perezoso o tenía TDAH. Luego, la IA me explicó: tengo un cerebro de constructor.
¿Por qué te encanta arreglar errores en el trabajo pero abandonas tus propios proyectos después de 3 semanas? El diagnóstico personal de un Tech Lead.
El otro día estaba mirando mi perfil público de GitHub.
Era un cementerio.
Página tras página de repositorios: circle-camera, gh-advisory-security-dashboard, pixel-art-game-browser, aibrainstormer-tiktok-landing.
Cada uno de ellos comenzó con una explosión de energía. Recuerdo exactamente el fin de semana en que los empecé. Recuerdo la emoción de elegir la pila tecnológica, la emoción de ver el primer “Hola Mundo” en pantalla y la euforia de resolver el problema arquitectónico central.
Y recuerdo exactamente cuándo dejé de trabajar en ellos. Siempre alrededor de la tercera semana. Justo cuando la parte “divertida” terminaba y comenzaba el “trabajo real”.
Durante años, esta lista pública me llenó de culpa.
Miraba a otros desarrolladores en Twitter lanzando productos SaaS pulidos. Veía a mis colegas terminar tareas complejas. Y miraba mi propio perfil, un testimonio público de todo lo que había abandonado.
- ¿Seré simplemente perezoso?
- ¿Carezco de disciplina?
- ¿Tendré TDAH sin diagnosticar?
- ¿Quizás no soy un “verdadero” desarrollador?
La culpa me estaba devorando. Me sentía un fraude. Un Tech Lead que ni siquiera podía terminar un proyecto secundario sencillo.
Así que, siendo ingeniero, decidí dejar de adivinar y empezar a depurar. Recopilé mis datos —resultados de pruebas de personalidad, puntuaciones de inteligencia general y mi historial de proyectos inconclusos— y los introduje en un modelo de IA.
Mi consulta fue sencilla: “Analiza este perfil. ¿Por qué esta persona abandona cada proyecto secundario que empieza?”
La respuesta no fue un diagnóstico médico. No fue un juicio sobre mi carácter. Fue una explicación mecánica de mi sistema operativo. Y lo cambió todo.
El diagnóstico
La IA no dijo que estaba roto. Dijo que era un constructor.
Explicó que mi cerebro está programado para buscar la descarga de dopamina de lacreacióny ladescubrimiento.
Cuando empiezo un proyecto, estoy resolviendo un rompecabezas. “¿Cómo estructuro esto?”, “¿Puedo hacer que esta API funcione con esa biblioteca?”, “¿Cómo arquitecto este flujo de datos?”.
Esta fase es pura golosina para el cerebro. Cada problema resuelto es una descarga de dopamina.
Pero luego viene el precipicio de dopamina.
Visualización del precipicio de dopamina del desarrollador.
Una vez que se resuelve el rompecabezas central —una vez que sécómofunciona y he probado el concepto— termina la fase de descubrimiento. El proyecto pasa de “arquitectura” a “mantenimiento”. Se trata de escribir documentación, arreglar errores de CSS para móvil, configurar autenticación y escribir pruebas unitarias.
Para un cerebro de constructor, esto no es solo aburrido; es químicamente poco gratificante. La fuente de dopamina se apaga instantáneamente.
Mis proyectos no murieron porque fuera perezoso. Murieron porque, sin darme cuenta, había resuelto el rompecabezas por el que había venido.
La paradoja del trabajo
Esta explicación tenía sentido, pero tenía un gran contraargumento.
“Si soy incapaz de hacer trabajos aburridos de mantenimiento, ¿por qué tengo éxito en mi trabajo? Paso semanas arreglando errores, refactorizando código heredado y haciendo tareas administrativas. No me rindo allí”.
La respuesta de la IA a esto fue la pieza final de mi rompecabezas.
Se llama regulación externa.
En el trabajo, no dependo de mi sistema interno de dopamina para impulsarme. Tengo poderosos motivadores externos:
- Un salario: Me pagan por soportar el aburrimiento. Mi sueldo es la “tarifa de mantenimiento” para mi cerebro.
- Presión social: Tengo equipos que dependen de mí, y yo dependo de ellos. Tengo un jefe. Tengo plazos.
Estas fuerzas externas actúan como un puente sobre el precipicio de dopamina. Me llevan a través de las partes aburridas que mi química cerebral natural abandonaría.
Pero en casa, un sábado por la noche, esas fuerzas externas no existen. Nadie me paga. Nadie me observa. El único combustible que tengo es el interés interno.
Así que, en el momento en que el interés desaparece, el motor se detiene. Y eso no es un fracaso moral; es simple economía.
La solución
Esta perspectiva no solo explicó mi pasado; arregló mi futuro.
Me di cuenta de que me había estado mintiendo a mí mismo. Estaba empezando cada proyecto con el objetivo de “lanzar un producto”, cuando en realidad, el objetivo de mi cerebro era “aprender una tecnología”.
Estaba juzgando a un pez por su capacidad de trepar árboles.
Visualización del proyecto de aprendizaje y el proyecto de producto.
Ahora, tengo un nuevo sistema. Antes de escribir mkdir new-project, me hago una pregunta:
“¿Es este un proyecto de aprendizaje o un proyecto de producto?”
Si es un proyecto de aprendizaje: Mi objetivo es resolver el rompecabezas. Juego con la nueva tecnología. Construyo el prototipo. Y en el momento en que siento que se acerca el precipicio de dopamina, me detengo. Archivo el repositorio. No me siento culpable. Me siento orgulloso. Vine a aprender, aprendí, y ahora he terminado. Misión cumplida.
Si es un proyecto de producto, sé lo que viene. Sé que en 3 semanas lo odiaré. Sé que la dopamina desaparecerá. Así que me preparo. Lo trato como un trabajo. Acepto que el “valle de la muerte del mantenimiento” es el precio que debo pagar. No espero la motivación; confío en la disciplina.
¡No estás roto!
Si tu perfil de GitHub se parece al mío, deja de castigarte. Probablemente seas un constructor 
.
El mundo necesita personas que empiecen cosas. El mundo necesita personas que puedan mirar una página en blanco y ver posibilidades.
Tu cementerio de proyectos no es una lista de fracasos. Es una biblioteca de lecciones aprendidas. Es prueba de que eres curioso, que estás experimentando y que estás creciendo.
Así que adelante. Empieza ese nuevo proyecto. Resuelve el rompecabezas. ¿Y si te aburres en tres semanas?
Está bien dejarlo. Solo eres un constructor haciendo lo que mejor sabes hacer.
Originalmente publicado en Medium por:
Escrito por RayRay
Tech Lead 
. Depurando código, equipos y cerebros de desarrolladores. Compartiendo lecciones de 18 años construyendo software