Por qué programo 3 veces más rápido que mi equipo (y no es lo que piensas 
)
El secreto no son mejores herramientas ni más experiencia — es saber cuándo “lo suficientemente bueno” realmente lo es.
Foto por Mohammad Rahmani en Unsplash
¿Conoces esa sensación cuando tu gerente te pide una estimación y piensas “dos semanas”, pero dices “tres semanas, por si acaso”? Sí, yo también lo hacía. Luego vi cómo mis plazos se deslizaban de todas formas porque seguía puliendo código que nadie leería jamás.
El año pasado empecé a registrar mi velocidad de desarrollo comparada con la de mis compañeros. Los resultados me sorprendieron. Consistente entregaba funcionalidades 3 veces más rápido que desarrolladores con experiencia similar. Pero aquí está la parte extraña: no trabajaba más horas ni usaba herramientas de IA sofisticadas de las que todos hablan.
Simplemente lo hacía todo mal. Al menos, mal según todo lo que aprendí en mis clases de ciencias de la computación.
El problema con el código “perfecto”
Cuando empecé a programar, pensaba que cada función necesitaba estar perfectamente probada. Cada nombre de variable tenía que ser elegante. Cada abstracción tenía que ser cristalina. Quería cero errores y una arquitectura hermosa.
Esto suena bien en teoría. Pero en la práctica, me hacía increíblemente lento.
Esto es lo que realmente ocurre cuando persigues la perfección. Pasas tres horas nombrando una variable que se eliminará la próxima semana. Construyes una abstracción elegante para una funcionalidad que nunca tendrá el segundo caso de uso que planeaste. Escribes pruebas exhaustivas para código que resulta resolver el problema equivocado.
Aprendí esta lección de la manera más difícil durante un hackathon de 24 horas. Mi equipo pasó 18 horas construyendo una solución “limpia”, mientras que el equipo ganador tenía software funcional después de 6 horas. Su código era desordenado, lleno de comentarios TODO y probablemente tenía errores. Pero funcionaba, y eso era lo único que importaba.
El momento de iluminación: diferentes proyectos necesitan diferentes estándares de calidad.
Para un marcapasos, cada línea debe ser perfecta porque dependen de ello vidas. Para un proyecto secundario de fin de semana, solo necesita funcionar lo suficiente para validar tu idea. La mayoría de los proyectos caen en algún punto intermedio.
Ahora me pregunto una cosa antes de empezar a programar: “¿Qué es lo suficientemente bueno para este proyecto?”
A veces lo suficientemente bueno significa calidad del 60% si estoy probando una idea. A veces significa calidad del 95% si estoy construyendo algo por lo que los clientes pagan. Pero casi nunca es el 100% porque la perfección es enemiga de lo entregado.
La magia de los borradores
Los escritores no empiezan con prosa perfecta. Escriben primeros borradores terribles y luego los editan hasta convertirlos en algo bueno. Pero de alguna manera, en programación, pensamos que deberíamos escribir código perfecto desde el primer intento.
Esto está al revés.
Mi código de borrador se ve terrible. Tiene errores. Las pruebas fallan. Hay comentarios TODO por todas partes. Copio y pego código en lugar de hacerlo DRY. Codifico valores que deberían ser variables. Dejo sentencias print para depurar.
Pero aquí está por qué este enfoque funciona: los borradores revelan lo desconocido desconocido.
Cuando intentas escribir código perfecto desde el principio, tomas decisiones basadas en información incompleta. No sabes qué partes serán difíciles. No sabes qué funciones cambiarán. No sabes cuáles son los cuellos de botella reales.
Los borradores te muestran estas cosas rápidamente.
El mes pasado, estaba construyendo una canalización de procesamiento de datos. Mi primer instinto fue diseñar una arquitectura hermosa y flexible que pudiera manejar cualquier formato de datos. En cambio, escribí un script desordenado que solo manejaba nuestros datos actuales. Tomó 2 horas en lugar de 2 días.
Bien que lo hice, porque los requisitos cambiaron completamente la semana siguiente.
El borrador reveló que el rendimiento era realmente la mayor preocupación, no la flexibilidad. Si hubiera pasado días en la arquitectura “perfecta”, habría optimizado para lo equivocado.
Mi proceso ahora:
- Escribir el código más feo que resuelva el problema
- Asegurarme de que realmente funcione
- Identificar qué partes necesitan ser limpiadas
- Refactorizar solo lo que importa
Esto no significa que entregue borradores. Significa que uso borradores para entender el problema antes de construir la solución real.
Cuestiona todo (especialmente los requisitos)
Aquí hay algo que nadie te dice: la mayoría de los requisitos son negociables.
Los gerentes de producto y los clientes a menudo piden funciones complejas porque no han pensado en alternativas más simples. Quieren 10 pantallas diferentes cuando 2 funcionarían bien. Quieren manejar casos extremos que afectan al 0.1% de los usuarios.
Yo solía construir lo que me pedían. Ahora hago preguntas:
“¿Podemos combinar estas dos pantallas?” “¿Realmente necesitamos manejar este caso extremo?” “¿Qué tal si apoyamos 10 elementos en lugar de 1000?” “¿Podríamos lanzar con una versión más simple primero?”
La mitad del tiempo, la respuesta es sí.
El trimestre pasado, me pidieron construir un panel de informes complejo con 15 tipos diferentes de gráficos. En lugar de construirlo, pregunté: “¿Qué decisiones intentan tomar con estos datos?”
Resultó que realmente solo necesitaban saber si las ventas estaban subiendo o bajando. Un simple gráfico de líneas resolvió el problema real en una fracción del tiempo.
El código más rápido es el código que no tienes que escribir.
No estoy diciendo que ignores los requisitos. Estoy diciendo que entiendas el objetivo detrás de los requisitos. A menudo puedes lograr el mismo objetivo con mucho menos trabajo.
El enfoque es tu superpoder
El mayor asesino de productividad no es escribir lento o tener malas herramientas. Es la distracción.
Empiezas a arreglar un error y notas algún código feo cerca. Lo refactorizas. Luego ves una oportunidad para mejorar los nombres. Luego te das cuenta de que todo el módulo podría organizarse mejor. Antes de darte cuenta, has pasado cuatro horas y el error original sigue ahí.
Llamo a esto “teatro de productividad”. Te sientes ocupado, pero no estás avanzando en lo que realmente importa.
Aquí está lo que cambió mi vida: temporizadores y commits pequeños.
Ahora pongo un temporizador de 25 minutos para cada tarea. Cuando suena, me detengo y hago commit de lo que tengo, aunque no sea perfecto. Esto me obliga a enfocarme primero en la parte esencial.
El temporizador crea urgencia. En lugar de vagar por el territorio de la refactorización, me mantengo enfocado en el problema específico que estoy resolviendo. Si queda tiempo, entonces puedo limpiar las cosas.
Los commits pequeños también ayudan porque crean impulso. Cada commit se siente como un progreso. Y si me distraigo, el temporizador me atrapa y me devuelve al camino.
El efecto secundario extraño: la calidad de mi código realmente mejoró. Cuando tienes tiempo limitado, te enfocas en lo que realmente importa en lugar de en lo que podría importar algún día.
Pequeños pasos, grandes resultados
Solía acumular cambios en commits grandes. Pensaba que era más profesional entregar funciones completas en lugar de progreso incremental.
Este fue otro error.
Los cambios grandes son difíciles de revisar. Son arriesgados de implementar. Toman una eternidad en completarse, lo que significa que no hay retroalimentación hasta el final. Y si algo sale mal, es difícil averiguar qué se rompió.
Los cambios pequeños son lo opuesto. Son fáciles de revisar, seguros de implementar y te dan retroalimentación rápidamente. Si algo se rompe, sabes exactamente qué lo causó.
Pero el mayor beneficio es psicológico. Los cambios pequeños crean impulso. Cada pull request fusionado se siente como progreso. Te mantienes motivado porque estás constantemente entregando.
Mi regla ahora: si un cambio funciona, entrégalo, aunque no esté completo.
En lugar de construir toda una funcionalidad detrás de una bandera de funcionalidad, entrego primero el backend, luego la API, luego el frontend. Cada pieza funciona y agrega valor, aunque la funcionalidad completa aún no esté terminada.
Este enfoque tiene un beneficio adicional: te obliga a diseñar mejores APIs. Cuando no puedes esconder interfaces desordenadas detrás de “lo arreglaremos más tarde”, naturalmente creas límites más limpios entre componentes.
Las habilidades que realmente importan
Todo este asunto de estrategia está bien, pero algunas habilidades técnicas te hacen genuinamente más rápido:
Leer código probablemente sea la habilidad más subestimada. Cuando puedes entender rápidamente el código existente, depurar se vuelve mucho más fácil. Pasas menos tiempo adivinando y más tiempo arreglando. También aprendes más rápido al ver cómo otras personas resuelven problemas.
Modelado de datos vale la pena ir despacio. Un mal diseño de base de datos o estructura de datos te perseguirá durante meses. Es una de las pocas áreas donde invertir tiempo extra al principio ahorra enormes cantidades de tiempo después.
Scripting hace todo más rápido. Escribo constantemente pequeños scripts en bash y Python. Convertir formatos de datos, generar código repetitivo, encontrar duplicados, limpiar archivos. Si hago algo más de dos veces, lo automatizo.
Usar depuradores en lugar de sentencias print ahorra horas. Sé que depurar con print parece más rápido, pero los depuradores reales te permiten explorar el espacio del problema en lugar de adivinar dónde poner la siguiente sentencia print.
Tomar descansos cuando estás atascado. Esto parece obvio, pero es difícil hacerlo. He perdido la cuenta de problemas que parecían imposibles a las 5 PM pero tenían soluciones obvias a las 9 AM del día siguiente.
El verdadero secreto
Aquí está lo que aprendí después de años intentando programar más rápido: la velocidad proviene de cometer menos errores, no de escribir más rápido.
El cuello de botella no es la velocidad de tu teclado ni tu conocimiento de atajos. Es tomar buenas decisiones sobre qué construir y cuándo detenerse.
El código perfecto que resuelve el problema equivocado es inútil. El código desordenado que resuelve el problema correcto es valioso.
Así que empieza con borradores. Cuestiona los requisitos. Mantente enfocado en lo que importa. Entrega cambios pequeños con frecuencia. Y recuerda que “lo suficientemente bueno” a menudo es exactamente lo suficientemente bueno.
Tu gerente quedará impresionado por lo rápido que entregas. Tus compañeros se preguntarán cómo lo haces. Y tú tendrás más tiempo para las partes de la programación que realmente son divertidas.
El secreto no es trabajar más duro. Es trabajar en las cosas correctas y saber cuándo detenerse.