ROTEIRO ANTIGO DETECTADO
“Se o código é ruim, talvez eu seja ruim em avaliar código”
Experimente esta resposta:
“Esse trecho pode estar ruim e eu ainda estar lendo com cuidado.”VER A PRÁTICA
Crie uma resposta para este pensamento e um passo para colocá-la à prova.
O PENSAMENTO
“Se o código é ruim, talvez eu seja ruim em avaliar código”
SUA RESPOSTA GRAVADA
“Esse trecho pode estar ruim e eu ainda estar lendo com cuidado.”
UM PASSO PRIVADO
Pegue um trecho curto de código que você já viu hoje e escreva, num bloco de notas privado, três listas: o que está confuso, o que pode ser legado/contexto, e o que ainda falta para eu avaliar melhor. Sem editar nada.
No diff aberto, a dúvida sobre seu olhar
- 01 / Quando o review já entra torto
O gatilho costuma ser simples: você abre um diff, encontra uma escolha confusa, um nome torto, um atalho antigo, e percebe que não consegue decidir na hora se aquilo é só difícil de ler ou realmente mal feito. É nesse segundo que a frase aparece quase pronta: se o código é ruim, talvez eu seja ruim em avaliar código.
- 02 / Fechar rápido, para parar de se medir
A partir daí, você começa a ler menos o código e mais a si mesmo. Reabre trechos, compara com outras partes, procura um detalhe que prove que sua leitura está correta, ou então desiste e segue adiante com uma dúvida silenciosa. O alívio vem quando você transforma a incerteza em veredito sobre você — porque, pelo menos por alguns minutos, o problema parece nomeado.
- 03 / Separar o estado do sistema do seu critério
Na próxima vez, pare no instante em que a avaliação vira identidade. Em vez de concluir algo sobre você, nomeie só o que está faltando para julgar melhor: contexto, tempo, exemplo anterior, histórico da decisão. Você não precisa decidir o seu valor como leitor de código para admitir que ainda não tem elementos suficientes sobre aquele trecho.
TRACE · 01/04
Como este roteiro controla você
- Você encontra um trecho confuso e, em vez de ficar só na dúvida sobre ele, passa a duvidar do seu próprio julgamento.
- Se o código parece mal escrito, você tenta provar para si mesmo que deveria ter percebido isso mais cedo e com mais clareza.
- Você sai do review com a sensação de que a qualidade do código e a sua competência de avaliação são a mesma coisa.
SOURCE_LOCATED · 02/04
A regra oculta por baixo
O Roteiro da Herança Legada
Por baixo desse pensamento, costuma existir uma regra rígida: se eu não consigo julgar um trecho com rapidez e segurança, então meu olhar é o problema. Isso empurra você a transformar falta de contexto em defeito pessoal e a tratar qualquer hesitação como falha de competência, em vez de simplesmente sinal de que o material ainda não está claro o bastante.
FORGING_REPLACEMENT · 03/04
Linhas de substituição (grave estas)
- Esse trecho pode estar ruim e eu ainda estar lendo com cuidado.
- Eu posso precisar de mais contexto sem concluir nada sobre meu critério.
- Um código confuso não prova que eu sou confuso.
No app são geradas por pessoa — isto é o sabor, não o seu roteiro. O seu é construído com as suas palavras exatas.
INSTALL · 04/04
O protocolo, em um cartão
Quando penso
“Se o código é ruim, talvez eu seja ruim em avaliar código”
Eu digo
“Esse trecho pode estar ruim e eu ainda estar lendo com cuidado.”
Depois faço uma coisa
Pegue um trecho curto de código que você já viu hoje e escreva, num bloco de notas privado, três listas: o que está confuso, o que pode ser legado/contexto, e o que ainda falta para eu avaliar melhor. Sem editar nada.
STATUS: READY_TO_INSTALL
Apagar este pensamento4 minutos. Sua voz. Grátis.
O protocolo de wipe
- Escreva o pensamento exatamente como ele toca: "Se o código é ruim, talvez eu seja ruim em avaliar código". Palavra por palavra — o wipe mira a frase, não a sensação.
- Rastreie a regra e a ação evitada. Do que esse pensamento convenientemente desculpa você?
- Grave as linhas de substituição abaixo com a sua própria voz. Fale para valer — sem gravação, sem instalação.
- Rode o ciclo: toque toda manhã e noite, registre uma ação-prova por dia durante 7 dias.
Respostas diretas
Quando eu travo num diff cheio de nomes ruins, isso quer dizer que eu não sei avaliar código?
Não necessariamente. Às vezes o trecho está mal nomeado, misturado com decisões antigas ou dependente de contexto que não está visível. O travamento mostra que o material não está claro o bastante para uma avaliação limpa, não que seu critério tenha desaparecido.
Se eu preciso reler a mesma parte várias vezes, não é porque meu olhar falhou?
Pode ser só porque aquele trecho pede mais contexto do que o disponível na primeira passada. Releitura, nesse caso, é um sinal de cautela útil: você está tentando separar o que o código mostra do que você ainda não sabe sobre ele.
Por que eu acabo saindo do review pensando mais em mim do que no código torto da tela?
Porque é mais fácil transformar a incerteza em juízo pessoal do que ficar um pouco mais tempo na dúvida técnica. O pensamento encurta o desconforto: se o problema é você, parece que existe uma resposta definitiva. Mas isso embaralha código confuso com competência confusa.
Roteiros antigos relacionados
Autoavaliações relacionadas
Ciência relacionada
Pesquisadores para conhecer
Mecanismos relacionados
A pesquisa por trás deste roteiro
- Postmortem Culture: Learning from Failure — Google SRE, Google SRE Book, 2016
- Invisible Labor in Open Source Software Ecosystems — Champion et al., arXiv, 2024
- Stack Overflow 2025 Developer Survey: Trust in AI at an All-Time Low — Stack Overflow, 2025
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering — arXiv, 2025