Como virei blogueira sem querer (e por que você deveria fazer o mesmo)

Eu não acordei um dia pensando "vou virar tech writer". Na verdade, comecei escrevendo para mim mesma — anotações de bugs que resolvi, comandos que sempre esqueço, aquele padrão React que usei três vezes e na quarta vez já não lembrava mais.

Três meses depois, essas anotações viraram artigos. Seis meses depois, recrutadores começaram a me achar pelo que eu escrevi, não pelo currículo. Um ano depois, eu tinha construído uma reputação que nenhum bootcamp ou certificado me daria.

Se você programa, você já tem metade do trabalho pronto. Vou te mostrar como a outra metade acontece sozinha.

O truque está na ferramenta errada

A maioria dos devs que tentam blogar começam abrindo o Medium ou o dev.to e encarando a página em branco. Erro. Você não começa a escrever para internet — você começa escrevendo enquanto trabalha.

Eu uso um repo privado no GitLab chamado dev-notes. Estrutura básica:

dev-notes/
├── bugs/
│   ├── 2026-09-react-effect-loop.md
│   └── 2026-10-postgres-deadlock.md
├── snippets/
│   ├── debounce-hook.js
│   └── redis-rate-limit.js
└── til/ # Today I Learned
    ├── 2026-09-28-optional-chaining.md
    └── 2026-10-02-css-has-selector.md

Cada arquivo é markdown puro. Quando resolvo um bug irritante, abro bugs/YYYY-MM-problema.md e escrevo:

## Problema
useEffect rodando em loop infinito mesmo com array de dependências

## Causa
O objeto `config` estava sendo recriado a cada render:
const config = { theme: userTheme } // novo objeto toda vez

## Solução

js
const config = useMemo(
() => ({ theme: userTheme }),
[userTheme]
)

## Por que funcionou
Identidade referencial. Arrays/objetos literais sempre falham `===`.

markdown

Pronto. Levou 2 minutos. Não é um artigo — é documentação funcional do meu dia.

De nota privada para post público

Dois meses depois, topo com o mesmo loop em outro projeto. Abro minhas notas, acho a solução em 10 segundos. Economia de 40 minutos de debug.

Aí vem o pulo: se salvou seu tempo duas vezes, vai salvar o tempo de outra pessoa. Esse é o momento de publicar.

Pego aquele markdown, adiciono contexto (por que alguém bateria nesse problema?) e exemplos (como reproduzir?). Vira isso:

# useEffect em loop: o problema da identidade de objetos

Você já viu seu componente React renderizar infinitamente mesmo
com `useEffect` tendo dependências declaradas? O culpado costuma
ser um objeto ou array recriado a cada render.

## Reproduzindo o bug

js
function Dashboard() {
const [data, setData] = useState(null)

const config = { theme: 'dark' } // ← problema aqui

useEffect(() => {
fetchData(config).then(setData)
}, [config]) // loop infinito

return

{data?.title}
}

A cada render, `config` é um objeto *novo* (referência diferente),
então `[config]` nunca é igual ao array anterior. React dispara
o effect de novo, que causa render, que recria `config`...

## A solução: useMemo para identidade estável

js
const config = useMemo(
() => ({ theme: 'dark' }),
[] // só cria uma vez
)

Agora `config` mantém a mesma referência entre renders, e o loop para.

## Quando NÃO usar

Se `theme` vem de props/state, declare como dependência:

js
const config = useMemo(
() => ({ theme: userTheme }),
[userTheme] // recria só quando theme muda
)

## TL;DR
- Objetos literais em dependências do useEffect causam loops
- Use `useMemo` para manter identidade referencial
- Liste as dependências reais do objeto no array do `useMemo`

Esse artigo levou 15 minutos. Não porque escrevi rápido — porque a parte difícil (entender o problema e testar a solução) já estava feita quando eu resolvi o bug pela primeira vez.

O sistema que funciona sem esforço

Meu fluxo hoje:

1. Trabalho normal: resolvo bugs, implemento features, topo com comportamento inesperado
2. Anoto: 2 minutos no dev-notes, formato problema-causa-solução
3. Reviso semanal: abro o repo, vejo o que anotei nos últimos 7 dias
4. Publico o útil: se usei a nota duas vezes, expando para artigo e posto no dev.to

Zero planejamento de conteúdo. Zero bloqueio criativo. Escrevo sobre o que já fiz, não sobre o que vou fazer.

Os efeitos colaterais (bons)

Três coisas que não esperava:

Entrevistas técnicas ficaram fáceis. Quando você documenta problemas reais que resolveu, não precisa inventar resposta na hora. "Me fala de um bug difícil" → abro mental o índice de bugs/ e escolho um caso.

Recrutadores te acham. Dois dos últimos três trabalhos que recebi vieram de gente que leu algo que escrevi. Não porque o artigo era genial — porque provava que eu faço o que digo que sei.

Você aprende melhor. Forçar seu cérebro a explicar em texto expõe buracos no entendimento. Se não consigo escrever "por que X funciona", é porque não entendi X direito.

Caveats reais

Escrever demais logo no início. Eu comecei querendo postar 3x por semana, queimei em um mês. O sistema que funciona é postar quando tem o que dizer, não por cota.

Achar que precisa ser original. 90% dos meus posts são sobre problemas comuns. Não importa — sua explicação, seu exemplo, seu contexto são únicos. Alguém vai bater no seu artigo e entender do seu jeito.

Não linkar código real. Snippets inventados na hora costumam ter bugs. Eu sempre copio de código que roda, mesmo que simplifique depois. Se o exemplo não compila, perde credibilidade.

TL;DR

• Comece com notas privadas, não com blog público
• Use um repo git simples: markdown + estrutura por tipo (bugs, TIL, snippets)
• Publique só o que você reutilizou pelo menos duas vezes
• Formato problema-causa-solução é suficiente — não precisa de narrativa elaborada
• Recrutadores e entrevistas ficam mais fáceis quando você tem portfólio escrito
• Qualidade > frequência: poste quando tiver algo real, não por cota semanal