De Desenvolvedor Java à Engenheiro de Software: A Evolução do Mindset na Era Cloud-Native

Ao longo da minha jornada na área de tecnologia, vi linguagens nascerem, paradigmas mudarem e a infraestrutura migrar de servidores físicos “de estimação” para o dinamismo do Cloud-Native. Mas, em meio a tantas transformações, uma discussão permanece incrivelmente atual: o que realmente separa um codificador de um engenheiro?

Não tenho a pretensão de cravar uma definição acadêmica absoluta aqui. Quero, na verdade, compartilhar uma perspectiva prática baseada nas trincheiras do desenvolvimento. Muitas vezes, vi profissionais talentosos ficarem estagnados. Não por falta de capacidade intelectual, mas porque enxergavam seu trabalho apenas como “escrever código” em vez de “projetar sistemas”.

Para ilustrar isso, vou compartilhar algumas histórias sobre o Java, uma das linguagens que domino, e como elas se traduzem para os desafios modernos que enfrentamos hoje.

“Java consome muitos recursos”

Uma das reclamações mais clássicas que ouço é sobre o consumo de memória do Java. Um Javeiro puro, ao enfrentar lentidão, muitas vezes aceita isso como uma falha inerente da linguagem. “É assim mesmo”, dizem.

A verdade é que, no passado, a JVM se comportava como um locatário que alugava um grande galpão (memória) e não devolvia o espaço não utilizado para o dono (Sistema Operacional). No entanto, um engenheiro de software não se contenta com o “é assim mesmo”. Ele investiga o porquê.

Hoje, a realidade evoluiu drasticamente. Temos coletores de lixo (Garbage Collectors) modernos como o ZGC ou o Shenandoah, que devolvem memória de forma eficiente, e tecnologias como o GraalVM, que compila o código Java de forma nativa (Ahead-of-Time). Isso transforma uma aplicação que demorava segundos para iniciar e consumia gigabytes em um binário ultrarrápido que consome apenas dezenas de megabytes.

O problema nunca foi apenas a linguagem, mas a falta de compreensão de como a ferramenta interage com o ambiente sob ela.

“Tunar a JVM é magia negra”

Já ouvi essa também, e mais de uma vez, a “JVM não é boa o suficiente porque ninguém sabe como configurá-la”. Para o desenvolvedor focado apenas em código, os parâmetros da máquina virtual parecem um painel de avião assustador.

A engenharia, porém, é sobre entender os limites e o ambiente. Na era dos contêineres, simplesmente empacotar uma aplicação Java e jogá-la no Docker sem entender como a memória funciona é a receita para o desastre (o famoso OOMKilled — Out of Memory).

Um engenheiro de software entende que o contêiner tem limites restritos (cgroups). Ele não ignora a configuração, ele a adapta para a nuvem. Em vez de adivinhar o tamanho do Heap, ele utiliza as opções de ergonomia modernas da JVM desenhadas especificamente para contêineres:

# Exemplo de mentalidade de engenharia: 
# Entendendo o ambiente de execução e configurando a JVM de forma dinâmica
FROM eclipse-temurin:21-jre-alpine

COPY target/minha-app.jar app.jar
# Em vez de fixar -Xmx, o engenheiro usa porcentagens relativas ao contêiner,
# garantindo que a aplicação respeite os limites orquestrados pelo Kubernetes ou Docker.
ENTRYPOINT ["java", "-XX:InitialRAMPercentage=50.0", "-XX:MaxRAMPercentage=80.0", "-jar", "/app.jar"]

“Qual cache você escolhe?”

No passado, para o bom e velho Javeiro, a pergunta era “Memcache ou Ehcache?”. Hoje, a pergunta costuma ser “Redis ou Caffeine?”.

E hoje, quando questionado sobre isso, minha resposta é: “Depende muito das circunstâncias”. Isso pode trazer surpresa, as vezes se espera que, imerso nesse mundo, eu escolhesse cegamente a biblioteca nativa do Java (Caffeine, por exemplo) no lugar de uma solução externa.

Esse é o sintoma clássico do Javeiro: a escolha baseada em hábito, não em raciocínio. A expertise profunda, mas excessivamente estreita, torna-se uma fraqueza.

Um engenheiro de software faz perguntas antes de escolher:

• Nossa aplicação vai rodar em múltiplas instâncias? (Se sim, um cache local como Caffeine vai gerar inconsistência).
• Qual é a latência de rede se usarmos um serviço como o Redis via LocalStack para testes locais e ElastiCache na AWS em produção?
• O que acontece se o cache cair? O banco de dados suporta o tráfego?

A lealdade do engenheiro não é com o framework, mas com a arquitetura.

// O Desenvolvedor foca na ferramenta (acoplamento forte):
public class RedisProductCache {
    public void save(Product p) { /* lógica hardcoded do Redis */ }
}

// O Engenheiro foca no contrato e no design (abstração):
public interface ProductCache {
    void save(Product p);
    Optional<Product> get(String id);
}

// A implementação pode ser Redis, DynamoDB (via LocalStack em dev), ou Memória.
// O sistema não se importa com a ferramenta, mas com o comportamento.

A Raiz da Diferença: Profundidade vs. Perspectiva

O dilema entre o desenvolvedor Java e o engenheiro de software resume-se a um modelo mental. O Javeiro fica preso dentro de um único ecossistema. Ele foca em como codificar. Seu ponto forte é a profundidade: domina sintaxe, streams complexos, anotações de frameworks. Mas muitas vezes sofre da síndrome do “para quem tem um martelo, todo problema é um prego”.

Se esse mesmo profissional aplicar práticas reais de engenharia, a transição acontece. Ele muda o foco do como para o por que e o que estamos construindo.

O engenheiro de software cobre todo o ciclo de vida do produto. Ele vai dos requisitos à modelagem de dados, da implementação ao deploy automatizado e à observabilidade. Ele não vê Java, Go ou Python como identidades religiosas, mas como instrumentos. Cada um tem suas forças, fraquezas e trade-offs.

Um engenheiro constrói pontes entre conceitos. Ele avalia o custo de sua arquitetura na nuvem, a experiência do usuário, a segurança e a resiliência do sistema em cenários de falha. Ele otimiza para a adaptabilidade, não apenas para a familiaridade.

A diferença entre um desenvolvedor Java e um engenheiro de software não está puramente na habilidade técnica de digitar código, mas na perspectiva. É a diferença entre resolver uma tarefa isolada e compreender o ecossistema completo onde essa solução irá habitar.

Um bom desenvolvedor Java escreve um código limpo e eficiente. Um excelente engenheiro de software constrói produtos que escalam, duram e evoluem.

As tecnologias vão mudar. A sintaxe de hoje será o código legado de amanhã. Frameworks perderão tração. Mas o pensamento arquitetural, a capacidade de abstração e o bom julgamento de engenharia nunca saem de validade. É isso que separa quem apenas escreve linhas de código de quem verdadeiramente constrói o futuro.