primeiro bug em produção como dev junior: o que fazer sem entrar em pânico

O primeiro bug em produção como dev junior parece maior do que realmente é. A tela quebra, o alerta aparece, alguém marca você no Slack, o cliente reclama, o gestor pergunta “o que aconteceu?” e sua cabeça traduz tudo para: “acabou minha carreira”.

Não acabou.

Bug em produção acontece com junior, pleno, sênior, staff, tech lead e empresa bilionária. O que muda não é a existência do bug. O que muda é o comportamento depois que ele aparece.

Para dev junior, o primeiro bug em produção é menos uma prova de genialidade técnica e mais uma prova de maturidade operacional: você avisa cedo, não esconde, não inventa certeza, reproduz com calma, registra impacto, pede ajuda com contexto e aprende o suficiente para não repetir o mesmo erro do mesmo jeito.

Se você ainda está nos primeiros dias de empresa, leia também o guia de primeira semana como dev junior e o roteiro de primeiros 30 dias como dev junior. Este texto começa quando você já abriu PR, recebeu review e descobriu que código real às vezes quebra em lugar real.

primeiro: pare de tentar resolver em silêncio

O erro mais perigoso do junior não é ter causado um bug. É perceber o problema e ficar quieto tentando consertar sozinho para ninguém notar.

Essa estratégia quase sempre piora tudo.

Quando algo quebra em produção, o time precisa de visibilidade. Talvez o bug afete só uma tela interna. Talvez afete pagamento. Talvez afete só um usuário. Talvez afete cem. Você, sozinho e nervoso, provavelmente ainda não sabe. Então a primeira atitude correta é avisar.

Uma mensagem boa não precisa ser dramática:

Pessoal, percebi um possível problema depois do PR #123.

Sintoma: usuários não conseguem salvar o formulário X.
Impacto conhecido até agora: reproduzi em staging e apareceu em 2 relatos do suporte.
O que já fiz: revert local confirma que o erro some.
Próximo passo: estou isolando a mudança e preciso de alguém para validar se rollback é o melhor caminho.

Repare no formato: sintoma, impacto, evidência, próximo passo. Não tem desespero. Não tem “acho que destruí tudo”. Não tem tentativa de parecer mais certo do que você está.

Se você ainda não sabe se foi seu PR, diga isso:

Vi um erro que pode estar relacionado ao PR #123, mas ainda não confirmei. Estou reproduzindo agora e aviso em 10 minutos com o que encontrei.

Isso é melhor do que sumir por uma hora.

separe culpa de responsabilidade

Junior costuma confundir duas coisas: culpa e responsabilidade.

Culpa é a fantasia de que uma pessoa sozinha estragou tudo porque é incompetente. Responsabilidade é reconhecer que sua mudança pode ter contribuído para um problema e agir para reduzir dano.

Você não controla tudo:

• o processo de review pode ter falhado;
• o teste automatizado pode não cobrir aquele caso;
• a documentação pode estar incompleta;
• o ambiente local pode ser diferente de produção;
• a tarefa pode ter vindo com requisito ambíguo;
• o deploy pode juntar mudanças de várias pessoas.

Mas você controla seu comportamento depois que percebe o erro.

Uma frase madura é:

Minha mudança parece ter exposto esse problema. Ainda estou confirmando a causa, mas vou tratar como prioridade e manter vocês atualizados.

Isso assume responsabilidade sem teatrinho de autopunição. Time bom não precisa que você se humilhe. Precisa que você ajude a resolver.

reproduza antes de chutar causa

No susto, dá vontade de explicar rápido: “foi cache”, “foi o deploy”, “foi a API”, “foi dado antigo”, “foi o front”. Cuidado. Explicação sem reprodução vira chute com confiança.

O primeiro trabalho técnico é transformar relato em caso reproduzível.

Monte um bloco simples:

Bug: botão Salvar não conclui cadastro

Ambiente:
- produção: sim
- staging: sim/não
- local: sim/não

Passos:
1. login com usuário tipo X
2. abrir tela Y
3. preencher campo Z com valor W
4. clicar em Salvar

Resultado atual:
- aparece erro 500

