Mi sesgo de científico: Por qué tuve que desaprender para poder construir

This post is also available in English.

Había algo que no me cerraba en la academia. Me fascinaba la teoría, la elegancia de los modelos, pero me encontraba cada vez más alejado de una pregunta fundamental: ¿cómo se construyen las cosas? ¿Cómo se pasa de una idea en un pizarrón a un sistema que funciona en el mundo real, que no se rompe, que entrega valor de forma consistente?

Decidí hacer mi tesis en física aplicada, un intento de acercarme al “hacer”. La experiencia fue brutal y reveladora. Mis días no se iban en la belleza de la física, sino en una batalla constante contra la fragilidad de mi propio código. Simulaciones que corrían distinto cada vez, resultados que no podía garantizar, y una sensación permanente de que todo estaba atado con alambre.

Esto era 2016. La “crisis de la reproducibilidad” no era un titular que leía en Nature, era la realidad de mis madrugadas. Era mi frustración¹.

Ese fue el quiebre. Entendí que mi verdadera vocación no era descubrir la siguiente ley de la física, sino entender cómo construir sistemas donde cada número importa y cada resultado es verificable.

El viaje me llevó a lugares como JPMorgan, Qontigo y Mercado Libre. No fui a buscar prestigio, fui a buscar respuestas. Quería ver cómo lo hacían los equipos que no se podían permitir un error de redondeo. Y lo que descubrí fue profundo: la construcción de software robusto, especialmente en dominios numéricos, no es una extensión de la ciencia. Es una disciplina en sí misma.

Ahí entendí mi propio sesgo. La universidad me había entrenado durante años para ser un experto en análisis, en deconstruir problemas complejos hasta su mínima expresión. Es lo que hace un científico. Pero construir es un acto de síntesis². Es tomar piezas y componer un todo que es más grande y más fuerte que la suma de sus partes.

Es como ser un brillante arquitecto teórico, capaz de diseñar los planos más innovadores y entender las fuerzas estructurales a un nivel fundamental. Pero de repente te piden que lideres la construcción en el terreno: que gestiones al equipo, soluciones la falta de un material o te adaptes a una lluvia imprevista. Tu conocimiento del plano es vital, pero las habilidades para levantar la estructura en el mundo real son otras. Tuve que aprender a ser el constructor, no solo el arquitecto.

Phorma³ es la cristalización de ese viaje. Es mi respuesta a la frustración que sentí en mi tesis y que veo replicada en tantos equipos de I+D, finanzas y ciencia de datos. Equipos llenos de gente brillante, frenados por la fricción de herramientas y procesos que no están a la altura de su talento.

No se trata de encontrar una fórmula mágica. Se trata de aplicar una disciplina de ingeniería que ya existe, pero adaptada al contexto específico de la investigación y el desarrollo. Es saber qué prácticas usar, cómo y cuándo. Phorma es el mapa que me hubiese gustado tener hace diez años, para no tener que dibujarlo a ciegas.

Y acá es donde todo conecta con una misión más grande. Conozco de cerca la realidad de la ciencia en Argentina y Latinoamérica: el talento sobra, pero la financiación escasea. Por otro lado, veo a una industria con capital, buscando desesperadamente el tipo de capital intelectual que nuestras universidades producen en masa.

El verdadero potencial no está en que la industria simplemente “contrate” científicos para que dejen de serlo. Está en crear un puente⁴. Un puente donde el rigor del pensamiento científico pueda fusionarse con la disciplina de la ingeniería de software para crear algo nuevo. Algo que genere valor económico y, al mismo tiempo, haga avanzar el conocimiento.

Phorma es mi primer intento de construir ese puente. No será fácil. Pero es una convicción profunda que nació de mi propia historia.

Si algo de esto te resuena, si ves arquitectos brillantes frustrados porque el edificio no avanza, hablemos.

Notas