anotações de trabalho para dev junior: o caderno que evita repetir erro

Dev junior costuma ouvir “anota tudo” na primeira semana. Parece conselho óbvio, quase maternal. Só que pouca gente explica o que anotar, onde guardar, como revisar e como transformar nota em trabalho melhor.

O resultado é previsível: você abre um documento gigante chamado notas.md, joga links, comandos, prints, frases soltas da daily, erro de terminal, lembrete de estudar Docker, dica do tech lead e pauta de 1:1 tudo no mesmo lugar. Duas semanas depois, o arquivo existe, mas não ajuda. Você não encontra nada. Pergunta de novo. Repete erro. Fica com vergonha de parecer desorganizado.

Anotação boa não é diário bonito. Também não é documentação oficial da empresa. É ferramenta de trabalho. Ela serve para reduzir dependência, melhorar pergunta, registrar decisão, lembrar feedback e mostrar evolução quando alguém perguntar “como foi seu mês?”.

Este guia é para montar um caderno de trabalho simples para estágio, primeira vaga tech, suporte técnico, QA, dados, produto ou desenvolvimento. Pode ser Notion, Obsidian, Google Docs, Markdown no computador, bloco de notas ou caderno físico. A ferramenta importa menos do que o sistema.

Se você acabou de entrar, leia também o roteiro de primeira semana como dev junior e o plano de primeiros 30 dias como dev junior. Eles mostram o momento. Este texto mostra o mecanismo para não perder contexto no caminho.

anote para trabalhar, não para colecionar informação

O erro mais comum é tratar anotação como depósito. Tudo entra. Nada sai.

Anotação útil precisa responder a uma pergunta prática:

• como rodo esse projeto sem pedir ajuda de novo?
• qual foi a decisão sobre essa regra de negócio?
• o que eu tentei antes de chamar alguém?
• qual feedback apareceu mais de uma vez?
• o que preciso levar para a próxima 1:1?
• que evidência mostra que eu evoluí?

Se a nota não ajuda nenhuma dessas perguntas, talvez ela nem precise existir.

Pense no caderno como um mapa operacional. Ele não precisa guardar a internet inteira. Precisa guardar o caminho que você já percorreu dentro daquele trabalho.

a estrutura mínima do caderno

Comece com cinco arquivos ou seções. Não invente sistema enorme.

00-inbox.md
01-setup-e-acessos.md
02-tarefas.md
03-duvidas-e-decisoes.md
04-feedback-e-1on1.md

O 00-inbox.md é temporário. É onde você joga uma informação no meio da reunião sem tentar organizar na hora. No fim do dia, você limpa.

O 01-setup-e-acessos.md guarda comandos, versões, links de ambiente, VPN, variáveis e problemas resolvidos. Ele evita a pergunta repetida.

O 02-tarefas.md registra o que você está fazendo, qual é o objetivo, onde travou e qual foi o próximo passo.

O 03-duvidas-e-decisoes.md guarda dúvidas respondidas e decisões que mudam comportamento. É onde entra “não usar endpoint X nesse fluxo” ou “produto prefere mensagem A por causa de suporte”.

O 04-feedback-e-1on1.md guarda feedback, pautas de conversa, combinados e evidências de evolução.

Isso basta para começar. Se o sistema crescer, você separa depois. No começo, simplicidade ganha.

setup: transforme erro em receita

Setup local é uma das maiores fontes de vergonha para dev junior. A pessoa vê o README, roda comando, quebra, tenta mais três coisas, não anota nada e pede ajuda com “não funcionou aqui”.

Troque isso por uma receita viva.

Modelo:

Projeto: api-principal
Data: 2026-05-25

Ambiente:
- Ubuntu 24.04
- Node 22.3
- Docker 26
- Postgres via docker compose

Passos que funcionaram:
1. cp .env.example .env
2. pedir variável STRIPE_WEBHOOK_SECRET no canal #dev-infra
3. docker compose up -d db redis
4. npm install
5. npm run migrate
6. npm run dev

Erro que apareceu:
- migration falhou com "permission denied for schema public"

