La alegría de crear software de juguete

• Crear software de juguete es una forma de recuperar la alegría esencial y la creatividad del desarrollo de software
• En una época en la que la alegría pura de desarrollar software se está perdiendo por la IA y la industrialización, hacer programas de juguete simples como proyectos personales puede convertirse en una oportunidad para obtener conocimientos útiles en el trabajo y una comprensión más profunda
• El software de juguete sigue la regla 80:20, implementando la mayor funcionalidad posible con el mínimo código, y la clave está en evitar el diseño excesivo o la obsesión por la perfección
• La experiencia misma de construir por cuenta propia, enfrentándose a los problemas sin depender de herramientas de IA como los LLM, es la alegría esencial del aprendizaje y el crecimiento

---

Por qué deberíamos hacer más programas de juguete

• La cita de Richard Feynman, “Lo que no puedo crear, no lo entiendo”, muestra que la experiencia de construir algo por uno mismo conduce a una comprensión profunda
• A diferencia del consejo habitual de “no reinventes la rueda”, la experiencia de construir la rueda uno mismo enseña más que la lectura o el aprendizaje puramente teórico
• Últimamente, la IA y la industrialización del software están amenazando la alegría y la artesanía del desarrollo
• Crear software de juguete ayuda a recuperar la simple alegría de volver a engancharse con la computadora

Principios de los programas de juguete: Keep it simple

• El software de juguete sigue el principio 80:20: lograr el 80% de la funcionalidad con el 20% del esfuerzo
• El objetivo no es el producto final, sino la simplicidad y la implementación directa de los principios fundamentales
• Se advierte contra el over-engineering y se enfatiza escribir solo el código estrictamente necesario
• Se recomienda dejar todas las rutas de código aún sin implementar e ir ampliando la implementación a medida que haga falta
• Incluso los sistemas que parecen pequeños pueden resultar sorprendentemente fáciles de construir cuando uno realmente lo intenta

Beneficios adicionales del software de juguete

• El conocimiento obtenido en proyectos de juguete suele ayudar más de lo esperado en el trabajo real para rastrear problemas, resolver bugs y prevenir errores
• Experimentar directamente las restricciones al enfrentarse a los problemas da una visión más profunda sobre la esencia del software y puede llevar a descubrir soluciones innovadoras

Ejemplo: lista de distintos proyectos de software de juguete

Se organizan los tipos de proyectos de juguete implementados personalmente durante los últimos 15 años por nivel de dificultad y tiempo estimado. Cada proyecto incluye una breve explicación y material adicional de referencia

