Muchas veces, cuando estudiamos ingeniería, construimos pensando en el presente. Resolver un ejercicio, entregar un proyecto, hacer que un programa funcione o encontrar una respuesta para una clase. Aprendemos a solucionar problemas dentro de un contexto concreto, pero pocas veces pensamos en lo que ocurre cuando aquello que construimos deja de ser una entrega y empieza a formar parte de la vida de otra persona.

Eso fue lo que comenzó a cambiar cuando desarrolle un sistema para la gestión de donaciones de medicamentos, compuesto por un chatbot en Telegram y una plataforma web. Ya no se trataba únicamente de escribir código, conectar una base de datos o hacer que cada función cumpliera su propósito. Había alguien al otro lado que tendría que utilizarlo. Alguien que no conocía cómo estaba construido el sistema ni tenía por qué conocerlo. Y entonces el problema dejó de ser solamente cómo hacerlo funcionar, para convertirse también en cómo hacer que pudiera ser comprendido.

Antes de entregarlo, ya había intentado ponerme en el lugar de quien lo utilizaría. Pensé en su nivel de conocimiento, en las posibles dificultades y diseñé un proceso guiado para acompañar cada etapa. Creía que había anticipado buena parte de esas necesidades. Sin embargo, al momento de explicarlo aparecieron preguntas que, aunque podían parecer simples, me hicieron detenerme.

Algunas de esas preguntas no señalaban necesariamente un gran error. Señalaban algo más difícil de encontrar: aquello que yo había dejado de cuestionar porque, desde mi perspectiva, ya era evidente.

Cuando conocemos una herramienta durante mucho tiempo, comenzamos a olvidar cómo era no conocerla. Una acción que para nosotros parece natural puede esconder varios pasos para alguien más. Una palabra que utilizamos todos los días puede no significar lo mismo para quien nunca ha tenido que enfrentarse a ella.

Lo intuitivo, muchas veces, solo es intuitivo para quien ya sabe cómo funciona.

Ahí entendí que pensar en el usuario no consiste simplemente en imaginarlo antes de construir. También significa escucharlo después.

Cada pregunta permitía encontrar un punto que podía explicarse mejor, simplificarse o incluso replantearse. Y fue allí donde la refactorización adquirió otro significado para mí. No era solamente volver al código para hacerlo más limpio o eficiente. También era volver sobre nuestras decisiones para preguntarme si aquello que había construido seguía teniendo sentido frente a la experiencia real de quien lo utilizaba.

A veces pensamos que construir significa avanzar hasta llegar a una versión final. Pero quizá construir también implica saber regresar. Reconocer que algo puede funcionar y, aun así, necesitar ser cambiado. Entender que una solución no está terminada únicamente porque cumple técnicamente con lo que fue programado.

Y en medio de ese proceso ocurrió algo que también cambió mi manera de entender la relación entre quien construye y quien utiliza una tecnología.

La persona a la que se estuvo enseñando tenía conocimientos muy amplios en su propio campo. Mientras yo podía explicar cómo funcionaba el sistema, él podía comprender profundamente el contexto en el que ese sistema debía existir. Yo conocía la herramienta desde su construcción; él conocía el problema desde su experiencia.

Entonces enseñar dejó de ser una relación en una sola dirección.

Quizás hacer ingeniería también consiste en eso: aceptar que nuestro conocimiento siempre tiene un límite. Que podemos saber construir una solución y, al mismo tiempo, todavía tener mucho que aprender sobre la persona para la que la construimos.

Por eso, hoy pienso que aprender ingeniería no es solamente acumular herramientas, lenguajes o métodos para resolver problemas. También es aprender a observar, a equivocarse, a volver atrás y a escuchar. Es entender que detrás de cada sistema hay alguien que tendrá que apropiarse de él y que, en ese encuentro, nuestra propia forma de construir puede cambiar.

Porque construir para otros también significa aprender a mirar desde el otro lado.

Y quizás allí está una parte esencial de hacer ingeniería: estar dispuesto a descubrir, junto a otros, cuáles son las preguntas que todavía no habíamos hecho.