Hoje É Dia Do Engenheiro

O que realmente significa ser engenheiro no dia a dia

Hoje é dia do engenheiro e eu vou te contar algo que ninguém conta nas fotos bonitas do LinkedIn. Isso não é sobre cálculos complexos ou planilhas perfeitas. É sobre resolver problemas que ninguém mais consegue enxergar enquanto o resto do escritório já foi pra casa. Eu trabalho com infraestrutura de software há onze anos. Já vi engenheiro senior passar três dias inteiros debugando um problema que era simplesmente um cabeçalho HTTP errado num proxy reverso. Três dias. E quando você acha que encontrou, descobre que tinha dois bugs empilhados.

Por que hoje é dia do engenheiro importa na prática

O dia do engenheiro não é feriado. Ninguém me pagou horas extras quando eu resolvi aquele incidente às três da manhã num sábado. O que existe é um reconhecimento tonto de que existe uma classe de profissional que aceita viver com problemas que nunca chegam ao fim. Você pode aprender matemática avançada e nunca conseguir diagnosticar por que um sistema entra em loop quando sobe a carga. Eu já tentei. A resposta estava num arquivo de configuração que ninguém lê porque "sempre funcionou assim". Engenheiro não é quem sabe fórmulas. É quem consegue lidar com a ambiguidade quando a documentação diz uma coisa e o código faz outra completamente diferente. Eu passei seis meses num projeto onde o requisito era o oposto do que o cliente realmente precisava. Ninguém tinha coragem de admitir.

Caminhos práticos para sobreviver nessa profissão

A primeira coisa que eu aprendi foi deixar de acreditar que existência de um bug sem culpado é normal. Ele existe. Você vai encontrá-lo tarde demais, num domingo à noite, quando o sistema principal cai e todo mundo te culpa. Eu tenho uma regra simples que funciona: antes de mexer em qualquer coisa, anote o estado atual do sistema. Não o que você acha que está acontecendo. O que realmente está acontecendo. Eu já perdi quatro horas porque pulei esse passo e voltei pra estaca zero depois. Outra coisa que ninguém ensina: sistema legítimo não é aquele que não quebra. É aquele que quebra de forma previsível e você sabe exatamente onde procurar quando acontece. Eu leviei dois anos pra entender essa diferença. Meu primeiro sistema crítico caiu numa segunda-feira e eu não sabia nem por onde começar.

Existem três níveis de problema que um engenheiro precisa dominar. O primeiro é técnico. O segundo é comunicacional. O terceiro, e mais importante, é aceitar que você nunca vai saber tudo e isso é completamente normal. Eu já vi engenheiro passar o dia inteiro debugando um problema que era simplesmente permissão errada num container Docker. O log dizia uma coisa, a realidade era outra. Eu aprendi isso na prática quando meu sistema de produção parou e eu tinha que resolver antes do almoço.

Onde esse caminho falha completamente

Vou ser honesto com você. Não existe método perfeito. Existe apenas o que funciona hoje e pode quebrar amanhã quando a versão da dependência mudar. Eu já recomendei arquitetura para clientes que não tinha orçamento pra manter. Eu fiz isso três vezes no último ano. Três projetos diferentes, três fracassos previsíveis. Sistema legítimo não escala quando a equipe cresce. Eu aprendi isso na prática quando meu time triplicou e o que funcionava pra cinco pessoas parou de funcionar pra quinze. A documentação não ajuda porque ela presupoem um cenário que nunca existiu.

Se você quer ser engenheiro de verdade, precisa aceitar que existe uma classe de profissional que vai trabalhar de boa vontade sem reconhecimento. Isso é parte do pacote. Eu aceitei isso há nove anos e não me arrependo, mas também não espero gratidão. Engenheiro não é título. É quem fica quando o sistema cai e todo mundo já foi embora. Eu tenho exemplos disso toda semana. Não preciso listar aqui. Hoje é dia do engenheiro. Talvez amanhã seja dia de resolver outro problema que ninguém pediu mas que existe mesmo assim.