• Motor de regex (dificultad 4/10, 5 días): análisis de expresiones regulares estilo POSIX e identificación de cadenas coincidentes; ayuda a comprender a fondo el funcionamiento interno de las regex
• Kernel de SO x86 (dificultad 7/10, 2 meses): incluye CLI, drivers simples y administrador de memoria; se puede ampliar con sistema de archivos en memoria, ejecutables ELF, GUI, aislamiento de procesos y más
• Emulador de GameBoy/NES (dificultad 6/10, 3 semanas): permite entender un conjunto simple de instrucciones y el hardware, además de implementar PPU, PSG y formatos de cartucho peculiares
• Juego para GameBoy Advance (dificultad 3/10, 2 semanas): juego simple basado en sprites; la comunidad de desarrollo de GBA es activa y la estructura del sistema es totalmente abordable en solitario
• Motor de física 2D (dificultad 5/10, 1 semana): mecánica newtoniana básica y manejo simple de colisiones; puede extenderse a figuras complejas, inercia, algoritmos de resolución, soft bodies e interacciones compuestas
• Intérprete dinámico (dificultad 4/10, 1~2 semanas): intérprete de recorrido de árboles; crear tu propio lenguaje da una alegría tanto técnica como creativa
• Compilador tipo C (dificultad 8/10, 3 meses): diseño de un sistema de tipos simple y entorno objetivo, con optimizaciones y arquitectura para soportar múltiples backends
• Editor de texto (dificultad 5/10, 2~4 semanas): empieza con entrada/salida de archivos simple; se pueden usar toolkits de UI (QT/GTK, etc.), aunque se prefiere consola, y agregar Unicode, resaltado de sintaxis, multibuffer, LSP y otras funciones
• Runtime async (dificultad 6/10, 1 semana): en Rust, procesamiento de tareas con impl Future e implementación de concurrencia, con opción de añadir activación por I/O
• Hash Map (dificultad 4/10, 3~5 días): permite aprender el funcionamiento interno, closed y open addressing, la regla de Robin Hood, además de entender el rendimiento y cuándo conviene usarlo
• Rasteriser / Texture Mapper (dificultad 6/10, 2 semanas): aprendizaje de la estructura del pipeline gráfico 3D, matemáticas vectoriales, Z-buffer, mapeo de texturas y algoritmos de shading
• Renderizado con Signed Distance Field (dificultad 5/10, 3 días): representación matemática del espacio, visualización simple y comprensión de shaders y matemáticas vectoriales
• Motor de vóxeles (dificultad 5/10, 2 semanas): es fácil de entender si ya se tiene experiencia en gráficos 3D o desarrollo de juegos; puede ampliarse con texturas, generación procedural y red
• Máquina virtual threaded (dificultad 6/10, 1 semana): intérprete rápido y optimizado sin generación de código por arquitectura; puede ofrecer una experiencia de rendimiento comparable a la de un compilador
• Toolkit de GUI (dificultad 6/10, 2~3 semanas): tras crear herramientas básicas de UI, se pueden implementar directamente funciones avanzadas como motor de layout, text shaping y accesibilidad
• Simulador de mecánica orbital (dificultad 6/10, 1 semana): implementación simple del modelo gravitacional newtoniano, con posibilidad de ampliar a interacción entre múltiples cuerpos, algoritmos de integración, visualización e incluso datos de NASA
• Bitwise Challenge (dificultad 3/10, 2~3 días): juego reproducido usando solo un estado de 64 bits; sirve para entrenar la gestión creativa del estado, y las reglas detalladas pueden consultarse en GitHub
• Framework ECS (dificultad 4/10, 1~2 semanas): implementación directa de la estructura Entity-Component-System, integrándola con el sistema de tipos del lenguaje y adaptándola a restricciones y alto rendimiento
• Emulador de CHIP-8 (dificultad 3/10, 3~6 días): máquina virtual simple de los años 70, rápida de implementar, con posibilidad de observar y ejecutar varios fan games
• Motor de ajedrez (dificultad 5/10, 2~5 días): se empieza por las reglas y se va mejorando gradualmente; perder contra un motor hecho por uno mismo es una etapa del crecimiento como desarrollador
• Shell POSIX (dificultad 4/10, 3~5 días): permite entender los principios y límites de un shell basado en POSIX, además de lograr una comprensión profunda y conocer muchos trucos al implementar compatibilidad con el lenguaje real de shell

Consejos sobre el uso de herramientas como los LLM

• Las herramientas avanzadas como los LLM son útiles, pero el aprendizaje verdadero se vuelve más profundo cuando uno explora por sí mismo
• En lugar de mirar soluciones existentes, se puede obtener una sensación de logro más profunda durante el proceso de explorar territorios desconocidos y encontrar una respuesta propia
• Al hacer proyectos de juguete sin LLM, al principio puede resultar difícil por falta de costumbre, pero con el tiempo se empieza a sentir una alegría técnica única y una gran sensación de logro

• Si te desplazas en auto, no puedes sentir el ‘runner’s high’ de quien corre: la alegría profunda se obtiene a partir de la experiencia directa, no del atajo

[tolluset]

Entiendo totalmente lo de intentar hacerlo sin LLM. Si no se necesita desarrollo rápido, parece más divertido y gratificante ir construyéndolo mientras entiendes cada parte una por una.

[nezz1204]

Ah, se refería a un proyecto de juguete. Solo por el título, pensé que se trataba de crear software para juguetes. Jaja

[GN⁺]

Opiniones de Hacker News

