O que aprendi lendo código de outras pessoas
Em 2019 eu evitava ler código que não tinha escrito. Parecia mais lento que escrever do zero. Estava completamente errado — e aprendi isso da forma mais dolorosa possível.
Herdei um módulo de integração que outro dev tinha escrito.
Minha reação inicial foi querer reescrever. Parecia mais rápido do que tentar entender o que estava lá. Eu sabia o que o módulo precisava fazer. Sabia Python. Escrevia do zero em duas horas.
O sênior vetou. "Leia o código primeiro. Se depois de ler você ainda quiser reescrever, conversamos."
Li. Levou quatro horas. E descobri três edge cases que o dev original tinha resolvido que eu não teria pensado se tivesse reescrito do zero.
O código estava longe de ser bonito. Variáveis com nomes razoáveis, comentários ausentes onde mais faziam falta, uma função de 60 linhas que fazia trabalho demais.
Mas dentro daquele código feio havia conhecimento: sobre o comportamento real da API de terceiro que mudava formato de resposta dependendo do parâmetro. Sobre um timeout que precisava ser diferente para payloads grandes. Sobre um retry com backoff que tinha sido adicionado depois de um incidente de produção.
Código não é só a lógica visível — é também a história de problemas que já foram resolvidos.
O que aprendi a fazer ao ler código de outros:
Não começa da linha 1. Começa pelos testes (se existirem) — eles documentam o comportamento esperado. Depois os pontos de entrada (funções públicas, rotas, handlers). Depois o fluxo principal. Os detalhes de implementação você entende por demanda, quando precisa.
Quando encontra algo que parece errado ou desnecessário, antes de deletar, pergunta: por que isso está aqui? Código extra em lugares críticos costuma ser resposta a problema real que você ainda não encontrou.
Comentários do tipo # HACK: ou # TODO: são ouro — alguém sinalizou que aquele ponto merece atenção.
A habilidade de ler código de outros é diferente de escrever código.
Escrever é criar estrutura do zero, seguindo o seu modelo mental. Ler é reconstruir o modelo mental de outra pessoa a partir da estrutura que ela deixou. São habilidades relacionadas mas diferentes — e leitura é frequentemente a que o dev júnior menos pratica.
No trabalho em time, você vai passar tanto tempo (talvez mais) lendo código quanto escrevendo. Código legado de outro dev, PRs de colega, biblioteca de terceiro que você precisa entender para integrar.
Ficar confortável com leitura — sem pressa de reescrever, sem frustração com o que "poderia ser mais simples" — é uma das coisas que mais acelerou meu crescimento técnico em 2019.