Programar es escribir

Parece que diseñar también. Y liderar productos.

Como puedes inferir del título, esta vez el tema es medio técnico y desde mi experiencia como ingeniero de software. Pero me tinca que aplica también a otros “rubros”.

Cuando empecé a trabajar era suuuper común la analogía de que el software era como hacer edificios. Entre muchas de las malas conclusiones de esa mala analogía es que los arquitectos diseñan la solución y luego vienen los programadores e implementan, cuales obreros modernos.

Es un malentendido fatal. Entre otras cosas dió origen a:

• Mucha cosa waterfall-istica que hasta el día de hoy nos pena, como el sesgo a organizarnos demasiado en “proyectos”.

• Arquitectos astronáuticos que muchas veces inventamos soluciones elegantísimas a problemas que no existían o eran poco relevantes, a veces a punta de puros diagramas (como los otros arquitectos que hacen edificios) y poquito código real.

• Desarrolladores que pensamos que la pega era implementar no más. Responsables de hacer las cosas correctamente pero sin mucha responsabilidad sobre hacer las cosas correctas y que valen la pena hacer.

Hoy tocaremos este último punto.

---

Acá voy con una anécdota personal y real 😊.

Aproximadamente una vez al mes me junto con el team Get on Board para ayudarlos en lo que puedo. Con el tiempo me he vuelto menos útil, porque van creciendo y armando un equipo muy pro: cada vez hay menos cosas que quizás yo cacho y ellos no.

Un día me cuenta Sergio (CEO, de profesión diseñador) que va a invitar a Maca (Líder en Producto, de profesión sicóloga) a la reu. Me dice que quiere aprovechar la instancia para que les saque dudas con un algoritmo que escribí hace un par de años.

Que miedo. Cualquier código que he escrito hace más de algunos meses atrás bien podría haberla escrita otro desarrollador. No tengo buena memoria para estas cosas.

Más encima es un algoritmo de machine learning que aprende de los datos que vemos pasar para ayudar a tomar mejores decisiones. Más miedo.

Llegamos a la reunión y Sergio procedió a re-explicarme el código. Para mi inesperado orgullo, se apoyó en los comentarios escritos por el Leo-del-pasado. El código en sí también estaba súper legible y rápidamente pudimos pasar a discutir si el algoritmo servía para un problema nuevo que querían resolver. No tanto, fue la conclusión. Podíamos usar otras cosas más simples primero.

---

Sergio y Maca son profesionales extraordinarios. La mayor parte del mérito acá es de ellos, que sin haber aprendido a programar en su educación formal, usaron el superpoder de aprender-a-aprender para defenderse muy bien en el mundo del código.

Dicho eso, el Leo-del-pasado que escribió ese código merece créditos también.

Como muchas cosas, esto es algo que aprendí a porrazos. No hay nada más frustrante que no entender el código que tú mismo escribiste. Me pasó. Incluida la versión más graciosa de patear la perra al estilo de “quién diablos habrá escrito esta cuestión tan enredada” para luego encontrar mi propio nombre en los logs del control de versiones como el flamante autor de “esa cuestión tan enredada” 😂 .

Fue una linda lección de empatía. Si uno mismo no puede entender lo que uno hizo hace unos años o inclusos meses atrás, que queda para las otras personas con quienes trabajas.

Por eso:

“Los programas deben ser escritos para que los lean las personas, y sólo incidentalmente para que lo ejecuten las máquinas”

— Harold Abelson

Por eso el lenguaje de programación importa. Por eso a veces un trade-off de usar un lenguaje “lento” pero más expresivo termina siendo buena elección (aunque hay algunos lenguajes modernos que mezclan expresividad y eficiencia). Por eso no me suelen gustar los “generadores de código” cuando el código generado pasa a ser parte del programa. Te ahorran la lata al escribir, pero después a tí y a otros les toca leer leseras repetitivas.

Por eso importa dejar buenos mensajes de “commit” para explicar los cambios que uno hace. Sobre todo explicar los por-qués. Si no los escribes, sólo viven en tu cabeza y esa memoria después se pierde.

Al final el código es el diseño de un software. El código son los “planos”, en aquella mala analogía. Los diagramas, dibujos y prosa explicativa son una tremenda ayuda para leer los “planos”. Muy necesaria, pero jamás suficiente. El código, en resumen, es donde formalizamos (y constantemente evolucionamos) la solución a un problema.

Hasta acá todo esto parece el enésimo rant de que los desarrolladores cumplamos con buenas prácticas de documentación. Pero a cambio de toda esta parte molestosa, viene una parte muy poderosa. “Una gran poder conlleva una gran responsabilidad”, diría el tío Ben. A veces entre tanta responsabilidad se nos olvida el poder que ganamos 😅 .

El software se come el mundo porque programar es como escribir. Cierto, el código compilado/interpretado por máquinas hace cosas asombrosas. Pero más asombroso es lo que conseguimos mediante la colaboración de muchas personas sobre el código (¡sobre soluciones a problemas!) a lo largo de meses, años, décadas y generaciones.

Es como lo que hacen los científicos (creando papers que citan otros papers que citan otros papers) pero sin tanta burocracia y aplicado para cosas útiles.

Broma 😬 . Lo que hacemos en la industria no sería posible sin la ciencia 🤗 .

De vuelta a mi punto, es lo que planteaba en “Escribir”:

Lo que escribes, en cambio, pasa a tener existencia propia. Es como hacer un fork de uno mismo, que puede interactuar con otras personas mientras uno sigue haciendo su vida normal.

Uno puede dejar de trabajar en un producto y aún así tu fork puede ayudar a otros programadores a resolver sus problemas. Programadores desconocidos, a veces desde el pasado, te pueden ayudar gracias a esa función que resuelve lo que necesitas o gracias a ese código bien explicado que te permite adaptarlo o quitarle un bug.

El open-source es un amplificador impresionante de todo esto. Las APIs también. Y StackOverflow, sin duda.

Esto no es una volada no más. No tengo dudas, pero sí tengo pruebas. Lo que sea que programaste esta semana está basado en millones de líneas de código escritos por otros. En la otra cara de la moneda, mi anécdota entretenida es que hace unos años código que escribí terminó ayudando a desarrolladores de Firefox. Conozco muchos otros con experiencias más potentes.

¿Será que todo esto aplica a otras disciplinas? ¿Aplica a diseño? ¿Aplica a liderazgo de productos?

Yo creo que sí. Primero pensé que no. Los programadores la tenemos fácil en confundirnos porque el código engañosamente parece ser para máquinas en vez de para personas (¡probablemente así lo siguen enseñando!). Pero los diseñadores normalmente comunican sus diseños a otros humanos.

Excepto que no es lo mismo comunicar un diseño a quien esperas que te ayude a implementarlo versus quien tendrá que evolucionar o entender ese diseño. Y me soplaron en Continuum que es común encontrarse con documentación que dice como usar o implementar un cierto diseño (o incluso un sistema de diseño) pero sin la parte clave de las razones detrás de las decisiones de diseño.

Lo mismo en equipo de productos. Solemos tenemos un lindo tablero histórico sobre las cosas que decidimos hacer, pero no es tan común que sobreviva la información de por qué decidimos hacerlas. Me declaro culpable.

¿Cuánto poder nos farreamos por no tomar la responsabilidad (o conciencia) de que crear/colaborar es escribir?

PD: También puedes responder este correo si quieres comentar en privado. Siempre leo todas las respuestas 🙂