Escribe más software “inútil”
(ntietz.com)- El software inútil es una forma de juego que recupera la alegría de la computación al liberarse de la presión de producir resultados prácticos, y Hurl también fue un experimento que comenzó como una “broma”
- Los tecnólogos suelen pasar mucho tiempo en entornos donde se espera que produzcan resultados útiles, por lo que la chispa de diversión que los llevó a empezar a programar puede debilitarse
- En los proyectos lúdicos, uno mismo define las pruebas, el rastreador de issues y el criterio de finalización, y puede parar en cualquier momento cuando ya aprendió lo que quería o se acabó la diversión
- Un motor de ajedrez, un almacén clave-valor que implementa parte de la API de Redis, una utilidad de Wake-on-LAN, una visualización de ajedrez y una base de datos de ajedrez fueron experimentos para aprender sobre GUI, sistemas, redes e internos de bases de datos
- Tratar a la computadora con menos solemnidad y crear cosas que “parecen inútiles” es una forma realista de aprender y divertirse al mismo tiempo
La libertad que da lo “inútil”
- Le preguntaron por Hurl: “¿por qué lo hiciste?”, y la respuesta corta fue: por una broma
- La respuesta más larga es que el software inútil permite experimentar la diversión y la exploración de la computación
- Por lo general, los tecnólogos están atados a hacer cosas útiles
- Los ingenieros de software escriben código que resuelve problemas reales
- Los científicos de la computación estudian problemas para producir resultados nuevos y prácticos
- Quienes escriben documentación técnica trabajan con tecnologías y documentación reales
- Muchas personas que empezaron a programar sintieron diversión en ese trabajo de una u otra manera, y esa sensación quizá también influyó en su elección de carrera
- Cuando uno tiene que hacer cosas útiles todo el día, es fácil que el interés se desgaste
- Lo que hay que hacer viene con obligaciones y presión
- Toda actividad termina conectada con el trabajo mismo
- En el proceso, es fácil perder el importante elemento de juego
- El software inútil es una manera de escapar de esas obligaciones
- Tú decides qué quieres obtener del proyecto
- Puedes detenerte en cualquier momento
- Si no quieres escribir pruebas, puedes omitirlas
- Si no quieres usar un rastreador de issues, puedes descartarlo
- Si ya aprendiste lo que querías y dejó de ser divertido, puedes dar por terminado el proyecto
Proyectos hechos por diversión
- El horrible motor de ajedrez con UI tenía muchos bugs, pero sirvió para entender mejor la programación de GUI, la programación de juegos y cómo funciona un motor de ajedrez
- El almacén clave-valor se usó para aprender programación de sistemas y a escribir código más eficiente mientras implementaba parte de la API de Redis
- La utilidad de Wake-on-LAN fue un proyecto para aprender cómo funciona WOL y la programación de redes en Rust
- La visualización de partidas de ajedrez permitió experimentar con cómo hacer arte con código y visualizar un juego favorito
- En la base de datos de ajedrez aprendió mucho sobre bitmaps y la estructura interna de las bases de datos
- También creó una herramienta basada en LLM que “explica condescendientemente” qué hace un comando
- La implementación del protocolo del lado del servidor POP3 quedó incompleta, pero fue divertida para aprender el protocolo e imaginar cómo sería una app basada en POP3
- Al seguir “Crafting Interpreters” en Rust, aprendió mucho sobre intérpretes y compiladores, y la meta no era terminar, sino disfrutar el proceso
- “Mazes for Programmers” lo llevó hasta más o menos la mitad en Rust, pero lo abandonó cuando empezó a sentirse como trabajo, y no quiso seguir
- También escribió scripts pequeños para jugar con ideas y conceptos y hacer experimentos
- Hurl también es una forma de este juego, y aunque no sea útil, el proceso de aprender y crear algo puede ser divertido
1 comentarios
Opiniones de Hacker News
Me encanta crear software inútil. Solo de lo que hice este año están el uncolouring book de https://lines.potato.horse, MeatGPT de https://meat-gpt.sonnet.io, Medieval Content Farm de https://tidings.potato.horse, You deserve butter de https://butter.sonnet.io, Mrr de https://mrr.sonnet.io y el Mrr físicamente preciso de https://mrrr.sonnet.io
Algunos de ellos en realidad se parecen más a posts de blog elaborados y están sobredimensionados porque me resulta más fácil expresarme jugando con código que resolviendo problemas reales. Hay una lista más larga en https://sonnet.io./projects
Mi hijo de 8 años usa Scratch todos los días y a menudo lo ayudo cuando tiene preguntas; fue bastante divertido hacer, solo por diversión, un proyecto absurdo con animaciones inútiles incluidas. Gracias a eso, en casa ahora “Hurry to love! Hurry to love!” se volvió una frase recurrente
De hecho, me había olvidado de bastantes de esas cosas
Totalmente de acuerdo. Hace poco fui a una escuela de payasos y me di cuenta de que estaba demasiado obsesionado con hacer los proyectos de forma “correcta” o “bien”
La vida es para vivirla, y si intentas hacer el software demasiado “correctamente”, le exprimes toda la diversión. Así que últimamente intento escribir código con más disfrute, y eso hizo que escriba mucho más código y que todo fluya con más facilidad. Hace poco hice mi propia biblioteca de serialización binaria estilo protobuf para probar una idea de evolución de esquemas, y ahora estoy construyendo una base de datos local-first basada en CRDT. Ayer logré la primera sincronización de datos y me emocionó muchísimo. Durante años escribí mucho código para resolver Serious Problems y también mucho código impulsivo, pero irónicamente el código del que más orgullo siento es el que hice por diversión. A los proyectos divertidos sigo volviendo para mantenerlos y mejorarlos, mientras que los proyectos serios muchas veces se marchitan y mueren cuando me voy
En los juegos, en vez de entrar en ritmo y confiar en el proceso, la gente empieza a leer guías para crear el personaje más fuerte, maximizar atributos y apuntar al 100% de completado. Al final desaparecen la exploración y la alegría de los encuentros casuales que hacían bueno al juego, y uno termina dedicando tiempo a maximizar estadísticas como si fueran tiradas aleatorias de dados. Con otras actividades pasa algo parecido: mientras intentas maximizar algo, ya sea riqueza o calidad del código, desaparecen el asombro y el “simplemente probar”
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
Pero cuando caí en la optimización, de pronto se volvió un juego con una sola respuesta correcta, y de la noche a la mañana se le fue toda la diversión. Muchas veces se aprende más haciendo algo terriblemente mal por soberbia y capricho. La idea de “¿qué tan difícil puede ser?” me metió varias veces en profundidades que no podía manejar, pero al salir de ahí siempre aprendí muchísimo y también encontré diversión
En cualquier oficio (craft) hay una parte contraintuitiva: si simplemente haces más, por lo general acabas mejorando. Escribe relatos malos, moldea cerámica fea, pinta paisajes torcidos
Puede haber un efecto de práctica, pero también pesa mucho nuestra tendencia a descartar ideas por nuestra cuenta si no vemos con total claridad en la mente el producto terminado que podríamos esperar. Para alguien analítico en particular, se siente como una decisión inteligente para reducir tiempo desperdiciado, pero al mismo tiempo es una forma segura de no crear nada. Muchos proyectos de software “inútiles” siguieron siendo inútiles, pero otros encontraron una utilidad mayor durante el proceso de hacerlos. Al final esto lleva al cliché de “fallas el 100% de los tiros que no intentas”, pero se entiende la idea
Esto no solo va de escribir software “inútil”; también es un argumento para evitar las llamadas mejores prácticas en proyectos pequeños
Hice un generador de sitios estáticos para un catálogo de artículos, y el catálogo es simple y no cambia con frecuencia. Después de darle vueltas a qué base de datos usar, al final decidí meterlo todo en un arreglo estático dentro del codebase. Es una dependencia menos en la que pensar, y para mi propósito encaja perfectamente
No sé si realmente lo cambiaron así, pero desde entonces, cada vez que sale la frase “necesitamos una base de datos”, esa es siempre la primera pregunta que hago
De todos modos cargo todos los datos en memoria para ejecutar algoritmos de grafos, así que me di cuenta de que guardar datos de solo lectura en una base de datos casi no tenía sentido. No tengo ninguna intención de implementar Bellman-Ford en SQL
Aprendí esto programando con un amigo al que consideraba un pésimo coder
Nos llevábamos bien e hicimos juntos muchos proyectos divertidos, pero él realmente parecía no saber qué estaba haciendo. Copiar/pegar por todos lados, sin arquitectura, sin diseño, malos nombres, y la mitad del tiempo ni siquiera estaba seguro de qué hacía realmente el código. Pero funcionaba. Al final me di cuenta de que él lograba hacer más cosas que yo. No se quedaba atorado en detalles insignificantes y trabajaba muchísimo más. No escribía pruebas unitarias, pero jugaba con el resultado como un niño y lo probaba manualmente todo el tiempo. Terminé aceptando esa forma de pensar. No existía un software de contactos que hiciera lo que quería, así que intenté hacerlo yo mismo; pero en vez de intentar crear una UI elegante, usé django-admin y listo. Llevo 10 años usando ese horrible conjunto de formularios y hace lo que tiene que hacer. Cuando no había un CLI para TOTP, hice uno en Python y volqué las seeds en TOML en texto plano. Tardé 5 años en agregar cifrado, porque bastaba con hacer un enlace simbólico al archivo desde un contenedor de Veracrypt y era poco trabajo. Hace dos meses quería un temporizador cuyo presupuesto de tiempo aumentara cuando hago ejercicio y se consumiera cuando juego videojuegos, así que lo hice (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). Pegué un montón de Tailwind escupido por ChatGPT y lo controlé con HTMX, y con eso fue suficiente. Se lo mostré a amigos y 4 me pidieron cuentas; uno pidió probarlo con médicos para un programa de adicciones. Ni siquiera tenía formulario de registro, así que los hardcodeé. Me gustaría decirle a mi yo joven que dejara de obsesionarse con hacer las cosas correctamente o con trabajar solo en problemas importantes. De todos modos, en toda mi vida nunca he llegado a esa “corrección”
Desde que empecé a dejar el nombre que pone el IDE hasta demostrar que el proyecto es interesante, siento que mi tasa de éxito subió. Parece relacionado con el mismo principio de fondo
Hay una lógica curiosa, especialmente cuando limpias código de otra persona. Maldices diciendo “¿en qué demonios estaba pensando?”, pero al mismo tiempo está el hecho de que esa persona al menos lo puso en marcha
Pero ganaba 100 dólares por hora en un país de salarios bajos. Compraba dominios y contenido, rehacía el software, hacía cosas como optimización para motores de búsqueda, y después de 3 meses lo vendía por 10 veces el precio de compra. Unos 7000 dólares de ganancia por 3 meses de trabajo no está mal, y probablemente ni siquiera era su trabajo de tiempo completo
Pero mi conclusión fue esta. Primero, fallan tan seguido como tienen éxito, es imposible predecir de qué lado caerá, y como arreglarlo después es más difícil que no hacerlo así desde el principio, se siente como una apuesta con valor esperado negativo. Segundo, personalmente odio trabajar de esa manera. Tercero, por eso no quiero dedicar tiempo a trabajos en los que ese enfoque pueda parecer razonable. Esa experiencia me llevó a buscar proyectos más profundos y grandes, en vez de una sucesión de tareas pequeñas y triviales. A cambio, ahora acepto con mucha más comodidad que otras personas puedan tener preferencias distintas a las mías. Pienso más en el método que me queda bien que en la forma correcta de hacer software
Aun así funciona. Es duro, pero productivo, y estoy aprendiendo mucho en el proceso. Sé cómo ordenarlo después, pulirlo y hacerlo mantenible y extensible, así que lo haré cuando ya exista algo que realmente funcione. Apoyo bastante este enfoque, sobre todo al probar cosas nuevas, porque en el pasado también me resultó bastante productivo
Apple rechazó una vez mi app porque era inútil. El equipo de revisión de apps me llamó personalmente para decirme que esta app era inútil y que no sería aprobada para la Mac App Store.
Unos 12 años después, miles de personas usaban esa pequeña app inútil, KeyboardCleanTool. Es una app gratuita muy pequeña que bloquea tanto el teclado como la entrada de la Touch Bar, y la gente la usaba de formas que uno ni se imaginaría. Por ejemplo, dejar que un bebé golpeara el teclado a gusto, o dejar que un gato durmiera sobre la laptop. Lo que es útil es realmente subjetivo.
Después de unas diez búsquedas más, en un artículo sobre buenas formas de limpiar el teclado, entendí recién al ver que recomendaban esa app porque permitía bloquear el teclado. Al final la descargué y, para ser una app “inútil”, resultó bastante útil.
Cuando era chico, mi madre encendió por accidente nuestra Mac IIsi mientras limpiaba, y usé eso como excusa para convencerla de que necesitábamos el protector de pantalla After Dark. Poco después aparecieron tostadoras volando por la pantalla. Qué nostalgia.
Para ver el polvo que podía rayar al limpiar, necesitaba que la pantalla de la MacBook y los monitores quedaran completamente negros, y que el trackpad también se desactivara. La combinación de teclas para desactivar el modo de limpieza tenía que ser difícil de activar por accidente y fácil de recordar, así que elegí presionar la tecla Command al menos 8 veces seguidas. Las prácticas de revisión de apps de Apple siempre son irritantes. No entiendo por qué intentan decidir en nombre de los usuarios qué es útil. Y eso sin mencionar que apps fraudulentas que sí pasan la revisión sobreviven meses en la App Store.
Me encanta usar software expresivo y divertido. Lo hago para aprender y explorar, y eso fue lo que me atrajo a la programación y me mantiene ahí.
Por desgracia, se mete la necesidad. Bajo la amenaza del hambre, hay que ser productivo. Me importan las personas con las que produzco, y me siento culpable si no produzco. Eso termina absorbiendo incluso la motivación de mi tiempo personal. Me sorprende que haya tantas personas con la estabilidad y la libertad para expresarse. Envidio, aunque también me alegra por ellos, a quienes pueden ir al Recurse Center, a quienes tienen montones de posts de blog llenos de proyectos personales y relatos de aventuras. Probablemente la mayoría trabajó duro para llegar a una posición en la que pudiera construir esa vida. Yo también quiero hacerlo. Pero para lograrlo parece que debo quemar más vida en productividad. Si sacrifico suficientes años, tal vez la suerte me conceda el derecho a disfrutar la vida. Es gracioso. Y entonces disfrutaré más el software inútil.
Antes sentía que crear software útil era la marca de un desarrollador de software competente, y no dedicaba tiempo a nada que no fuera obviamente útil de una forma fácil de explicar.
Esa es una excelente manera de convertir el software en una tarea tediosa. Ahora me siento cómodo haciendo cosas inútiles, y es divertido. Rehago ideas que ya existen de maneras nuevas, y no me importa si alguien ya lo hizo. Si es solo por diversión, también puede hacerse de la misma manera, como hacer un cover de una canción de otra persona. Aprendes, disfrutas, y eso tiene valor por sí mismo. A veces también encuentras formas de mejorar. Aprendí esto cuando empecé a escribir firmware. La presión de que todo tuviera que ser útil era enorme, y tuve que bajar el ego y hacerme a un lado. Descubrí que escribir código desprolijo que hace cosas tontas es muy divertido, y se volvió una gran forma de aprender con poca presión y experimentar ideas con gusto. Además, las cosas inútiles a veces terminan siendo sorprendentemente útiles. Todas las cosas inútiles que hice en los últimos años terminaron llevando a código, ideas o conocimientos útiles e inesperados.
Hace mucho tiempo dirigí un grupo llamado Houston Recreational Computer Programming Group. Era un grupo dedicado casi por completo a mostrar proyectos de software inútiles y divertidos, y la pasábamos muy bien.
Ahora me mudé, y no sé si la ciudad donde vivo actualmente sea lo bastante grande como para armar un grupo así, ni si tengo la energía para volver a dirigirlo. En lo personal, lo que me gustaba era que una vez al mes tenía que preparar un pequeño proyecto para mostrar por si nadie llevaba nada. En unos 2 años eso pasó solo unas pocas veces, pero uno de esos proyectos[1] salió bastante bien y me enorgullece. Tampoco es completamente inútil. [1] https://github.com/smcameron/gaseous-giganticus
Acabo de terminar un software inútil hace apenas unos minutos, así que este artículo llega muy oportunamente.
CFR Brackets: https://susam.net/cfr.html
Demo: https://susam.net/cfr.html#3
Source: https://github.com/susam/cfr
Es un lenguaje de dibujo muy pequeño que solo admite 5 comandos: C(cambiar color), F(avanzar), R(rotar), [(inicio de bloque), ](repetir bloque). Los comandos están un poco inspirados en el lenguaje de programación Logo, y el minimalismo en P′′. Sin embargo, a diferencia de ambos, no es Turing-completo. No está pensado para un uso práctico; lo hice por diversión. Pienso seguir jugando con él dibujando formas interesantes mientras mantengo el código de entrada lo más pequeño posible. “Creo que es extraordinariamente importante mantener la diversión de la computación en la ciencia de la computación.” — Alan J. Perlis