Resultado esperado:
- cadastro salvo e usuário redirecionado para tela de confirmação

Evidência:
- print
- log
- request id
- horário aproximado

Esse registro reduz ruído. Em vez de jogar “tá quebrado” no canal, você entrega um mapa que outra pessoa consegue seguir.

Se você não consegue reproduzir, também diga:

Ainda não consegui reproduzir. Tenho dois relatos com horário e usuário, mas no meu teste local passou. Vou procurar logs pelo request id e peço ajuda se não achar em 15 minutos.

Isso mostra método. Junior não precisa ter resposta imediata. Precisa ter próximo passo claro.

entenda o impacto antes de mexer mais

Nem todo bug em produção pede a mesma reação.

Um erro visual em uma tela pouco acessada não tem a mesma urgência que cobrança duplicada, vazamento de dado, login quebrado ou fila parada. Antes de sair codando correção, descubra o tamanho do incêndio.

Pergunte ou investigue:

• quantos usuários foram afetados?
• o problema impede compra, login, cadastro, pagamento ou uso principal?
• existe workaround seguro?
• começou depois de qual deploy?
• afeta todo mundo ou um tipo específico de conta?
• há risco de dado incorreto, perda de informação ou exposição indevida?

Se encostar em pagamento, dado sensível, segurança, produção crítica ou contrato com cliente, pare de tentar ser herói. Chame alguém mais sênior imediatamente.

Mensagem possível:

Esse bug parece afetar fluxo de pagamento. Não vou mexer sozinho. Consegui reproduzir com estes passos e tenho o horário do primeiro erro. Quem pode assumir comigo a decisão de rollback ou hotfix?

Isso não diminui você. Pelo contrário: mostra que você sabe diferenciar bug comum de risco operacional.

rollback não é vergonha

Muita gente no primeiro emprego acha que reverter PR é fracasso. Não é. Rollback é ferramenta de proteção.

Se sua mudança causou problema relevante, a pergunta não é “como salvo meu orgulho?”. A pergunta é:

Qual caminho devolve estabilidade mais rápido e com menos risco?

Às vezes é hotfix. Às vezes é feature flag. Às vezes é desativar uma integração. Às vezes é rollback completo.

Como junior, você provavelmente não decide isso sozinho. Mas pode ajudar muito chegando com informação:

• PR suspeito;
• arquivos alterados;
• horário do deploy;
• passos de reprodução;
• logs ou prints;
• teste local mostrando que revert resolve;
• riscos conhecidos do rollback.

Uma boa forma de falar:

Testei localmente revertendo o commit X e o erro parou de acontecer no caso reproduzido. Não sei se há efeito colateral do rollback. Você prefere que eu abra PR de revert para revisão ou seguimos por outro caminho?

Você não está mandando no incidente. Está oferecendo uma hipótese útil.

peça ajuda com contexto, não com pânico

Pedir ajuda é esperado. O problema é pedir ajuda de um jeito que transfere todo o trabalho mental para outra pessoa.

Compare:

Ruim:

Deu erro aqui, consegue ver?

Melhor:

Estou investigando o erro 500 no cadastro depois do PR #123. Já reproduzi em staging com usuário do tipo escola, mas não com usuário admin. O log aponta nil pointer em CreateProfile. Minha hipótese é que o campo phone vem vazio em contas antigas. Você consegue validar se essa hipótese faz sentido antes de eu mexer na validação?

A segunda mensagem dá ao sênior um ponto de entrada. Ele não precisa descobrir tudo do zero. Ele consegue responder, corrigir direção ou assumir a investigação se o risco for alto.

Essa habilidade também melhora sua carreira antes de entrar na empresa. Em projetos pessoais e entrevistas, saber explicar bug, hipótese e tentativa vale muito. Se você está montando portfólio, o guia de GitHub para junior e o texto sobre portfólio com 3 projetos ajudam a mostrar esse tipo de maturidade sem inventar experiência fake.

durante a correção: reduza escopo

Bug em produção não é hora de refatorar o mundo.

Se você encontrou um nome ruim, uma função duplicada, um teste faltando e uma arquitetura estranha, anote. Não misture tudo no hotfix.

O PR de correção deve ser pequeno:

