Carlos Mendes

Estava no segundo ano de faculdade, sabendo Java e Python, mas sentindo que faltava algo. Queria entender o que separa um programador de um engenheiro de software. Este livro foi recomendado como 'o manual de mentalidade de engenharia'.

DRY (Don't Repeat Yourself) - mas não só código duplicado. Uso para identificar duplicação de conhecimento: mesma lógica de negócio em dois lugares, configurações repetidas, processos manuais que deveriam ser automatizados. É uma lente para ver ineficiências em todo o sistema.

Para estudantes de ciência da computação no penúltimo ano, ou desenvolvedores júnior no primeiro emprego. Leia quando você já sabe programar mas quer entender como pensar sobre software de forma profissional e sustentável.

Estava em reuniões de design técnico e seniores falavam 'Observer', 'Factory', 'Decorator' - era como se falassem outro idioma. Escolhi este livro para aprender o vocabulário que me fazia sentir excluído das discussões importantes.

Strategy Pattern. Uso semanalmente para isolar algoritmos que mudam frequentemente (pricing, validações, formatações). No código, manifesta como injeção de dependência - ao invés de if/else gigantes, componho comportamentos. Facilita testes e mudanças de requisitos.

Para mid-level engineers (3-5 anos) que querem influenciar decisões de arquitetura. Leia quando você domina a linguagem mas suas soluções parecem sempre 'gambiarras'. O livro mostra que existe estrutura por trás do caos aparente.

Herdei um monolito de 200k linhas sem testes. Qualquer mudança quebrava algo em produção. Estava paralisado entre 'deixar como está' e 'reescrever tudo'. Refactoring me mostrou que existe um caminho do meio: evolução incremental e segura.

Extract Method + Working Effectively with Legacy Code. Antes de qualquer mudança, escrevo um teste de caracterização do comportamento atual. Depois faço micro-refatorações (renomear, extrair, mover) sempre mantendo verde. Em 6 meses transformei o sistema mais temido em um dos mais seguros para modificar.

Para qualquer desenvolvedor que trabalha com código legado (ou seja, 90% de nós). Essencial quando você está assumindo um sistema existente ou quando seu próprio código de 6 meses atrás parece ter sido escrito por um estranho.

Foi promovido a Staff Engineer e precisava decidir entre PostgreSQL, MongoDB, Cassandra, Redis para diferentes use cases. Minhas decisões impactariam a empresa por anos. Precisava entender profundamente trade-offs de bancos de dados, não só tutoriais superficiais.

CAP Theorem na prática. Quando design sistemas, começo perguntando: 'o que acontece durante uma partition?' Isso guia se uso transações ACID (consistência forte) ou eventual consistency. Uso diariamente para explicar stakeholders por que não podemos ter 'zero downtime E consistência perfeita E latência de 10ms'.

Para senior+ engineers que tomam decisões de arquitetura ou staff engineers mentorando times. Leia quando você for responsável por escolher tecnologias que custarão milhões para mudar depois. Idealmente antes de arquitetar seu primeiro sistema distribuído.

Estava me preparando para entrevistas de Staff na FAANG, mas percebi que o livro era mais do que prep de entrevista - era um framework mental para pensar sobre escala, disponibilidade e trade-offs de forma estruturada em qualquer sistema.

O framework de 'requisitos não-funcionais' (RNFs). Agora em todo design doc, explicito: QPS esperado, p99 latência, disponibilidade target, custo de infra. Isso força conversas honestas sobre trade-offs antes de escrever uma linha de código. Economiza meses de retrabalho.

Para engineers mid-level+ que querem crescer para senior/staff. Leia quando você já construiu alguns sistemas mas quer entender as decisões de arquitetura de forma sistemática. Ótimo complemento ao DDIA - este é mais prático e orientado a casos de uso.