Correção:
- recriar volume local depois da role ser ajustada
- comando: docker compose down -v && docker compose up -d db

Observação:
- não rodar seed em produção; seed é só local/staging

Perceba que isso não é documentação oficial. É seu histórico de sobrevivência. Da próxima vez, você resolve mais rápido. Se outro junior entrar, talvez sua nota vire base para melhorar o README do time.

Se o seu foco é backend, automação ou scripts, esse hábito também ajuda nos projetos de portfólio. Um projeto Python pequeno, por exemplo, fica muito mais forte quando o README explica instalação, entrada, saída e erro comum; os guias práticos de Python Brasil podem servir como referência de estudo, mas o valor aparece quando você documenta o que realmente rodou.

tarefa: escreva antes de codar

Antes de começar uma tarefa, registre três coisas:

Tarefa: corrigir validação de CPF no cadastro

Objetivo:
- impedir cadastro com CPF inválido antes de chamar o serviço externo

Minha leitura:
- validação hoje acontece só no backend
- frontend mostra erro genérico
- preciso ajustar mensagem e teste de backend

Dúvidas:
- CPF vazio deve mostrar mesma mensagem de CPF inválido?
- existe regra diferente para cadastro via convite?

Plano pequeno:
1. localizar validação atual
2. reproduzir erro local
3. escrever teste do caso inválido
4. ajustar mensagem
5. abrir PR pequeno

Isso parece lento, mas economiza tempo. Junior se perde quando começa pelo código antes de entender a regra. Cinco minutos de nota evitam duas horas mexendo no arquivo errado.

Essa prática também melhora pergunta. Em vez de mandar “não entendi a task”, você manda:

Minha leitura é que preciso validar CPF antes de chamar o serviço externo.
Encontrei validação no backend, mas o frontend mostra erro genérico.
A dúvida é: CPF vazio e CPF inválido usam a mesma mensagem?

Essa pergunta dá contexto. Pessoa senior consegue responder rápido.

dúvida respondida vira decisão registrada

Muita dúvida de junior volta porque a resposta fica perdida no Slack.

Exemplo:

Dúvida: posso usar endpoint /internal/customers no fluxo público?
Resposta do Pedro em 2026-05-25:
- não
- esse endpoint depende de permissão interna
- para tela pública, usar /api/customers/search

Impacto:
- atualizar plano da tarefa #432
- evitar sugerir /internal em PR futuro

Isso é ouro. Não pela formalidade, mas porque evita repetir a mesma decisão no próximo PR.

Quando uma resposta muda seu comportamento, registre. Quando é só curiosidade solta, talvez não precise.

daily: use nota para não falar no automático

Daily ruim nasce de memória fraca:

Ontem mexi naquela task. Hoje vou continuar. Sem bloqueio.

Se você mantém nota de tarefa, daily melhora naturalmente:

Ontem reproduzi o erro de CPF inválido, encontrei a validação no backend e adicionei o primeiro teste.
Hoje vou ajustar a mensagem no frontend e abrir PR pequeno.
Bloqueio: preciso confirmar se CPF vazio usa a mesma mensagem de CPF inválido.

Não é discurso maior. É discurso mais útil.

O guia de daily como dev junior aprofunda esse formato. A anotação é o combustível dele.

PR e review: guarde padrões, não feridas

Code review mexe com ego. Junior lê comentário e sente que o revisor está avaliando sua inteligência. Se você não registra direito, fica só a emoção: “meu PR voltou cheio de comentário”.

Registre padrão técnico:

Review do PR #128

Comentários recebidos:
- faltou teste de erro, não só caso feliz
- nome da função estava genérico
- descrição do PR não explicou impacto para suporte

Padrão para próxima vez:
- antes de abrir PR, checar teste de erro
- trocar nomes genéricos como handleData
- incluir seção "como testar" na descrição

Isso transforma review em checklist. O guia de code review como dev junior mostra como responder comentário sem travar; seu caderno mostra como não repetir o mesmo tipo de ajuste.

Não use a nota para escrever desabafo sobre o revisor. Se precisar desabafar, faça em outro lugar. Caderno de trabalho precisa te deixar melhor, não mais ressentido.

