⏱️ Lectura: 14 min
A los pocos meses de graduarse, Thienan Tran se dio cuenta de algo incómodo: tenía trabajo, tenía rutina, pero no tenía amigos. Cada noche buscaba en Google cómo hacer amigos después de la universidad y obtenía siempre la misma respuesta: hacer un hobby con otra gente, frecuentemente. Como su hobby principal era programar y los meetups locales ocurrían apenas una vez al mes, le quedaba el gym. El problema: hablar con desconocidos en un gimnasio le aterraba. Su solución fue tan honesta como predecible para alguien acostumbrado a depurar código: convertir el problema en un experimento social riguroso. Durante 30 días iniciaría una conversación diaria con un desconocido en el gym, registraría cada interacción y analizaría los resultados como si fueran datos de producción. El número final: 35 conversaciones documentadas, una historia que muchos developers en LATAM y el resto del mundo van a reconocer demasiado bien.
📑 En este artículo
- Cuando un developer trata su soledad como un bug
- El experimento: hipótesis, método y métricas
- Los datos crudos: 35 conversaciones, cuatro semanas
- Por qué los developers son propensos a la soledad post-universitaria
- Quantified self: la mentalidad detrás del experimento social
- Lo que cualquier dev puede aplicar mañana
- Qué sigue: replicar en LATAM y otros experimentos pendientes
- Preguntas frecuentes
- ¿Qué es quantified self y cómo se relaciona con este experimento social?
- ¿Funciona este método para introvertidos extremos?
- ¿Por qué un mes y no más tiempo?
- ¿Cómo aplicar este enfoque sin que se vuelva manipulación?
- ¿Qué herramientas usar para registrar las interacciones?
- ¿Tiene sentido repetir el experimento varias veces al año?
- Referencias
Cuando un developer trata su soledad como un bug
Antes del experimento, Tran reconoce en su propio post comportamientos que muchos lectores van a identificar al instante: dudar varios minutos antes de despertar a su roommate cuando sonó la alarma de incendios, fingir no conocer a un amigo de infancia que lo saludó porque no sabía cómo actuar con personas del pasado, ignorar a compañeros de una clase de diez personas porque no estaba seguro de que se acordaran de él. La fricción social acumulada de años de evitación había construido un sistema en el que iniciar cualquier conversación se sentía como interrumpir un servidor en producción.
La idea de tratar ese problema con la disciplina de la ingeniería no es ingenua. Es exactamente lo que un developer entrenado para identificar patrones, ejecutar pruebas y leer logs haría con cualquier otro fenómeno reproducible. La diferencia es que la mayoría de developers no aplica esas herramientas a su vida personal, en parte porque la cultura tech romantiza el aislamiento como condición creativa. El experimento social de Tran cuestiona esa premisa con datos.
El experimento: hipótesis, método y métricas
El método de Tran tiene la forma de un ensayo controlado más que de una pieza de autoayuda. Empezó con una hipótesis explícita —estoy solo y no tengo amigos— y un procedimiento reproducible: durante un mes, cada día, elegía a una sola persona, generalmente alguien que veía con frecuencia en el gym, y la abordaba con una opening line predefinida. La frase inicial fue durante la primera semana: Hey, te veo aquí seguido. Te ves fuerte, ¿cuál es tu split? Después de esa semana iteró: empezó a personalizar la apertura según un detalle que le interesara de cada persona. Si alguien usaba una gorra de Boston, le preguntaba si había estudiado allí. Si veía a alguien que parecía conocido, le preguntaba si trabajaba en el centro de la ciudad.
La meta era sostener cada interacción entre 5 y 10 minutos sin ser él quien cortara la conversación, porque sabía que tenía un sesgo previo a terminar charlas pronto. Cada conversación generaba cuatro variables: descripción de la persona, duración (corta 0-2 min, mediana 5-7 min, larga 10+ min), notas y aftermath. Este último campo es crítico, porque revela el verdadero objetivo: no acumular charlas, sino construir relaciones que sobrevivieran al experimento.
Visualmente, el flujo del experimento se parece a cualquier loop de feedback que un ingeniero diseñaría:
flowchart TD
A["Hipotesis: estoy solo"] --> B["Disenar experimento"]
B --> C["1 conversacion al dia"]
C --> D["Registrar datos"]
D --> E["Analizar duracion y aftermath"]
E --> F["Iterar opening line"]
F --> CEl bucle es simple, pero su valor está en la disciplina de no saltarse ninguna iteración. Tran sostiene en su post que la primera semana fue la más dura precisamente porque no había datos suficientes para refinar la apertura: estaba ejecutando el mismo script con resultados variables y resistiendo el impulso de abandonar.
Los datos crudos: 35 conversaciones, cuatro semanas
Los resultados, en formato bruto, ocupan un buen rato de scroll. La primera semana abordó a siete personas: un estudiante de medicina, un tipo grande con gorra café, un CS major buscando trabajo, un codificador médico, un nurse con gorra de Boston, un vecino del downtown y un mech eng con bigote. La distribución de duraciones es informativa por sí sola. Algunas conversaciones duraron menos de dos minutos —el mech eng respondió y se fue— y otras se extendieron diez o más; con el tipo grande con gorra café incluso le escribió primero por Instagram para extender la charla más allá del gym.
El campo aftermath es la métrica más reveladora. El tipo grande con gorra café siguió saludándolo cada semana y se volvió fuente de consejos sobre fitness. El vecino del downtown se transformó en alguien con quien sigue chateando aún ocupado. Otros simplemente desaparecieron del gym, respondieron sin engancharse o terminaron el saludo en pocas semanas. A lo largo del mes, Tran sostuvo el ritmo y completó 35 conversaciones en total. La cantidad de relaciones que sobrevivieron al experimento es relativamente baja en términos absolutos, pero la métrica que cambió drásticamente no fue el número de amigos: fue la incomodidad.
Empezar conversaciones dejó de sentirse como un evento extraordinario y pasó a ser un comportamiento por defecto. Para alguien que reconoce haber fingido no conocer a un amigo de infancia para evitar awkwardness, ese cambio de baseline es más profundo que cualquier amistad puntual.
Por qué los developers son propensos a la soledad post-universitaria
La historia de Tran resuena tanto porque la soledad post-universitaria es un problema epidémico entre developers, especialmente en LATAM donde muchos terminan trabajando remoto desde casa para empresas extranjeras. La estructura social que la universidad provee —clases compartidas, proyectos grupales, convivencia en residencias o espacios académicos— desaparece de golpe al graduarse. El reemplazo natural en la cultura corporativa, los compañeros de oficina, no aparece para quienes trabajan desde casa o en equipos distribuidos sin coincidencia geográfica. El resultado es un patrón conocido: agenda llena de standups, calendario sin almuerzos compartidos, semanas en las que el único contacto cara a cara es el del repartidor.
El libro Bowling Alone de Robert Putnam ya documentaba este declive del capital social desde los noventa, mucho antes de que el remote work se volviera default. Lo que el experimento social de Tran identifica es que la mecánica del aislamiento tiene un componente particular entre developers: cuando todo el día se trabaja con interfaces digitales, la fricción de iniciar una conversación cara a cara aumenta. Y cuando la fricción aumenta, el cerebro entrena al sistema para evitarla. Cada interacción que se evita refuerza el circuito de evasión.
💭 Clave: La soledad no es un problema social abstracto, es un patrón medible: número de interacciones por semana, duración promedio, frecuencia de seguimientos. Si lo podés medir, lo podés debuggear.
La única forma de revertir el circuito de evasión es exposición deliberada, exactamente lo que Tran hizo. La exposición no es agresión; es repetición controlada hasta que el sistema nervioso recalibra qué cuenta como amenaza y qué no. En términos de programación, es como ejecutar un test que falla durante semanas hasta que el código se acomoda al nuevo comportamiento.
Quantified self: la mentalidad detrás del experimento social
El concepto detrás del experimento social de Tran tiene nombre: quantified self. El término, acuñado en 2007 por dos editores de Wired, describe una práctica que ha crecido entre developers, científicos de datos y biohackers: aplicar métricas y registro sistemático a aspectos de la vida personal que tradicionalmente se manejan por intuición. Sueño, ejercicio, productividad, alimentación, estado de ánimo —todo medible si uno se compromete a registrarlo. La conexión con la mentalidad de programación es obvia: si no podés observar el sistema, no podés depurarlo.
El registro no necesita herramientas sofisticadas. Una estructura mínima en Python o cualquier lenguaje basta para sostener el experimento durante un mes:
from dataclasses import dataclass, field
from datetime import date
from typing import Literal
Length = Literal["short", "medium", "long"]
@dataclass
class Conversation:
day: date
description: str
length: Length
notes: str = ""
aftermath: str = ""
log: list[Conversation] = []
def add(description: str, length: Length, notes: str = "", aftermath: str = ""):
log.append(Conversation(date.today(), description, length, notes, aftermath))
add("chico con gorra de Boston", "medium", notes="siguio levantando mientras hablabamos")
Lo interesante del experimento social de Tran no es la herramienta —escribir un JSON con conversaciones del día es trivial— sino que aplicó la disciplina al dominio social, donde los developers solemos resistirnos a los datos. No es un problema técnico, no se puede medir es la excusa común. Tran demuestra que sí se puede. La métrica clave de su experimento no fue número de amigos sino frecuencia de comportamiento: cuántas veces inició una conversación. Esa es una métrica cuantitativa, sostenible y susceptible de feedback semanal.
Lo que cualquier dev puede aplicar mañana
Para developers que reconocen el patrón en sí mismos, el experimento social de Tran ofrece un marco concreto y aplicable. Primero, definir una hipótesis explícita sobre qué se quiere cambiar. Quiero más amigos es vago; quiero iniciar al menos una conversación nueva por día durante 30 días es accionable. Segundo, fijar un período de prueba acotado. Tran usó 30 días, ni demasiado corto para no ver señales, ni tan largo para que se vuelva carga indefinida. Tercero, registrar datos crudos sin censura. La tentación de embellecer los registros aparece rápido, sobre todo cuando las cosas no salen bien, pero los datos crudos son los que producen aprendizaje.
💡 Tip: Empezá tu propio experimento esta semana con una sola métrica. Contá cuántas veces iniciaste una conversación con alguien fuera de tu círculo. La métrica sola, sin objetivos agresivos, ya genera consciencia y aparece el patrón.
Cuarto, iterar el código del experimento. Tran cambió su opening line después de la primera semana, no por capricho sino porque vio que las charlas customizadas duraban más. Ese es el ciclo de feedback de cualquier sistema: medir, ajustar, medir de nuevo. Y quinto, publicar el resultado. Tran subió todo a su blog, datos crudos incluidos. Esa exposición pública añade un compromiso adicional y, en su caso, terminó generando que otros developers le escribieran contando experimentos parecidos. La transparencia, una vez más, funciona como mecanismo de accountability.
Qué sigue: replicar en LATAM y otros experimentos pendientes
El experimento social de Tran no resolvió la soledad post-universitaria como problema social ni pretendía hacerlo. Lo que hizo fue construir evidencia empírica de que el comportamiento puede modificarse con disciplina y datos. La pregunta que queda abierta para developers en LATAM es si replicar este tipo de experimento en contextos locales —gimnasios, comunidades de tech, eventos de meetup, cafés con coworking— produce resultados similares. La cultura social en buena parte de LATAM tiende a ser más cálida que la del norte de Estados Unidos, lo que podría reducir la fricción inicial pero también complicar el control del experimento, porque más gente tiende a engancharse en charlas largas espontáneamente.
Hay una segunda lectura interesante: si los developers podemos aplicar quantified self a la soledad, ¿qué otros problemas no técnicos estamos dejando sin tocar por miedo a parecer fríos al medir? El experimento de Tran sugiere que esa frialdad es solo aparente, y que la métrica bien aplicada genera mucho más calor humano que el esfuerzo intuitivo sostenido. Probablemente la próxima ola de experimentos sociales escritos por developers no va a venir de coaches ni de psicólogos, sino de gente que abrió un .json y registró durante un mes lo que normalmente se queda como ruido de fondo.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es quantified self y cómo se relaciona con este experimento social?
Quantified self es la práctica de registrar y medir aspectos de la vida personal con la misma disciplina que se mide un sistema técnico. El experimento de Tran es un caso aplicado: en vez de medir pasos o calorías, midió interacciones sociales, duración y seguimiento. La conexión con programación es directa: lo que no se observa no se puede mejorar.
¿Funciona este método para introvertidos extremos?
El propio Tran se describe como alguien aterrado por iniciar conversaciones, no como un extrovertido natural. El método funciona precisamente porque sustituye motivación por estructura: no requiere ganas, requiere seguir el procedimiento. Para introvertidos extremos puede ser útil empezar con una métrica más conservadora, por ejemplo una conversación cada dos días.
¿Por qué un mes y no más tiempo?
Treinta días es un balance pragmático: suficiente para que el patrón se consolide y aparezcan datos interesantes, lo bastante corto para sostener el compromiso sin agotamiento. Un experimento de seis meses se vuelve indefinido y la mente pierde la sensación de meta clara. Tran cerró el mes y luego decidió qué hábitos mantener.
¿Cómo aplicar este enfoque sin que se vuelva manipulación?
La diferencia entre experimento social y manipulación está en la honestidad de las interacciones. Tran no usaba opening lines fabricadas para extraer algo de la otra persona; las usaba para vencer su propia parálisis. Las conversaciones eran genuinas, los seguimientos también. La métrica era sobre su propio comportamiento, no sobre cómo cambiar el de otros.
¿Qué herramientas usar para registrar las interacciones?
Cualquier cosa que sostengas durante 30 días sirve. Un archivo JSON, una hoja de cálculo, una nota en el celular, un cuaderno. La regla es que el costo de registrar sea menor al de saltarse un día. Estructuras complejas con dashboards y gráficos suelen abandonarse en la primera semana; estructuras simples sobreviven el mes completo.
¿Tiene sentido repetir el experimento varias veces al año?
Sí, sobre todo si cambia el contexto: nueva ciudad, nuevo trabajo, nuevo gym, nueva comunidad. El sistema social cambia, las opening lines cambian, el aftermath cambia. Repetir el experimento al pasar a un entorno nuevo es la forma más eficiente de instalar baseline social en menos tiempo.
Referencias
- Thienan Tran — Talking to 35 Strangers at the Gym — Post original que documenta el experimento social, con datos crudos por semana.
- Wikipedia — Quantified Self — Definición y origen del movimiento de auto-medición que enmarca el experimento.
- Wikipedia — Bowling Alone — Trabajo seminal de Robert Putnam sobre el declive del capital social en EEUU desde los años setenta.
- Wikipedia ES — Soledad (estado emocional) — Marco general sobre la soledad como fenómeno emocional y sus correlaciones con aislamiento social.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios