Creo que en mi caso fue “comer mi propia comida para perros en el momento adecuado”.
En los proyectos donde eso sí se aplicó...
-
El programa de prueba de concepto para una función de una herramienta interna de desarrollo que hice porque me frustraba desarrollarla dentro de la empresa salió en apenas 2 semanas. Lo fui desarrollando mientras lo usaba, me gustó cómo quedó, así que repetí el ciclo de ampliarlo en esa herramienta, usarlo yo mismo y publicarlo... y ahora, un año después, lo sigo usando muy bien. Como lo usé de forma continua, iba haciendo por encima las cosas que parecían útiles. Luego las probaba, y si funcionaban bien, las pulía al final, así que creo que por eso salió bien.
-
Como sentía que la mayor parte de mi rutina era demasiado predecible (ir al trabajo => desarrollar => salir del trabajo => desarrollar/jugar/escribir => dormir), hice un temporizador Pomodoro automático. A este también lo hice en 2 semanas y luego lo usé otras 2 semanas. Pero no sentí que tuviera una ventaja grande frente a lo que ya había en el mercado. Así que lo descarté.
-
Estoy haciendo un proyecto open source llamado cron for notion, un “generador automático de documentos de Notion según el horario”. La gran meta de este proyecto es soportar muchas plataformas con REST API capaces de generar documentos, armando el horario en un frontend web, enviándolo al backend, y pasando por una lógica enorme y terrorífica... pero por ahora es un programita simpático que, si le mandas JSON por la línea de comandos CLI, te genera documentos bonitos. Este también lo hice en 2 semanas en mis ratos libres. Aunque, a diferencia de su nombre, también soporta YouTrack, y en realidad no es cron sino que hay que llamarlo por CLI, me di cuenta de que es súper útil.
En los proyectos donde eso no se aplicó...
-
Cuando estaba en la preparatoria, quería hacer un gigantesco MMORPG de mundo abierto... y después de pasar 8 semanas jugando con un personaje que corría por un descampado, lo abandoné.
-
Hice un juego tipo Smash Bros. + shooter usando un motor de físicas. Pero había que entregarlo justo al terminar el desarrollo. Y un juego que podía haber sido mucho más divertido terminó convertido en uno bastante regular.
-
Cuando estaba en la preparatoria, yo pensaba que sería increíble poder jugar un RPG en móvil usando gestos de pantalla táctil. Al menos en mi documento de diseño sonaba increíble, pero 6 meses después, tras probar un juego que sí soportaba eso, me di cuenta: ah, era malísimo. Durante esos 6 meses yo solo había programado el reconocimiento de gestos, y por eso no quedé en ese concurso.
-
Y muchos otros proyectos que murieron sin siquiera llegar a tener nombre
En sus experiencias con side projects satisfactorios, ¿qué cosas tuvieron en común? 'm '?
1 comentarios
Es parecido a eso que mencionaste de dogfooding.
En la época en que yo coleccionaba CDs, hice y publiqué una herramienta que ponía etiquetas con la información del álbum en archivos MP3, y la usé durante mucho tiempo. Pero cuando todo pasó al streaming y dejé de comprar CDs, ya no la uso. Aun así, todavía hay gente que recuerda esa herramienta.
Cuando empezaron a aparecer muchos sitios del tipo One a Day, también hice un asistente de compras que los agrupaba y los mostraba juntos porque yo lo necesitaba; después dejé de usarlo a medida que fueron disminuyendo tanto los productos que valían la pena como los propios sitios.
Creo que lo importante es que las herramientas que más duran son las que, aunque nacen de una necesidad propia, también les pueden servir a los demás.
Ese asistente de compras incluso llegó a generar un poco de ingresos gracias a los afiliados, y creo que en los side projects también sería mejor probar distintos modelos de monetización en vez de limitarse a poner publicidad. Así se pueden mantener por más tiempo.