• Me pregunto cuánta gente usa los LLM como si fueran motores de búsqueda. Antes buscaba en Google cosas como “pros cons mysql mongodb”, y terminaba leyendo documentación oficial, foros, blogs y hasta Stack Overflow, lo cual tomaba bastante tiempo. Pero ese tiempo de lectura y aprendizaje siempre fue bienvenido. Ahora le doy al LLM prompts más específicos, tipo “ventajas y desventajas de mysql vs mongodb para guardar fotos, con enlaces de referencia”. Así capto rápido lo esencial y además tengo links, así que no dependo solo de alucinaciones. A veces también le pido cosas concretas como “diseñame un data schema en postgres para guardar metadatos de fotos; quiero separar X en otra tabla”, pero eso solo lo uso cuando tengo muy claro qué tipo de resultado debería salir. Es más bien para no perder tiempo tecleando o cuando se me olvida momentáneamente el nombre exacto de un tipo, como int vs integer

  • Si usas un LLM como motor de consultas técnicas, muchas veces te da información que parece plausible a primera vista, pero falla en puntos importantes. Si te la crees y sigues la respuesta al pie de la letra, puedes desperdiciar horas o incluso días. Aunque le pidas enlaces de referencia, a veces sí traen información real y otras veces son contenido irrelevante; diría que mitad y mitad. Aun así, hay una cosa en la que sí es claramente bueno: la búsqueda inversa tipo "tip-of-my-tongue". O sea, le describes un concepto y te recomienda los términos de búsqueda adecuados; para eso sí me ha resultado consistente y satisfactorio
  • No falta mucho para que las empresas empiecen a pagarle grandes cantidades a los LLM para que sus productos aparezcan mejor posicionados en comparativas. El LLM puede cambiar solo el encuadre y el énfasis para que el resultado parezca “orgánico”. Porque basta con mostrar información verdadera y fundamentada, pero resaltando cierto contexto
  • Yo también uso los LLM para buscar. Se siente como volver a la época de inicios de los 2010, cuando googlear era poderosísimo. Cuando podías encontrar de todo. Claro, eso no duró mucho, y hoy googlear es dolor y frustración pura. Tengo muchas quejas sobre los cambios que hicieron Google y los marketers, pero siento que los LLM actuales son extremadamente eficientes para sacar a la superficie información en línea al instante. Los enlaces de referencia además suelen ser bastante precisos. Al final actuarán las mismas fuerzas de cambio de siempre, así que probablemente sea solo una oportunidad temporal antes de que también se arruine
  • Yo también soy de los que usan LLM como motor de búsqueda. Todavía no uso AI IDEs. Hace poco, en una entrevista técnica en vivo, intenté responder haciendo consultas “tipo Google” al LLM que elegí, y el entrevistador me dijo que era la primera vez que veía a un candidato usar IA así. Yo asumía que la mayoría de developers todavía la usaban primero para buscar, más que como AI IDE. ¿Será raro un caso como el nuestro?
  • Incluso para programar uso LLM como motor de búsqueda. Cosas como: “analiza el repo que cloné en /src/foo y explícame cómo está implementado barFeature. Ahora mira el proyecto /src/baz y explícame por qué el enfoque de foo sería difícil de aplicar en baz”. No le pido que haga algo nuevo; lo uso para traducir lo que ya existe dentro de un proyecto a mis propias ideas. El desarrollo realmente nuevo y desafiante me gusta codificarlo yo mismo

