ROTEIRO ANTIGO DETECTADO

“Uma aprovação rápida significa que eles não olharam de verdade”

Experimente esta resposta:

“Uma aprovação rápida significa que o diff estava claro, não que passaram batido.”

Faça a autoavaliação de 60 segundos →

VER A PRÁTICA

Crie uma resposta para este pensamento e um passo para colocá-la à prova.

O PENSAMENTO

“Uma aprovação rápida significa que eles não olharam de verdade”

SUA RESPOSTA GRAVADA

“Uma aprovação rápida significa que o diff estava claro, não que passaram batido.”

UM PASSO PRIVADO

Abra seus últimos três PRs mergeados e confira se alguma aprovação rápida acabou revertida ou marcada — sem supor, verificando de verdade.

A aprovação de quatro minutos num diff de 312 linhas

01 / O aviso que chega antes de você terminar a descrição
Você abre o pull request, cola o link no canal do time e começa a escrever a descrição — a parte em que explica a lógica complicada da migração. Antes de terminar a segunda frase, o check verde aparece: Approved. Quatro minutos. Trezentas e doze linhas alteradas em seis arquivos, e o reviewer clicou em menos tempo do que leva para ler o diff uma vez, quanto mais duas.
02 / A reauditoria que você faz em cima de si mesmo
Você percorre de novo o próprio diff, caçando a linha que com certeza passou batido — a função auxiliar que você renomeou pela metade, o caso extremo na lógica de retry. Você começa a listar mentalmente quais arquivos não poderiam ter carregado em quatro minutos. Em vez de dar merge, você deixa o PR aberto e sobe em silêncio mais um commit corrigindo algo que ninguém apontou, porque achar isso antes de qualquer outra pessoa parece a única forma de saber que o código realmente sustenta. O alívio dura o tempo de abrir o próximo PR.
03 / Checar como um bug que passou batido realmente aparece
Antes de subir esse fix que ninguém pediu, abra o histórico recente de PRs do seu time e procure aprovações que chegaram em minutos, depois rastreie o que aconteceu depois — mergeado, em produção, ainda de pé semanas depois sem revert e sem incidente. Essa é a evidência real que uma aprovação rápida deixa, não uma sensação sobre quanto tempo o clique deveria ter levado.

TRACE · 01/04

Como este roteiro controla você

Você relê o diff sozinho assim que o 'Approved' aparece, caçando o que com certeza passou batido em quatro minutos.
Em vez de dar merge, você sobe em silêncio mais um fix num ponto que ninguém apontou, só para o caso de ter sido exatamente isso.
Uma aprovação no mesmo minuto incomoda mais do que uma demorada — parece que ninguém realmente abriu os arquivos.

SOURCE_LOCATED · 02/04

A regra oculta por baixo

O Julgamento do Review

Se uma aprovação não durou tempo suficiente para de fato ler cada linha alterada, ela não conta como retorno de verdade — é só um carimbo, e o código continua sem verificação até você mesmo achar a falha.

FORGING_REPLACEMENT · 03/04

Linhas de substituição (grave estas)

Uma aprovação rápida significa que o diff estava claro, não que passaram batido.
Se algo estiver errado, o CI e o próximo reviewer também vão pegar.
Eu não preciso do tempo de leitura de outra pessoa para saber que esse código funciona.

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

“Uma aprovação rápida significa que eles não olharam de verdade”

Eu digo

“Uma aprovação rápida significa que o diff estava claro, não que passaram batido.”

Depois faço uma coisa

Abra seus últimos três PRs mergeados e confira se alguma aprovação rápida acabou revertida ou marcada — sem supor, verificando de verdade.

STATUS: READY_TO_INSTALL

Apagar este pensamento

4 minutos. Sua voz. Grátis.

Começar este wipe exato no app →

O protocolo de wipe

Escreva o pensamento exatamente como ele toca: "Uma aprovação rápida significa que eles não olharam de verdade". 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

Uma aprovação de quatro minutos em centenas de linhas não prova que só passaram os olhos?

A velocidade de uma aprovação reflete principalmente o quanto a pessoa já conhecia o código ao redor, não o cuidado da leitura — quem acompanhou a branch desde o primeiro commit precisa de bem menos tempo no diff final do que quem abre tudo pela primeira vez.

Por que eu subo um fix extra que ninguém pediu depois de uma aprovação rápida?

Esse commit a mais não é realmente sobre o código — é uma forma de sentir que alguém revisou a fundo, mesmo quando essa pessoa é você, conferindo o próprio trabalho pela segunda vez.

Se a aprovação é real, por que parece pior do que receber comentários?

Comentários mostram o que alguém viu. Uma aprovação silenciosa não diz nada sobre o que foi olhado, então a cabeça preenche essa lacuna com a pior suposição em vez de descansar.