Yo miro un programa como miro una cerradura: antes de meter la llave, ya alguien decidió qué puerta existe. Cuando programamos, empezamos a tomar decisiones mucho antes de escribir la primera línea de código. Decidimos qué vale la pena observar, cómo ordenar lo que encontramos y qué vamos a aceptar como una respuesta válida. Parecen decisiones técnicas, limpias, de esas que suenan a teclado y café frío. Pero por debajo traen una manera de entender el mundo.
La epistemología nos obliga a detener la mano justo ahí. ¿Qué sabemos realmente? ¿Qué estamos dando por hecho? ¿Qué dejamos fuera para que el sistema parezca ordenado? Uno puede llamar “bienestar” a una variable, asignarle un número y mostrarlo en un gráfico impecable. Pero detrás de ese número puede haber una persona que se siente acompañada por sus compañeros y, al mismo tiempo, agotada por su trabajo. La pregunta incómoda es simple: ¿cuánto de esa experiencia cabe en nuestra medición?
Los programas pueden calcular con precisión y nuestra interpretación seguir siendo incompleta. Esa es la parte que a veces se esconde bajo la alfombra del dashboard. El dato no miente por sí solo, pero tampoco habla entero. Hay que preguntarle de dónde viene, quién lo nombró, quién quedó fuera, quién tuvo que simplificarse para entrar en la planilla.
La recursividad ofrece una imagen buena para pensar este problema. En programación, una función puede llamarse a sí misma para resolver una parte del problema hasta llegar a una condición que detenga el proceso. Pero repetir una operación no significa aprender. También nosotros podemos darle vueltas a una idea, volver sobre la misma explicación, ejecutar otra vez el mismo supuesto y terminar encerrados en una pieza que tiene muchas llaves, pero ninguna ventana.
Con el conocimiento pasa algo parecido, aunque no sea una función. Observamos, construimos un modelo, revisamos lo que produce y volvemos a nuestras preguntas. Ese recorrido solo tiene sentido si estamos dispuestos a cambiar de opinión. Si la evidencia nunca puede incomodarnos, difícilmente podrá enseñarnos algo. Un sistema que confirma siempre lo que ya pensábamos no está pensando con nosotros: está barnizando nuestra costumbre.
Anthony Giddens mete otra llave en la chapa cuando habla de la doble hermenéutica. La idea, dicha sin ponerse solemne, es esta: cuando estudiamos la vida social, no observamos piedras ni tornillos mudos; observamos personas que ya interpretan lo que viven. Y esas personas pueden conocer nuestras conclusiones, responder a ellas, rechazarlas, usarlas o quedar atrapadas por ellas.
Imaginemos que una plataforma describe a un equipo como “poco comprometido”. Para quienes diseñaron el sistema, puede ser una categoría de análisis. Para quienes trabajan ahí, puede sentirse como un juicio sobre su esfuerzo. Quizás alguien pregunte por qué se mide su compromiso sin considerar la sobrecarga que enfrenta, el cansancio acumulado o la forma en que la jefatura organiza el trabajo.
El problema se pone más fino cuando esa etiqueta empieza a actuar. Una jefatura puede usar el resultado para aumentar el control. El equipo, sintiéndose observado o castigado, puede cambiar su conducta. Cuando volvamos a medir, aquella primera conclusión ya no será solo una descripción: habrá intervenido en la realidad que decía mirar. La medición se volvió parte del mecanismo.
Por eso no basta con decir que el modelo “funciona”. ¿Funciona para quién? ¿Abre qué puerta? ¿Cierra cuál? ¿A quién convierte en número y a quién le permite explicar el número? Si una persona puede decir “ese resultado no representa lo que estoy viviendo” y el sistema no tiene dónde alojar esa frase, entonces el modelo no está completo: está sordo con buena interfaz.
Yo desconfío de los sistemas que parecen demasiado seguros de sus categorías. La vida humana rara vez cabe en un solo campo. A veces una variable ayuda a ver algo que antes pasaba inadvertido; otras veces convierte una experiencia compleja en una chapa falsa. El asunto no es dejar de medir. El asunto es medir sabiendo que cada medición trae una sombra.
Programar tecnología para comprender a otros exige escuchar lo que sus experiencias dicen de nuestros modelos. ¿Quién eligió las categorías? ¿Qué quedó fuera? ¿Hay espacio para corregir el marco? ¿Podemos distinguir entre calcular bien y comprender bien? Porque una cosa es que el algoritmo devuelva una respuesta y otra muy distinta es que esa respuesta sea justa, suficiente o humana.
La clave, como casi siempre, estaba fuera del mapa. Programar no es solo escribir instrucciones para una máquina. También es declarar qué mundo creemos que existe. Y si ese mundo no deja hablar a quienes pretende medir, entonces la cerradura podrá brillar mucho, pero seguirá cerrada por dentro.
Ultima picadura
Programar para comprender a otros exige una humildad precisa: medir mejor, escuchar más y permitir que la experiencia contradiga la cerradura.
![]()
"Si Sor Tadea de San Joaquin dejó memoria con trabajo y disciplina, hoy la medida mínima es registro claro, continuidad real y responsabilidad para no hacer perder el tiempo."
Candela Dura
Waldo Key
Todavia no hay comentarios aprobados en esta pieza.