• Una de las mejores decisiones de mi carrera fue tomarme 6 meses entre trabajos para hacer proyectos personales. Tenía muchas ideas para empezar, pero como no tenía restricciones, el alcance siempre crecía y al final muchas veces no terminaba nada. Así que decidí dedicar solo 1 semana a cada proyecto. Hacía únicamente lo que se pudiera en ese tiempo. Empezar desde cero y, en una semana, construir algo utilizable con un lenguaje o framework nuevo, o en un área desconocida, me dio una confianza enorme. También me ayudó a recordar por qué me gustaba programar desde un principio. Si alguna vez tienes unos meses libres entre trabajos, en vez de prepararte para entrevistas de Silicon Valley, hacer toy projects puede hacerte darte cuenta de cuánto ya sabías

  • Si tienes herramientas de generación con IA, ayudan muchísimo con este tipo de proyectos personales. Yo hago principalmente backend, pero también puedo hacer frontend. El tema es que antes se me iba demasiado tiempo en CSS, así que muchas veces no lograba terminar mis proyectos personales. Ahora le digo a la IA “hazlo bonito” y me deja algo al 85%; luego solo arreglo bugs y hago unos ajustes, así que puedo cerrarlos mucho más rápido. Antes desarrollar se sentía como meterse en un lodazal; ahora, como se volvió mucho más llevadero, hago proyectos personales más seguido
  • Últimamente he ido cambiando hacia arreglar directamente las librerías que uso. Si detecto documentación de onboarding incompleta, un SDLC roto o problemas serios de rendimiento, me puedo pasar el día entero corrigiendo eso. A diferencia de un proyecto colaborativo, donde hay otras personas esperando, en los toy projects personales es muy fácil perderse en side quests o tareas secundarias. En la colaboración existe la presión de que alguien está esperando
  • Me da curiosidad cómo hiciste para tomarte 6 meses y luego conseguir el siguiente trabajo. Yo también quisiera descansar 6 meses, pero me da miedo no conseguir trabajo después y terminar descansando más tiempo del planeado
  • Cuando era chico, armaba servidores con classic ASP + SQL, tocaba HTML/CSS/JS, y desplegar era facilísimo. Solo había que subir archivos por FTP. Ahora me gustaría explorar formas más modernas, pero cuando hago proyectos personales siempre termino atorándome pensando en despliegue y proceso de desarrollo o lifecycle. Me da curiosidad cómo eliges hosting y estrategia de despliegue para toy projects
  • A mí también me ha quedado clarísimo que la IA acelera este tipo de proyectos, sobre todo porque genera boilerplate o código para automatizar tests

• Hacer software de juguete se parece a darle mantenimiento a una bicicleta, un auto o un bote. Es divertido. Pero arreglar la bicicleta para ir al trabajo sí estresa. Hacer toy software es divertido, pero cuando en algún momento quiero usarlo de verdad, termino encontrando todos los bugs y ya no tengo tiempo para corregirlos; ahí aparece el dilema

  • A mí me gusta más desarrollar software solo para usarlo yo. Con los autos también me satisface más usarlos por mucho tiempo y a bajo costo
  • Hubo una época en la que administraba mi propio servidor de correo, pero ya no. No porque no pudiera hacerlo, sino porque ahora prefiero dejar ese trabajo a especialistas
  • Hace poco hice mi propia aplicación de facturación. Me encantó ir agregando una por una las funciones que necesitaba. Hasta incluí cosas por las que en servicios de pago tendría que pagar una suscripción mensual. Pero cuando llegó el momento de mandar facturas reales, me di cuenta de que había demasiados problemas por resolver en mi app —estilos, captura de direcciones, etc.—. Al final sentí que había que encontrar un equilibrio entre la diversión de andar en bicicleta y la practicidad de la bici para ir al trabajo. Con el tiempo, quizá diversión y practicidad se vayan acercando cada vez más
  • Yo también tengo demasiadas cosas que quisiera convertir en “software terminado”, pero no tengo ni el tiempo ni la energía. Además hay muchísimo trabajo aburrido y repetitivo. Y aun así, administrar y filtrar “resultados de IA” también es bastante trabajo. Todavía estoy en una etapa temprana de experimentación, así que no sé si en unos meses seguiré pensando lo mismo
  • Por eso mismo, hacer una página personal es realmente divertido. De verdad puedes usarla como tu propio patio de juegos

• Me sorprende que haya tantas opiniones negativas sobre los LLM. Los LLM te dan la información servida en bandeja. Cuando empiezas un proyecto nuevo, obviamente no arrancas sabiendo todo. Haces tu mejor intento, fallas, luego estudias, entiendes por qué no funcionó y ajustas con un enfoque nuevo; ahí está el aprendizaje real. Si solo sigues un tutorial porque “ya sabes todo”, no llegas a experimentar las limitaciones ni las ventajas y desventajas reales de cada método. Por ejemplo, si intentas hacer un parser con expresiones regulares y descubres por ti mismo que no puedes manejar expresiones recursivas, también aprendes de primera mano sobre estructuras más complejas y problemas de complejidad temporal. Si implementas tu propio compilador optimizador y te frustras con toda clase de trucos de optimización, terminas entendiendo por qué los compiladores reales están diseñados como están. Si escribes tu propio motor de layout, incluso el concepto de width se vuelve una lucha muy concreta. No hay mejor experiencia que aprender a base de ensayo y error. Aunque el LLM te ayude a evitar errores, ojalá eso no te haga perder oportunidades de aprendizaje valiosas

  • Mucha gente dice que si no usas LLM te vas a quedar atrás, pero a veces pienso que usar menos LLM podría ser una gran ventaja a largo plazo

