- Al trabajar en proyectos técnicos grandes, es importante contar con resultados visibles en el día a día para mantener la motivación y llegar hasta el final
- En vez de dividir el proyecto en bloques grandes y ambiguos, lo separo en unidades pequeñas y visibles, y elijo métodos que me permitan verificar un progreso real en cada etapa
- En las etapas iniciales, crear demos rápidamente con bucles de retroalimentación estrechos ayuda mucho a mantener la concentración y la automotivación
- Es efectivo desarrollar primero las funciones que necesito para mí mismo y seguir mejorándolas a través del uso real
- Más que la perfección, priorizo el avance, y asegurar repetidamente la experiencia de tener pequeños éxitos es lo que permite completar proyectos largos
En el punto de partida
- Al comenzar un proyecto grande, el mayor obstáculo es decidir por dónde empezar
- Si se consideran todos los componentes al mismo tiempo, todo se vuelve demasiado vago y es fácil perder el interés
- Lo importante es empezar por una unidad pequeña que permita ver resultados rápidos
- Cada subproyecto debe ser independiente y ofrecer señales claras de haber sido completado
- Cuanta más experiencia se tiene, mejor se puede entender la forma general y los subcomponentes del proyecto
Crear resultados iniciales
- En el trabajo inicial, puede que haya poco que se vea por fuera, así que el avance puede no ser evidente
- En esos casos, es importante usar de forma adecuada pruebas automatizadas (por ejemplo, pruebas unitarias) para obtener resultados visibles
- Por ejemplo, al crear un parser de terminal, se puede verificar de inmediato con pruebas el resultado del análisis de cadenas de entrada
- La experiencia repetida de ver que las pruebas pasan ya produce una sensación de logro
- A través de estos pequeños éxitos, se puede seguir acumulando evidencia objetiva del avance del proyecto completo
Crear demos rápidamente
- El objetivo inicial no es un subcomponente perfecto, sino una implementación suficiente para una demo
- La complejidad que será necesaria a largo plazo (por ejemplo, bases de datos, estructuras de datos avanzadas, etc.) se deja para después, y se prioriza al máximo una implementación simple para avanzar rápido
- Siempre hay que recordar que "la perfección puede convertirse en enemiga del progreso"
- La meta es hacer una demo simple una o dos veces por semana
- Incluso una demo incompleta permite revisarla directamente y recibir retroalimentación intuitiva, lo cual contribuye mucho a la motivación
Desarrollar para mí mismo
- Sobre todo en proyectos personales, es importante implementar primero las funciones que uno necesita y pasar por el proceso de adoptarlas y usarlas uno mismo
- Al usarlas directamente, se perciben las carencias y se mejora enfocándose en las funciones realmente necesarias, haciendo evolucionar el proyecto desde la perspectiva de un usuario real
- Al inicio aparecen incomodidades o bugs, pero eso deja claro qué es lo siguiente que hay que hacer
- El orgullo de usar software que uno mismo escribió ayuda a sostener el proyecto
- Al principio se omiten por completo funciones innecesarias (scroll, selección con mouse, pestañas, etc.)
Cómo empaquetar el proyecto completo
- Se divide el problema completo en problemas pequeños y visibles. Cada uno debe permitir comprobar un resultado real
- Cada problema pequeño se resuelve solo hasta un nivel suficiente para crear una demo y luego se pasa al siguiente
- Se crea una demo funcional lo antes posible y después se agregan funciones de manera iterativa
- Primero se implementan las funciones que tienen sentido para el propio uso
- Si hace falta, se mejora cada componente de forma iterativa y se repite este ciclo
Conclusión
- Con este enfoque, es posible mantener la propia motivación y completar distintos tipos de proyectos: personales, grupales, laborales o académicos
- Más que enfocarse en deploy o tooling, el texto se centra en qué métodos permiten sostener la motivación de forma continua
- Puede que no sea el mismo método para todo el mundo, pero los resultados visibles del progreso son la fuerza más importante para terminar proyectos de largo plazo
- Es importante entender los propios intereses y la forma en que uno se motiva, y construir un proceso de trabajo acorde con eso
1 comentarios
Opinión de Hacker News
Estoy de acuerdo con todas las opiniones planteadas en el texto, y al mismo tiempo quiero agregar una más: la importancia de los ciclos de retroalimentación rápidos
Cuando haces un cambio y puedes ver de inmediato el resultado, de verdad motiva
Si modificas el código de forma juguetona y observas sus efectos, muchos problemas desaparecen o se transforman en algo fácil de resolver
En proyectos enormes, había una correlación clara entre lo fácil que era configurar y ejecutar algo, y la cantidad de problemas del proyecto (bugs, incumplimiento de plazos, etc.)
Esa charla habla sobre los ciclos de retroalimentación
Enlace de YouTube
Estoy pensando en aplicar pruebas e2e a los bugs que encuentre para asegurarme de que realmente quedaron corregidos
Cuando quieres probar o arreglar algo, si el setup por sí solo toma horas, pierdes las ganas y al final lo pospones
Por eso me gustan los lenguajes que tienen un REPL útil, como Lisp
Hay una gratificación inmediata al poder ver el resultado al instante
En el momento en que pierdes la motivación, ese proyecto se evapora
Por eso, hacer que el propio desarrollo sea una experiencia disfrutable es casi el factor más importante
Creo que es una parte donde la experiencia incluso puede estorbar
A menudo veo a ingenieros senior profundizar demasiado para construir algo perfecto y, cuando llega la hora de mostrar el demo, el resultado no es gran cosa
Puede que la implementación esté bien hecha, pero la funcionalidad o el producto en sí son completamente mediocres
A veces quiero simplemente apagar el cerebro y ponerme a escribir código chafa sin pensarlo tanto
Antes hacía muchos proyectos de juguete, e incluso metía todo el código fuente en un solo archivo
No me preocupaba por modularizar nada, pero era divertido y funcionaba
Pero ahora se me hace realmente difícil terminar aunque sea un solo proyecto de juguete
Como ya lo hiciste una vez, parece que te inclinas a meterle todo tipo de funciones extra innecesarias
Por ejemplo, si participas en retos de programación como Advent of Code, los problemas del inicio son simples y solo más adelante hace falta optimización o algoritmos complejos
O algo como pico-8, donde las limitaciones hacen imposible pasarte demasiado tiempo programando
También ayuda intentarlo en entornos con límite de tiempo, como hackatones o game jams
Porque la gente con poca experiencia puede olvidar todas las "best practices" tediosas de lenguajes anteriores y probar cosas libremente
Yo diseño directamente las tablas de la DB, y le dejo a un LLM con bastante libertad la parte de implementación
Me llamó la atención que el objetivo de los subproyectos iniciales no es crear un "subcomponente terminado", sino un subcomponente "lo suficientemente bueno" como para poder pasar al siguiente paso
Para poner en práctica este enfoque, me di cuenta de que hay que "omitir" algo
Otros dijeron que en este modo ignoran la modularización del código, pero a mí mantener el código ordenado me da satisfacción y motivación
Así que yo planeo "omitir" cosas como algoritmos, estructuras de datos y rendimiento
Al final, el punto es que claramente hay que saltarse algo, pero si ese algo es lo que te motiva, entonces no deberías omitirlo
Un demo funciona como una etapa intermedia entre desarrollar software (programar) y explicarlo por escrito (documentarlo)
A través del demo, puedo seguir validando mis hipótesis sobre lo que mi proyecto debe hacer, y se convierte en una especie de mecanismo de retroalimentación
Los demos permanecen con el tiempo, así que cuando rompes una funcionalidad puedes darte cuenta de inmediato y seguir con ese ciclo iterativo de corregirla
Personalmente estoy trabajando así en el motor de juegos que desarrollo
Ejemplo de demos en github
Ojalá este enfoque se volviera sentido común
Se siente más enfocado en proyectos personales
A mí me interesa saber cuál es una buena manera de llevar grandes proyectos técnicos en equipo, donde todos trabajen hacia un mismo objetivo y las cosas realmente se terminen bien
En casi 15 años trabajando, no he visto un proyecto técnico sin sobrepasar presupuesto, sin retrasarse, sin quedarse corto en funciones y sin burnout
En cambio, si existen casos de este tipo de proyectos grandes bien llevados y exitosos, me gustaría que compartieran enlaces o materiales recomendados para seguir leyendo
Sobrepasar presupuesto es bastante común mientras de verdad no se acabe el dinero
La mayoría de las veces solo es alguien quejándose de que la estimación estuvo mal
Con los retrasos pasa lo mismo: si no hay una fecha límite realmente inamovible, no es un problema grave
De hecho, conviene no planear eventos atados al calendario, como grandes campañas de promoción, hasta que el proyecto esté casi terminado
Quedarse corto en funciones al final también es una cuestión de expectativas
El verdadero problema es que la gente termine completamente drenada y en burnout
Eso sí es algo que como mínimo hay que evitar con certeza
Personalmente, cada vez me gusta más Scaled Agile Framework
Lo uso como un framework, es decir, como una especie de "hombre de paja" que adapto según el contexto
Eso me ha llevado a explorar materiales fuente más profundos y sacar mis propias conclusiones
Aprendí que el verdadero éxito empieza por entender con claridad "por qué estamos construyendo esto"
Si el objetivo no está claro, no puedes priorizar ni saber por dónde empezar
Esa claridad ayuda muchísimo más a decidir "qué construir y cuándo", y a veces incluso permite decidir "no construirlo en absoluto"
Lo siguiente importante es la "empatía"
Hay que ponerse de verdad del lado del cliente, comprender por completo su problema y plantear una solución
No se trata simplemente de darle al cliente todo lo que pide, sino de entender con precisión su dolor principal y entregar algo que de verdad tenga valor
La verdadera razón por la que fracasan la mayoría de los proyectos es que el equipo dedica demasiado tiempo a construir "lo equivocado"
Si se mantiene el enfoque en lo que realmente se necesita, en funciones que la gente de verdad quiere o por las que estaría dispuesta a pagar, muchos más proyectos terminarían completándose con éxito
Hay muchísima gente que ve un gran proyecto y cae en parálisis por análisis
Lo realmente difícil es terminar
Si construyes software que tú mismo vas a usar, puedes resolver tus propios problemas
Y como tú mismo lo usas, también puedes detectar bugs en el software
De hecho, encontré varios bugs mientras construía y usaba directamente mi propio servidor web
Una cultura de desarrollo enfocada, iterativa y orientada a entregar resultados que siempre estén funcionando