O que separa um bom programador de um bom engenheiro de software?

Question

Accepted Answer

Um **bom programador escreve código funcional**. Um **bom engenheiro de software resolve o problema certo holisticamente** — dominando requisitos, design, tradeoffs, manutenibilidade, testes, operações e o contexto de negócios ao redor do código. Engenharia é código mais julgamento mais responsabilidade sobre todo o ciclo de vida.

## Onde a linha realmente fica

Escrever código que passa nos testes é a parte fácil e aprendível. A parte mais difícil e valiosa é tudo ao redor disso: decidir *o que* construir, *como* deve se encaixar no sistema, e *qual será o custo* de conviver com isso depois.

- **Um programador pergunta** "Como faço isso funcionar?" e para quando funciona.
- **Um engenheiro pergunta** "Que problema estamos realmente resolvendo, quais são as restrições, e qual é o design mais barato que sobrevive a mudanças?"

## O que o engenheiro é responsável além do código

- **Requisitos** — esclarece a necessidade real, questiona a especificação, expõe casos extremos antes que se tornem incidentes.
- **Tradeoffs** — pondera velocidade vs. simplicidade, construir vs. comprar, agora vs. depois, e torna a escolha *explícita*.
- **Design e manutenibilidade** — escreve para o próximo leitor, mantém o raio de impacto pequeno, evita complexidade acidental.
- **Testes e operações** — pensa em modos de falha, observabilidade, rollback, e o que acontece às 3 da manhã.
- **Comunicação** — explica decisões, as documenta, e leva outros junto.
- **Contexto de negócios** — conecta o trabalho aos resultados, não apenas aos tickets fechados.

## Uma nuance útil

Isso **não é** sobre senioridade ou título de cargo — muitos "engenheiros" programam, e alguns "programadores" engenham. É uma **mentalidade**: assumir responsabilidade pelo resultado, não apenas pela saída. A mudança é de *"meu código funciona"* para *"este sistema cumpre seu propósito, confiável, e não punirá quem o tocar a seguir."*

## Por que isso importa

Entrevistadores e times valorizam o engenheiro sobre o programador porque **bugs, outages e sistemas não mantíveis raramente vêm de código que não compila — vêm de falta de julgamento**: a pergunta não feita, o tradeoff ignorado, o caso extremo não testado. Demonstrar que você pensa sobre todo o ciclo de vida — e consegue articular *por que* escolheu um caminho em vez de outro — é o que sinaliza que você pode ser confiado com sistemas reais e consequências reais, que é exatamente do que se trata crescer nessa carreira.