La sensibilidad tecnológica es una práctica
El olfato para el software no se adquiere leyendo. Sobre Git en el centro de una empresa, UNIX como patrón oro y por qué todo el mundo acaba siendo técnico.
Una reflexión de Jaime Gómez-Obregón me trajo algunos recuerdos de mi trabajo en Carto. Una empresa singular donde Git estaba en el centro de una buena parte de sus operaciones.
No de las operaciones de ingeniería. De las operaciones. Contratos, documentación, propuestas, decisiones. Lo que significaba que una persona que entraba en un rol comercial o de soporte adquiría, sin que nada de aquello se planteara como formación, una intuición práctica sobre ramas, conflictos de fusión, historial y el hecho de que algunas cosas no se pueden deshacer.
También me llevó a varias conversaciones interesantes donde pude volver a subrayar varios temas a los que siempre doy mucha importancia.
La sensibilidad hacia el software se interioriza mejor a través de su uso
No se llega leyendo. Esta es la parte que se resiste a todo intento de resolverla con un curso.
La distinción de Michael Polanyi es la útil: hay conocimiento que podemos articular y conocimiento que solo podemos demostrar, y el segundo se adquiere haciendo. Puedes explicar qué es un conflicto de fusión en noventa segundos. Lo que esa explicación no transmite es la sensación de haber provocado uno, el pequeño sobresalto de descubrir que dos personas resolvieron el mismo problema de forma distinta, el instinto que te lleva a comunicarte antes la próxima vez. Ese instinto es lo que de verdad mueve las decisiones de producto, y no llega por un diagrama.
Por eso el valor de que Git estuviera en el centro de las operaciones de Carto no era la herramienta. Era la exposición. Alguien sin perfil técnico que ha vivido de verdad dentro de un repositorio entiende algo sobre la irreversibilidad, sobre el trabajo en paralelo, sobre el coste de la divergencia, que ninguna cantidad de explicación le habría instalado.
El relato del oficio de Sennett hace el mismo argumento por el otro extremo: el juicio sobre un material se gana con tiempo pasado con el material, y no hay atajos, solo sustitutos que parecen atajos.
Algunas ideas clásicas de UNIX siguen siendo el patrón oro
Para entender la naturaleza del software, sigo sin encontrar nada mejor que la tradición UNIX. La formulación de Doug McIlroy es la compacta: escribe programas que hagan una cosa y la hagan bien; escribe programas que trabajen juntos; escribe programas que manejen flujos de texto, porque es una interfaz universal.
Se lee como consejo de ingeniería. Está más cerca de una teoría de las organizaciones. Cada una de esas restricciones trata del límite entre un trabajo y el siguiente, de hacer que tu salida sea utilizable por alguien cuyos planes no conoces. El libro de Kernighan y Pike es en gran medida una demostración extendida de lo que se vuelve posible una vez que esa disciplina existe, y la síntesis posterior de Eric Raymond es el argumento de por qué la disciplina sobrevivió a competidores mucho mejor financiados.
Las propiedades que produce son exactamente las que las organizaciones de producto dicen querer. Cosas que puedes inspeccionar. Cosas que puedes reemplazar sin reescribirlo todo. Piezas pequeñas sobre las que puedes razonar por separado, que es la única defensa contra los sistemas que nadie entiende. Esta es la respuesta práctica al problema de las cajas negras: no puedes eliminar la opacidad, pero puedes decidir cuánta construyes a propósito.
El software transforma por completo las organizaciones
El software, como mancha de aceite, transforma por completo las organizaciones, haciendo que todo el mundo sea, de alguna forma, ese «técnico» del que habla Jaime.
La transformación no consiste en que la gente aprenda a programar. Consiste en que deja de aguantar el límite de quién tiene que pensar en el software. Soporte decide qué cuenta como error. Ventas hace compromisos que se convierten en arquitectura. Legal escribe una cláusula que acaba siendo un modelo de datos. Finanzas elige un periodo de facturación que dará forma a un esquema durante una década. Ninguna de esas personas tiene «ingeniero» en el cargo y todas están tomando decisiones de software, normalmente sin que nadie les haya avisado de que eso es lo que está pasando.
Lo que convierte la sensibilidad en un requisito distribuido y no departamental. Y los requisitos distribuidos no se satisfacen con un presupuesto de formación. Se satisfacen organizando el trabajo de forma que la gente toque el material: poniendo el repositorio, los registros, las tasas de error y el despliegue en algún sitio que no puedan esquivar.
Las memorias de Linus Torvalds merecen una lectura exactamente por esto, y no por la biografía. Lo que se transmite es alguien que entendió un sistema porque lo usó todos los días durante años, sin plan de entenderlo y sin plan de estudios. La comprensión fue un subproducto de tocarlo.
La sensibilidad tecnológica no se adquiere. Se practica, o no se tiene.