A linguagem de programação não é a sua primeira decisão

Se quando você recebe um novo projeto a primeira coisa que passa na cabeça é “vou usar Go”, “vou usar Node” ou “vou usar Postgres” — para um segundo. Isso é um sinal importante.

Não é culpa sua. A maioria dos cursos e bootcamps ensinam exatamente dessa forma: apresentam uma stack, ensinam a construir coisas com ela, e pronto. Você sai de lá com habilidade técnica, mas sem o hábito de fazer as perguntas que realmente importam antes de escrever a primeira linha de código.

E esse hábito — ou a falta dele — é uma das maiores diferenças entre um dev júnior e um dev sênior.

🎯 O que vem antes da linguagem

Antes de qualquer decisão técnica, você precisa entender o contexto do que está construindo. E isso começa com perguntas que parecem óbvias, mas raramente são respondidas de forma explícita:

Quem vai usar esse sistema? Um time interno de 10 pessoas ou clientes externos espalhados pelo Brasil?
Quantas pessoas vão usar ao mesmo tempo? Dez usuários simultâneos ou dez mil?
Qual é o nível de disponibilidade esperado? O sistema pode cair por uma hora sem impacto, ou isso para a operação inteira?
Qual é o SLA acordado? 99%? 99,9%? 99,99%? A diferença entre esses números é enorme em custo e complexidade.
O sistema é tolerante a falhas? Se um serviço dependente cair, o que acontece? Degrada graciosamente ou derruba tudo?
Ele é crítico para o negócio? Um sistema de relatórios e um gateway de pagamentos não podem ser tratados da mesma forma.
Quais são os guard rails do projeto? Existem restrições de compliance, segurança, privacidade de dados?
Quais são as limitações da empresa? Time pequeno, infraestrutura legada, orçamento restrito?
Quanto isso vai custar? Computação, armazenamento, licenças, observabilidade — tudo tem um preço.

Só depois de ter clareza sobre essas respostas é que a escolha de tecnologia começa a fazer sentido. E muitas vezes, quando você entende bem o contexto, a stack “óbvia” que você escolheria no automático deixa de ser a melhor opção.

⚠️ O custo de pular essa etapa

Você já viu isso acontecer — ou já viveu na pele. O sistema vai para produção, e aí começam os problemas:

O banco de dados não aguenta a carga. A arquitetura não foi pensada para o volume real de usuários. A infraestrutura custa três vezes o previsto. O time precisa parar tudo para refatorar um sistema que acabou de ser entregue.

Esse é o clássico ciclo de “construir, entregar, refatorar porque não atende”. E ele quase sempre começa no mesmo lugar: decisões técnicas tomadas antes do entendimento do problema.

Não é falta de habilidade. É falta de processo.

💬 O óbvio precisa ser dito — e documentado

Aqui tem outro ponto que muita gente ignora: quando esses detalhes não estão claros, é responsabilidade do dev perguntar. Não assumir. Perguntar.

E mais do que perguntar — registrar as respostas.

Não existe infra infinita. Não existe sistema com 100% de uptime (qualquer um que te venda isso está mentindo ou não sabe o que está dizendo). Existem acordos, trade-offs e decisões conscientes.

Esses acordos precisam estar documentados antes do desenvolvimento começar. Se o stakeholder diz que o sistema pode ter 30 minutos de indisponibilidade por mês, isso precisa estar escrito. Se a empresa não tem orçamento para um ambiente multi-região, isso precisa estar claro. Se a tolerância a perda de dados é zero, a arquitetura precisa refletir isso — e o custo associado precisa ser aceito.

O óbvio precisa ser dito porque o que parece óbvio para você frequentemente não é óbvio para o negócio, e vice-versa. Essa comunicação explícita é o que evita o projeto de ir para produção com expectativas completamente desalinhadas.

🚀 Isso é senioridade de verdade

Saber escolher entre Kafka e RabbitMQ é técnico. Saber quando você realmente precisa de um message broker — ou se um simples job agendado resolve — isso é senioridade.

A maturidade técnica não está apenas em dominar ferramentas. Está em saber qual pergunta fazer antes de escolher qualquer ferramenta.

Devs que pensam dessa forma chegam em discussões de arquitetura com contexto, não com preferências. Defendem decisões com base em requisitos reais, não em hype ou familiaridade. E quando algo dá errado em produção — porque vai dar em algum momento — eles têm clareza sobre quais decisões foram tomadas e por quê.

Esse nível de consciência é o que separa quem codifica de quem constrói sistemas.

Se você está no início da carreira: comece a cultivar esse hábito agora. Pergunte mais antes de codar.

Se você lidera times: crie espaço para essas conversas acontecerem antes do desenvolvimento. Não deixe o contexto ser descoberto em produção.

Qual foi a última vez que você (ou seu time) foi direto para a solução sem entender bem o problema? O que aconteceu?