Quando eu percebi que queria ser um engenheiro, não só um programador
Programar é escrever código. Engenharia de software é tomar decisões sobre sistemas com trade-offs reais, em equipe, com restrições reais. A diferença parece semântica até você sentir na prática.
Existe uma distinção que levei um tempo para articular claramente, mas que mudou o que eu buscava no trabalho: a diferença entre programar e fazer engenharia de software.
Programar é escrever código que resolve um problema. É uma habilidade técnica com inputs e outputs relativamente claros. Você entende o requisito, escolhe a abordagem, implementa, testa.
Engenharia de software é diferente. É tomar decisões sobre sistemas — decisões que têm trade-offs, que afetam pessoas além de você, que vão ter consequências durante meses ou anos. É trabalhar com restrições que não são técnicas: prazo, orçamento, conhecimento do time, o que já existe e o custo de mudar.
O momento que tornou essa distinção real foi uma discussão sobre arquitetura num projeto de médio porte na software house.
Tínhamos um sistema que precisava processar eventos assíncronos. A opção mais simples era uma tabela de banco de dados como fila — poll periódico, processa, marca como processado. A opção mais robusta era introduzir um message broker real (RabbitMQ, naquela época).
A decisão técnica pura diria: message broker é a solução correta para esse problema. Mas a decisão de engenharia considerava outras variáveis. Ninguém no time tinha experiência com RabbitMQ. O cliente não tinha orçamento para um servidor adicional. O volume de eventos não justificava a complexidade de um broker dedicado.
A solução certa, naquele contexto, era a tabela de banco de dados. Não porque era tecnicamente superior — era inferior. Mas porque era a solução que o time podia manter, que se encaixava nas restrições do projeto, que não introduzia um ponto de falha que ninguém sabia operar.
Essa foi a primeira vez que eu entendi na prática que engenharia não é escolher a melhor solução técnica. É escolher a solução adequada ao contexto.
Ser engenheiro de software tem dimensões que programar puro não tem.
Comunicação com pessoas não-técnicas. Clientes, gestores, colegas de outras áreas. Traduzir complexidade técnica em impacto de negócio. Explicar por que uma mudança que parece simples vai levar duas semanas.
Design colaborativo. Chegar numa solução que funciona para o time, não só para você. Às vezes a sua solução é melhor tecnicamente mas não é melhor para o time se o time não consegue entendê-la e mantê-la.
Pensar sobre sistemas, não só sobre código. Onde esse código vai rodar. Como vai escalar. O que acontece quando falha. Qual é o plano de rollback.
Existe pressão, especialmente em início de carreira, de se identificar principalmente com a linguagem ou tecnologia que você usa. "Sou desenvolvedor Python." "Sou desenvolvedor React."
Não é errado. Especialização tem valor. Mas identificar-se com a linguagem pode criar um teto — você fica buscando ser melhor na linguagem em vez de melhor em resolver problemas de sistemas.
A transição que aconteceu em mim foi começar a me identificar com o tipo de problema que eu queria resolver, não com as ferramentas que usava para resolvê-los. Sistemas distribuídos, plataformas de alta disponibilidade, infraestrutura que escala. As linguagens e ferramentas seriam o que o problema exigisse.
Essa percepção não veio de um dia para o outro. Veio de um acúmulo de experiências onde eu percebia que o código não era o problema principal — era o julgamento sobre qual código escrever, quando, com quais trade-offs.
Engenharia de software é uma profissão que usa código como ferramenta, mas é fundamentalmente sobre tomada de decisão em sistemas complexos. Quanto mais cedo você começa a pensar sobre o que vai resolver, não só como vai implementar, mais rápido você cresce.
Essa semana: pense na última decisão técnica que você tomou no trabalho — qualquer uma, grande ou pequena. Quais foram os trade-offs que você considerou? Quais você provavelmente não considerou? Fazer essa pergunta retroativamente é como desenvolver o músculo de antecipar trade-offs prospectivamente.