• corrige o caso quebrado;
• adiciona ou ajusta teste relevante, se o time tiver estrutura;
• explica o impacto;
• evita mudança cosmética;
• não reescreve fluxo inteiro;
• não troca padrão sem combinar.

Descrição de PR boa:

## problema
Depois do deploy de 21/05, usuários com perfil antigo recebiam erro 500 ao salvar cadastro porque `phone` podia vir nulo.

## solução
Normaliza `phone` vazio antes de chamar `CreateProfile` e adiciona teste para conta antiga sem telefone.

## validação
- reproduzi o erro antes da correção
- rodei teste X
- validei fluxo em staging com usuário antigo

Isso conversa diretamente com o que já apareceu em primeiros 90 dias como dev junior: autonomia não é fazer sozinho. É deixar seu processo visível.

depois do bug: faça a retrospectiva pequena

Quando o fogo apaga, vem outra armadilha: tentar esquecer o assunto porque foi desconfortável.

Não faça isso.

Você não precisa escrever uma autópsia de dez páginas para todo bug pequeno. Mas precisa extrair aprendizado. Um registro privado já ajuda:

Bug em produção - 21/05

O que aconteceu:
- campo phone podia vir nulo em contas antigas

Por que passou:
- teste só cobria conta nova
- eu não conferi dado legado
- review focou na regra principal, não no caso antigo

O que vou mudar:
- perguntar sobre dado legado quando mexer em cadastro
- incluir caso nulo no teste
- colocar checklist de validação no PR

Se o time tem retrospectiva, leve uma versão objetiva:

Acho que esse bug passou porque eu testei só conta nova. Para próximos PRs nesse fluxo, vou validar conta antiga também. Faz sentido adicionarmos isso ao checklist?

Isso transforma erro em melhoria de processo. É exatamente o tipo de postura que ajuda em 1:1, feedback e primeiros 30 dias.

o que não fazer

Guarde esta lista. Ela evita metade dos problemas:

• não apague evidência para parecer menor;
• não force push em branch compartilhada durante incidente sem combinar;
• não altere dado de produção manualmente sem autorização;
• não culpe outra pessoa no canal público;
• não diga “corrigido” antes de validar;
• não misture hotfix com refactor;
• não desapareça depois de pedir ajuda;
• não transforme todo bug em crise emocional.

Também não use o bug para concluir que você não serve para tech. O primeiro emprego já tem ansiedade suficiente. Se toda falha vira prova de incapacidade, você vai aprender menos, não mais.

Para treinar debug fora do incêndio, escolha um projeto pequeno, quebre de propósito, leia stack trace, escreva passos de reprodução e documente a correção. A comunidade de Python Brasil é um bom ponto de partida para praticar projetos simples, scripts e leitura de erro sem precisar esperar a pressão do trabalho real.

um roteiro de 30 minutos para o primeiro susto

Quando o bug aparecer, siga esta ordem:

0-5 min
- respira
- confirma sintoma básico
- avisa no canal certo que está investigando

5-15 min
- tenta reproduzir
- coleta horário, usuário, request id, print ou log
- identifica PR/deploy suspeito

15-25 min
- estima impacto
- chama pessoa sênior se houver risco alto
- testa hipótese pequena ou rollback local

25-30 min
- atualiza o canal com fatos
- combina próximo passo: rollback, hotfix, investigação ou monitoramento

Esse roteiro não resolve todo bug. Mas impede o pior comportamento: silêncio, chute e pânico.

o sinal de crescimento

Seu primeiro bug em produção vai ficar na memória. Talvez você lembre da mensagem no Slack, do coração acelerado, do review depois, da vergonha de perceber que um caso simples passou.

Tudo bem.

O sinal de crescimento não é nunca quebrar nada. É quebrar menos com o tempo, perceber mais cedo, comunicar melhor, corrigir com menos ruído e transformar cada incidente em ajuste de processo.

Dev junior confiável não é quem nunca erra. É quem não esconde erro, não repete o mesmo padrão sem aprender e não deixa o time descobrir sozinho que algo está pegando fogo.

No começo, isso vale tanto quanto saber framework da moda. Talvez mais.