1:1: chegue com evidência pequena

1:1 de junior não deve virar terapia improvisada nem interrogatório. A melhor pauta é curta e baseada em exemplo.

Modelo:

1:1 - 2026-05-25

O que entreguei:
- PR #128 corrigindo validação de CPF
- melhoria no README de setup local

Onde travei:
- demorei para entender diferença entre endpoint público e interno

Feedback que quero:
- minha descrição de PR está clara o suficiente?
- estou avisando bloqueio cedo ou tarde?

Combinado:
- no próximo PR, incluir seção "risco e como testar"

Isso facilita a vida do gestor. Você não chega pedindo uma avaliação abstrata da sua carreira. Chega com material concreto.

Se a empresa usa PDI, essas notas viram evidência. O guia de PDI para dev junior explica como transformar feedback em meta pequena; o caderno mostra o antes e depois.

revisão semanal de 20 minutos

Sem revisão, caderno vira gaveta.

Reserve 20 minutos na sexta ou segunda. Não precisa ritual complexo.

Pergunte:

• que nota da inbox precisa ir para uma seção definitiva?
• que erro eu repeti esta semana?
• que decisão preciso lembrar na próxima tarefa?
• que feedback apareceu mais de uma vez?
• que evidência posso levar para 1:1?
• que link, comando ou contexto já ficou obsoleto?

Apague coisa inútil. Mova coisa importante. Resuma o que ficou longo demais.

Uma boa revisão semanal termina com algo assim:

Resumo da semana
- consegui rodar api-principal localmente sem ajuda
- abri PR #128 com teste de erro depois do review
- ainda demoro para pedir contexto de produto
- próxima semana: validar regra antes de codar

Isso parece simples porque é. O efeito aparece em meses.

cuidado com informação sensível

Anotar bem não significa copiar segredo da empresa.

Não coloque no seu caderno pessoal:

• senha;
• token;
• chave de API;
• dado de cliente;
• print de produção com informação real;
• link privado que você pretende reutilizar fora da empresa;
• código proprietário em repositório pessoal.

Se precisa lembrar de um segredo, anote onde ele fica, não o valor:

STRIPE_WEBHOOK_SECRET: pedir acesso no cofre 1Password do time, pasta pagamentos.

Isso protege você e a empresa.

Também não transforme anotação de trabalho em post público sem limpar contexto. O que é aprendizado seu pode virar portfólio depois, mas precisa ser generalizado: “aprendi a documentar setup local” é ok; “o banco do cliente X quebra por causa da tabela Y” não é.

quando a anotação está funcionando

Você sabe que o caderno está funcionando quando:

• pergunta menos coisa repetida;
• faz pergunta com mais contexto;
• escreve daily mais clara;
• abre PR com descrição melhor;
• lembra feedback sem depender da memória;
• chega na 1:1 com exemplo;
• consegue explicar sua evolução nos últimos 30 dias;
• melhora README, runbook ou documentação do time a partir de dor real.

O objetivo não é virar a pessoa mais organizada da empresa. É reduzir ruído. Junior que reduz ruído ganha confiança rápido, porque o time percebe que cada ajuda dada vira aprendizado acumulado.

um modelo para copiar hoje

Se quiser começar agora, copie isto:

Hoje
- tarefa principal:
- objetivo:
- próxima ação:
- bloqueio:
- pessoa/canal para pedir ajuda:

Aprendi
- comando/link/regra:
- decisão importante:

Para revisar
- feedback recebido:
- erro a não repetir:
- pergunta para 1:1:

Preencha por cinco dias. Depois ajuste.

Não espere ferramenta perfeita. Não espere template perfeito. Comece pequeno, revise toda semana e deixe o caderno trabalhar para você.

No primeiro emprego tech, muita coisa ainda vai ser confusa: arquitetura, produto, processo, sigla, cultura, deploy, review, prioridade. Você não controla tudo isso. Mas controla uma parte importante: transformar cada confusão em registro útil para a próxima vez.

É assim que dev junior deixa de parecer perdido sem precisar fingir que já sabe tudo.