Llevas horas atascado en un problema. Quizás es un comportamiento raro de una API, un test que pasa en local y falla en CI, un pedazo de código que debería ser obvio y no lo es. Caminas hasta el escritorio de un colega y empiezas a explicárselo. A la mitad de tu segunda frase, te detienes. Encontraste el bug antes de que dijera una palabra.
Ahora piensa en las partes de tu vida que no son código. La frustración después de un mal 1:1 con tu manager. La sensación vaga de que no estás trabajando en lo correcto. El burnout que se va acercando y que sigues ignorando porque siempre hay otro sprint. Tu cerebro tiene un memory leak con estas cosas, y no las estás logueando en ningún lado.
El journaling es el debugger para eso.
Ya piensas como alguien que hace journaling
No voy a intentar convencerte de que el journaling es bueno para ti. Eres desarrollador, eres escéptico, y probablemente ya viste suficientes posts de "10 razones por las que el journaling cambiará tu vida" como para toda una vida.
Así que déjame reformularlo. Las habilidades que usas todos los días ya se mapean al journaling:
Descomponer sistemas complejos. Cuando un sistema es demasiado grande para tenerlo entero en la cabeza, lo descompones. Aíslas componentes. Sigues el flujo. Escribir sobre una semana confusa hace exactamente eso.
Documentar decisiones. Los buenos equipos escriben ADRs para acordarse seis meses después por qué eligieron Postgres en vez de Mongo. El journaling es la versión personal de eso. ¿Por qué aceptaste ese trabajo? ¿Por qué le dijiste que no a ese proyecto? Crees que te vas a acordar. No te vas a acordar.
Post-mortems. Después de un incidente, no dices "bueno, eso estuvo mal" y sigues. Escribes qué pasó, qué esperabas, qué salió mal y qué vas a cambiar. Un artículo de Stack Overflow sobre los diarios de desarrollador lo describe bien: defines el problema, registras los intentos, sigues la solución. Debugging asíncrono, básicamente.
Análisis de causa raíz. No arreglas síntomas. Escarbas hasta encontrar la causa real. Ese instinto es raro fuera de la ingeniería, y hace que escribir sobre tu vida sea mucho más útil que "querido diario, hoy fue difícil".
No necesitas aprender a hacer journaling. Necesitas darte cuenta de que ya piensas así.
Por qué la mayoría de los desarrolladores lo dejan después de una semana
La mayoría de las apps de journaling están diseñadas para un público de estilo de vida. Los prompts preguntan cosas como "¿Por qué estás agradecido hoy?" o "Escríbele una carta a tu niño interior". La interfaz tiene degradados suaves y animaciones relajantes. Toda la experiencia se siente como si la hubiera diseñado alguien que tiene muchas velas aromáticas en su casa.
Eso está bien para algunas personas. Si pasas tus días en una terminal o en un IDE, se siente como mala UX. La estructura es vaga, los prompts son blandos, y el enfoque es tan de autoayuda que te dan ganas de cerrar la app y no volver a abrirla nunca.
La solución es simple: escribe como escribirías un post-mortem.
Qué pasó hoy. Qué esperaba. Qué encontré en su lugar. Dónde sigo atascado. Eso es una entrada de diario. Toma cinco minutos. No hace falta gratitud.
Un enfoque de diario de trabajo diario propone anotar tareas, conversaciones, problemas resueltos y prioridades para el día siguiente, en 10-15 minutos al final del día. Ese es todo el sistema.
Cuatro cosas sobre las que los desarrolladores escriben bien
Hago Pensio, que es una app de journaling. También soy desarrollador. Así que hago journaling sobre cosas de desarrollador, y noté algunas categorías donde escribir es desproporcionadamente útil si piensas en sistemas.
1. Registros de decisiones
Todas las semanas tomas decisiones que se sienten obvias en el momento y se vuelven un misterio tres meses después. ¿Por qué elegí esta librería? ¿Por qué me opuse a esa feature request? ¿Por qué acepté liderar ese proyecto cuando ya estaba saturado?
Empecé a anotar estas cosas después de pasar una tarde entera volviendo a discutir con mi equipo una decisión técnica que ya había pensado semanas antes. El razonamiento había desaparecido por completo de mi cabeza. Dos párrafos nos habrían ahorrado toda la tarde.
2. Procesar bloqueos
Estás atascado. Son las 11 de la noche. Nadie está en Slack. No puedes hacer rubber duck porque no hay pato. Así que abres un archivo y empiezas a escribir: "No entiendo por qué está pasando esto. Probé X, Y y Z. X no funcionó porque..." y en algún punto alrededor de la cuarta frase, lo ves. O no lo ves, pero ahora tienes un resumen claro para pegar en un mensaje a la mañana siguiente.
Escribir cuando estás atascado organiza lo que realmente sabes frente a lo que estás asumiendo. Ese hueco es normalmente donde está el bug.
3. Preparar el 1:1
Antes de tu 1:1 con tu manager, ¿sabes qué es lo que de verdad te está molestando? No el tema de superficie de "el pipeline de deploy está lento", sino lo de verdad. Como que quizás te sientes invisible en el equipo, o te preocupa la reorganización, o te molesta que te vuelvan a meter en la rotación de soporte otra vez.
Escribir durante cinco minutos antes de un 1:1 te ayuda a descubrir qué quieres decir. Yo hago esto antes de cualquier reunión donde sé que puede haber emociones de por medio, y consistentemente evita que no diga nada o que diga algo de lo que me arrepienta.
4. Volcado mental de fin de semana
Viernes por la tarde. ¿Qué se lanzó esta semana? ¿Qué sigue atascado? ¿Qué evité?
Esa última pregunta es la importante. Las cosas que evitas te dicen más que las que completas. Empecé a hacer esto cuando estaba construyendo Pensio y noté que seguía evitando una feature específica durante semanas. Cuando por fin escribí sobre por qué, descubrí que no estaba atascado en el código. Tenía miedo de que la feature no funcionara lo suficientemente bien y de que los usuarios se decepcionaran. No era un bloqueo técnico. Era un bloqueo de miedo. Solo lo encontré porque lo escribí.
El journaling diario construye un modelo mental de lo que estás haciendo, lo que reduce el olvido que ocurre cuando estás repartido entre varias áreas de proyecto al mismo tiempo.
El asunto de Obsidian
Muchos desarrolladores ya escriben en Obsidian, y si ese eres tú, no hay razón para cambiar. Pensio tiene un plugin de Obsidian que sincroniza tus entradas y le suma análisis de emociones y detección de patrones encima de lo que ya escribiste. Conservas tu flujo de trabajo y obtienes la capa de inteligencia.
Tu cerebro es un mal cache
La razón por la que el journaling funciona para los desarrolladores no es que te haga más consciente o centrado. Es que tu cerebro es un cache pésimo para cualquier cosa que no sea el problema que estás resolviendo ahora mismo. Las emociones, las decisiones, las frustraciones, los patrones, a todo se lo lleva el garbage collector demasiado rápido.
Escribir es lo único que hace flush de la memoria de trabajo hacia almacenamiento persistente. Llevar un diario de desarrollador también construye confianza al documentar tu progreso con el tiempo, porque de lo contrario solo te enfocas en lo que está roto ahora mismo y te olvidas de todo lo que ya arreglaste.
No necesitas un sistema sofisticado. Abre un archivo markdown. Escribe qué pasó, qué esperabas, qué encontraste. Hazlo durante una semana y fíjate si tu cerebro se siente distinto.
Si escribes en Obsidian, el plugin de Pensio le suma la capa de inteligencia sin cambiar tu flujo de trabajo. Gratis en pensio.app.