• Yo también pasé años haciendo incontables proyectos raros en fines de semana y madrugadas para aprender computer graphics. No gané ni un centavo, pero gracias a eso conseguí el trabajo de mis sueños. Algunos trabajos representativos:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web El verdadero propósito de toda esta montaña de código fue siempre “adquirir conocimiento”

• Siento que de verdad hace falta ese espíritu de “la diversión de programar” que propone este texto. En la era del coding con agentes de IA, vale aún más. Pero sí creo que el autor se queda muy corto con los tiempos estimados para esos toy projects. No digo que yo sea una referencia promedio, pero aun así, para la mayoría de esa lista no me parece que sean proyectos de unos cuantos días si asumes que solo trabajas 2 o 3 horas por día. Siento que solo la investigación previa ya lleva bastante tiempo. Como ejemplo, hace poco reemplacé mi blog de Pelican por un sitio estático personal generado con Odin, y aun dedicándole solo 2 o 3 horas al día, me tomó dos semanas. Y eso que era más fácil que varios otros proyectos de la lista

  • Tu proyecto ya es más que un proyecto “toy”. Tú mismo eres un cliente real y esperas que, una vez desplegado, funcione correctamente. Esa expectativa es la frontera entre un juguete y una herramienta real. Puedes hacer un procesador de texto en una hora: quizá solo procese una tecla a la vez, sea absurdamente simple y ni siquiera tenga botón para salir. Pero aun así eso basta como procesador de texto “toy”
  • Si interpretas “X días” como 24*X horas, la lista se vuelve bastante razonable
  • Una de las ventajas de los toy projects es que no tienen deadline. Así que sí puedes hacerlos con mucha calma, a fuego lento. Yo sigo puliendo desde la pandemia un lenguaje Turing-completo basado en PEG
  • En este tipo de tiempos influye muchísimo hasta qué punto usaste librerías de terceros y qué resolviste por tu cuenta, además de cuánto te enfocaste realmente solo en el núcleo esencial. Si ves el GitHub del autor (https://github.com/ssloy?tab=repositories), se puede aprender mucho sobre cómo mantener el alcance pequeño. Y además, el autor ya entiende muy bien el dominio del problema, así que puede programar así de “ajustado”. Si el tema fuera nuevo para él, sería difícil implementarlo de esa manera

• También coincido con el consejo de “no uses LLM para este tipo de proyectos”, pero no creo que deba tomarse de forma tan extrema. Me parece interesante que el consejo sobre cómo recibir ayuda de la IA se sienta distinto a pedir ayuda a una persona. Si al final del blog dijera “si tienes un amigo que programa bien, jamás le pidas ayuda”, sonaría raro. Un amigo experto entiende el contexto y te ayuda a que lo resuelvas tú mismo. Apostaría a que casi nadie le ha pedido realmente a la IA: “no me resuelvas el problema; guíame como si fueras un amigo experto”. Claro, tal vez todavía no pueda hacerlo bien, o le falte mucho, pero en 1 o 2 años esa clase de guía podría volverse de lo más natural. Por eso creo que conviene desarrollar el hábito de expresar claramente qué tipo de ayuda quieres. No hace falta cargar con la idea fija de que un LLM solo te va a dar respuestas incorrectas

  • Aun así, me queda claro que la IA todavía no es un developer experto
  • Usar el LLM como si fuera un amigo experto es, de hecho, la forma en que más lo uso. Para que sea confiable, hay que reformular el prompt o la pregunta para que no venga sesgada desde el inicio. Últimamente siento que Claude y ChatGPT tienden demasiado a darme la razón
  • (autor) En realidad, yo sí recomendaría incluso “no pedir ayuda ni a un amigo experto”. Mi postura es que, salvo que de verdad estés totalmente atorado, es mejor leer un poco de literatura básica sobre el tema. Creo firmemente que la experiencia de probar muchos caminos por tu cuenta y abrirte paso a trompicones es esencial para desarrollar creatividad y capacidad de resolver problemas. Ese tiempo de confusión es necesario. Pero al final, cada quien debe decidir por sí mismo
  • En la práctica, yo sí le pregunto al LLM como si fuera un “profesor”. No le pido respuestas como si fuera un interno

• Gracias al vibe coding con Claude, por fin volví a empezar side projects divertidos después de muchísimo tiempo. Una vez que aprendí las herramientas y el proceso, en pocas semanas he estado armando rápido varias apps: un dashboard familiar de calendario y clima, una app de lectura para Bluesky (que oculta posts ya vistos), un dashboard gamificado de PM para la empresa, una extensión de Chrome que esconde posts de Reddit después de cierto tiempo, y una app para reemplazar un plugin de WordPress sin mantenimiento, entre otras. Al principio le pedía mucho a Claude, sobre todo para mejorar la UI, pero ahora ya aprendí a conformarme con un 90% de acabado y a enfocarme en nuevas funciones en vez de pulir de más

  • Me desconcierta cuando Claude corrige un bug pero no me muestra enseguida el resultado. Hubo una vez en que tuve que pedirle 6 veces que me enseñara la salida actualizada de un solo cambio. ¿A alguien más le pasa?

• Esta lista me pareció realmente impresionante. Muchos de los proyectos que al autor le parecen fáciles a mí me resultarían de una dificultad muchísimo mayor. Aun así, sí me motivó mucho a querer retomar mis propios toy projects. Eso sí: la conclusión sobre aprendizaje con LLM me parece más matizada. Depende por completo de cómo lo uses. Por ejemplo, pedirle “impleméntame este problema” es pésimo para aprender, pero pedirle “explícame la estructura de ELF al nivel más alto de abstracción, enfocándote en el porqué” puede ser un acelerador de aprendizaje enorme. Es cierto que dejar de investigar todo por tu cuenta puede ser una desventaja, pero si de verdad mantienes una actitud intelectual activa, tener siempre disponible una conversación de preguntas y respuestas al estilo socrático es una ayuda potentísima para aprender

  • (autor) Eso es precisamente lo que quise decir en el texto con “cierto tipo de aprendizaje”. Por ejemplo, para aprender la estructura de un binario ELF no puedes descubrirlo todo solo a partir de conjeturas; necesitas conocer la historia y el proceso de decisión, así que tienes que usar especificaciones, documentación o materiales de referencia, incluidos los LLM. Pero lo fundamental es el “constructive learning”, aprender construyendo por tu cuenta. El punto está en que el proceso de exploración, tropiezos y prueba al crear tú mismo un formato binario te hace entender las razones, los problemas y todo el espacio de diseño de formatos reales como ELF. Para ese tipo de aprendizaje exploratorio, recomiendo no usar ayuda de LLM. “Si te dejaran 10 años solo con una laptop, un editor de texto y un compilador, ¿hasta dónde podrías llegar? ¿En qué punto necesitarías información específica para destrabarte?”

• Estos proyectos que presentan aquí son muy buenas ideas, pero a mí no me interesa ninguno. En momentos así me pregunto si de verdad alguna vez me gustó programar

  • Creo que soy tu total opuesto. La mayoría de los proyectos de la lista me parecieron interesantes, y son el tipo de cosas que uno quisiera intentar o incluso ya intentó hacer. De hecho, yo también me estuve haciendo esa pregunta hasta hace poco, y cuando nació mi bebé y me tomé licencia, empecé un proyecto de programación “simple” solo por diversión. Decidí quitar todas las dependencias y hacer todo yo mismo desde cero, y resultó muchísimo más complejo de lo que pensaba; pero justamente por eso empecé a esperar con ansias esas pocas horas que tenía para programar. De pronto programar volvió a parecerme divertidísimo. Tal vez estés pasando por burnout