Você está travado num problema há horas. Talvez seja um comportamento estranho de uma API, um teste que passa localmente e falha no CI, um trecho de código que deveria ser óbvio e não é. Você vai até a mesa de um colega e começa a explicar. No meio da sua segunda frase, você para. Achou o bug antes dele dizer uma palavra.
Agora pensa nas partes da sua vida que não são código. A frustração depois de um 1:1 ruim com o seu gestor. A sensação vaga de que você não está trabalhando nas coisas certas. O burnout que vem se aproximando e que você continua ignorando porque sempre tem outra sprint. Seu cérebro tem um memory leak com essas coisas, e você não está logando isso em lugar nenhum.
O journaling é o debugger pra isso.
Você já pensa como quem faz journaling
Não vou tentar te convencer de que o journaling é bom pra você. Você é desenvolvedor, é cético, e provavelmente já viu posts de "10 motivos pelos quais o journaling vai mudar a sua vida" o suficiente pra uma vida inteira.
Então deixa eu reformular. As habilidades que você usa todo dia já se mapeiam pro journaling:
Quebrar sistemas complexos. Quando um sistema é grande demais pra caber na cabeça, você decompõe. Isola componentes. Segue o fluxo. Escrever sobre uma semana confusa faz exatamente isso.
Documentar decisões. Bons times escrevem ADRs pra lembrar seis meses depois por que escolheram Postgres em vez de Mongo. O journaling é a versão pessoal disso. Por que você aceitou aquele trabalho? Por que você disse não pra aquele projeto? Você acha que vai lembrar. Não vai.
Post-mortems. Depois de um incidente, você não diz "bom, foi ruim" e segue em frente. Você escreve o que aconteceu, o que esperava, o que deu errado e o que vai mudar. Um artigo do Stack Overflow sobre diários de desenvolvedor descreve isso bem: você define o problema, registra as tentativas, acompanha a solução. Debugging assíncrono, basicamente.
Análise de causa raiz. Você não conserta sintomas. Você cava até achar a causa real. Esse instinto é raro fora da engenharia, e faz escrever sobre a sua vida ser muito mais útil do que "querido diário, hoje foi difícil".
Você não precisa aprender a fazer journaling. Você precisa perceber que já pensa assim.
Por que a maioria dos desenvolvedores desiste depois de uma semana
A maioria dos apps de journaling é feita pra um público de estilo de vida. Os prompts perguntam coisas como "Pelo que você é grato hoje?" ou "Escreva uma carta pra sua criança interior". A interface tem gradientes suaves e animações relaxantes. A experiência toda parece ter sido desenhada por alguém que tem um monte de velas aromáticas em casa.
Isso é ótimo pra algumas pessoas. Se você passa os dias num terminal ou numa IDE, parece uma UX ruim. A estrutura é vaga, os prompts são moles, e a pegada é tão de autoajuda que dá vontade de fechar o app e nunca mais abrir.
A solução é simples: escreva como você escreveria um post-mortem.
O que aconteceu hoje. O que eu esperava. O que encontrei no lugar. Onde ainda estou travado. Isso é uma entrada de diário. Leva cinco minutos. Não precisa de gratidão.
Uma abordagem de diário de trabalho diário sugere registrar tarefas, conversas, problemas resolvidos e prioridades do dia seguinte em 10-15 minutos no fim do dia. É esse o sistema inteiro.
Quatro coisas sobre as quais desenvolvedores escrevem bem
Eu faço o Pensio, que é um app de journaling. Também sou desenvolvedor. Então faço journaling sobre coisas de desenvolvedor, e notei algumas categorias onde escrever é desproporcionalmente útil se você pensa em sistemas.
1. Registros de decisões
Toda semana você toma decisões que parecem óbvias na hora e viram um mistério três meses depois. Por que escolhi essa biblioteca? Por que fui contra aquela feature request? Por que aceitei liderar aquele projeto quando eu já estava sobrecarregado?
Comecei a anotar essas coisas depois de passar uma tarde inteira rediscutindo com o meu time uma decisão técnica que eu já tinha pensado semanas antes. O raciocínio tinha sumido completamente da minha cabeça. Dois parágrafos teriam economizado a tarde toda.
2. Processar bloqueios
Você está travado. São 23h. Ninguém está no Slack. Você não consegue fazer rubber duck porque não tem pato. Então você abre um arquivo e começa a escrever: "Não entendo por que isso está acontecendo. Tentei X, Y e Z. X não funcionou porque..." e em algum ponto lá pela quarta frase, você vê. Ou não vê, mas agora tem um resumo claro pra colar numa mensagem na manhã seguinte.
Escrever quando você está travado organiza o que você realmente sabe versus o que você está supondo. Esse buraco costuma ser onde está o bug.
3. Preparar o 1:1
Antes do seu 1:1 com o gestor, você sabe o que de fato está te incomodando? Não a questão de superfície do "o pipeline de deploy está lento", mas a de verdade. Tipo, talvez você se sinta invisível no time, ou esteja preocupado com a reorganização, ou fique irritado por ser puxado de novo pra escala de suporte.
Escrever por cinco minutos antes de um 1:1 te ajuda a descobrir o que você quer dizer. Eu faço isso antes de qualquer reunião em que sei que pode ter emoção envolvida, e isso consistentemente evita que eu não diga nada ou diga algo de que vou me arrepender.
4. Descarga mental de fim de semana
Sexta à tarde. O que foi lançado essa semana? O que continua travado? O que eu evitei?
Essa última pergunta é a importante. As coisas que você evita dizem mais do que as que você conclui. Comecei a fazer isso quando estava construindo o Pensio e percebi que continuava evitando uma feature específica por semanas. Quando finalmente escrevi sobre o porquê, descobri que não estava travado no código. Eu estava com medo de que a feature não funcionasse bem o suficiente e de que os usuários ficassem decepcionados. Não era um bloqueio técnico. Era um bloqueio de medo. Só encontrei isso porque escrevi.
O journaling diário constrói um modelo mental do que você está fazendo, o que reduz o esquecimento que acontece quando você está espalhado por várias áreas de projeto ao mesmo tempo.
A parada do Obsidian
Muitos desenvolvedores já escrevem no Obsidian, e se esse é o seu caso, não tem motivo pra mudar. O Pensio tem um plugin do Obsidian que sincroniza as suas entradas e adiciona análise de emoções e detecção de padrões em cima do que você já escreveu. Você mantém o seu fluxo de trabalho e ganha a camada de inteligência.
Seu cérebro é um cache ruim
O motivo pelo qual o journaling funciona pra desenvolvedores não é que ele te deixa mais consciente ou centrado. É que o seu cérebro é um cache péssimo pra qualquer coisa que não seja o problema que você está resolvendo agora. Emoções, decisões, frustrações, padrões, tudo isso vai pro garbage collector rápido demais.
Escrever é a única coisa que faz flush da memória de trabalho pro armazenamento persistente. Manter um diário de desenvolvedor também constrói confiança ao documentar o seu progresso ao longo do tempo, porque senão você só foca no que está quebrado agora e esquece tudo o que já consertou.
Você não precisa de um sistema sofisticado. Abre um arquivo markdown. Escreve o que aconteceu, o que você esperava, o que você encontrou. Faz isso por uma semana e vê se o seu cérebro se sente diferente.
Se você escreve no Obsidian, o plugin do Pensio adiciona a camada de inteligência sem mudar o seu fluxo de trabalho. Grátis em pensio.app.
