Gif by NicotraRepresentacoes on Giphy

E haeeeee meu povo! 💻 Aqui vem eu trazendo polêmicas, tretas e “briga de cachorro grande”, mas com a cabeça e o código no lugar certo? Brincadeirinha! 😄

De um lado, temos Elemar Júnior (CEO da EximiaCo), um Tech Trusted Advisor e autor que une sólido conhecimento técnico em arquitetura corporativa e programação de alto desempenho à visão de negócios. Ele é o cara que nos lembra, com rigor, o perigo do "amadorismo remunerado" e a falta de fundamentos no código.

Do outro, está Eduardo Pires (Microsoft MVP e Regional Director), Arquiteto de Software, consultor e fundador do desenvolvedor.io, conhecido por sua paixão em disseminar as melhores práticas e arquiteturas no ecossistema .NET. Ele é a voz que defende que a humildade é a característica mais importante para a evolução contínua do desenvolvedor.

Dois gigantes. Duas ideias fortes. E, claro, como vocês já sabem, eu sou o tipo de programador que gosta de uma zoeira, mas também falo sério para não perder o costume!

O Confronto de Ideias: Fundamento vs. Atitude

Recentemente caíram na minha timeline dois posts que me fizeram pensar profundamente sobre o estado da engenharia de software atual. Um do Elemar Júnior falando sobre sermos “amadores remunerados” e outro do Eduardo Pires explicando qual seria a característica mais importante de um programador.

Dois caras gigantes. Duas ideias fortes que atacam o mesmo problema por ângulos diferentes: a qualidade e a maturidade do profissional de tecnologia. E aqui está eu, um peixinho no meio deles querendo dar opinião. Perfeito. 😀

O Que Cada Mestre Disse

  • Elemar Júnior (A Falta de Fundamento): O Elemar argumenta que falta fundamento na nossa área. Segundo ele, muitos desenvolvedores não entendem o que estão fazendo. Não sabem estruturas de dados, não sabem complexidade algorítmica (O(n), O(nlogn), etc.), dependeram demais de frameworks e agora vivem apagando incêndio porque não dominam o básico. O framework virou muleta, e a falta de base transforma o trabalho em um exercício constante de improvisação cara.

  • Eduardo Pires (A Força da Atitude): O Eduardo traz outro ângulo. Para ele, a pior característica que um programador pode ter é arrogância. Ele defende humildade, aprendizado contínuo e a importância de não virar refém de ferramentas. A mensagem é clara: Estude, melhore, revise, evolua. Um profissional humilde está sempre disposto a admitir o erro e buscar o conhecimento, seja ele fundamental ou prático.

A Minha Sincera Opinião? A Dualidade Necessária🙂

Ambos têm razão em seus pontos, que são espelhos da mesma crise. No entanto, o debate fica incompleto se não considerarmos o contexto de mercado e a natureza humana.

É aqui que eu entro, e trago outras analogias para enriquecer essa discussão: O Que Ninguém Comentou (E Por Que o Mercado É Assim?)


1. O Trade-off Econômico Inegociável

Esse ponto é crucial: Empresas pagam por resultado AGORA.

Fundamentos são como o cálculo estrutural de um prédio. Ele garante que o edifício não caia em 10 anos. Mas o cliente, impaciente, paga pelo levantamento rápido das paredes de gesso. O mercado de tecnologia, muitas vezes, premia quem consegue "levantar a parede" mais rápido, mesmo que a fundação seja de areia.

O trade-off econômico existe. Muitas vezes o cliente quer algo amanhã, não ano que vem. Sim, fundamentos são importantes, sustentam o sistema e evitam tragédias futuras. Mas alguém tem que entregar valor perceptível no curto prazo.


2. A Especialização Prática como "Artesanato"

Existe um valor imenso no desenvolvedor que é excelente em "apertar a embreagem no tempo certo", pense nele como o artesão.

O cara entrega, resolve, faz acontecer. Ele domina o framework como um instrumento musical. Ele não sabe a física das ondas sonoras (o fundamento), mas toca a melodia que o cliente quer (o valor). Nem todo músico precisa construir o instrumento do zero, o importante é saber tocar bem aquilo que faz sentido para o público. A especialização prática é um tipo de valor que o mercado absorve e paga bem.

3. A Responsabilidade Coletiva do Ecossistema

O Elemar tem razão ao culpar a falta de estudo, mas a responsabilidade não é só do dev que não estudou. É do ecossistema inteiro.

As ferramentas mudaram o jogo. Abstrações facilitam, mas também escondem detalhes essenciais. A complexidade oculta é uma faca de dois gumes. Arquitetos, bibliotecas, documentação, cultura de testes, e até mesmo as empresas que promovem frameworks como "soluções mágicas", tudo isso influencia. O mercado criou um atalho, e os profissionais seguiram o caminho de menor resistência.

No fim das contas, o buraco é mais embaixo: O dev parou de se aprofundar porque a própria indústria disse que não era necessário. As ferramentas facilitaram tanto que esconderam a complexidade real, criando uma cultura de superficialidade compartilhada.


4. Custo Cognitivo e a Falsa Expectativa de Super-Herói

Cobrar que todo mundo seja ninja em teoria, prático, comunicativo, rápido e ainda tenha saúde mental é simplesmente ignorar como seres humanos funcionam.

Não é sustentável esperar que 100% dos devs sejam mestres em todos os pilares (fundamento, execução, comunicação, inteligência emocional).

Um exército precisa de soldados de linha de frente (os executores), precisa de engenheiros (os arquitetos de fundamento) e precisa de estrategistas (os líderes). Todos são importantes, mas têm papéis e focos diferentes. A cobrança excessiva leva ao esgotamento e à mediocridade em todas as áreas.


5. O Mercado Falha Junto

Universidades, bootcamps, RH, empresas e expectativas formam um grande sistema de incentivos. E, como todo sistema, ele molda comportamentos. Se o processo de contratação valoriza mais uma lista interminável de frameworks no currículo do que a capacidade real de resolver problemas e aprender rápido, a consequência é previsível: formamos profissionais que priorizam colecionar ferramentas em vez de dominar fundamentos.

E isso aparece claramente na prática. Quando você olha as vagas de programação, parece que o programador ideal precisa dominar tudo ao mesmo tempo: Vários bancos de dados, linguagens, arquiteturas, front-end, back-end, ferramentas X, Y, Z e mais meia dúzia de stacks. Ou seja, você é contratado pela quantidade de logotipos que consegue colocar no currículo, não pelo valor concreto que entrega.

Mas o mercado real nem sempre funciona assim. Eu já vi programadores sem formação acadêmica, sem aquela lista enorme de tecnologias, entregarem e resolverem muito mais problemas do que devs com currículos repletos de “habilidades”. Gente que talvez não saiba a teoria por trás de cada coisa, mas que pega o problema, entende o objetivo e faz acontecer.

Esse é o ponto: Quando o sistema recompensa quantidade de conhecimento decorado, ele tende a ignorar o que realmente importa, resultado, clareza e capacidade prática. E é assim que o mercado falha junto.


A Metáfora da Embreagem

Para dirigir, você precisa entender como o motor funciona? Ou você só precisa saber apertar a embreagem na hora certa?

Se exigíssemos que todo motorista dominasse física, mecânica, combustão e engenharia automotiva, quase ninguém teria emprego de motorista. O mesmo vale para programação.

O Papel na Programação

Quem é Você no Código?

O Risco

O Motorista (Artesão)

Domina o framework e entrega rápido.

Essencial para a velocidade, mas... Se o carro morrer na subida, ele não consegue consertar.

O Engenheiro (Cientista)

Domina estruturas de dados e complexidade.

Essencial para a sustentabilidade, mas... O cliente queria a corrida, não o museu de peças.

O Piloto de Corrida (Full-Stack Master)

Consegue fazer as duas coisas.

O sonho de toda empresa.

Conclusão e Reflexão Final

Eu concordo com o Elemar que fundamentos são essenciais para quem quer crescer de verdade (ser um engenheiro) e parar de sofrer com a própria falta de conhecimento.

Eu concordo com o Eduardo que humildade e vontade de aprender são qualidades obrigatórias para qualquer pessoa séria na área (o ponto de partida para a evolução).

E acrescento meu ponto. O mercado deveria abraçar a diversidade de perfis. Nem todo dev precisa ser uma enciclopédia ambulante. Nem todo dev precisa ser um executor ultra rápido. O segredo está em times complementares e cultura de aprendizado real.

Perguntas Inversas para o Líder:

  • Por que essa escolha entre "dev rápido" e "dev profundo" existe no seu time?

  • O seu ambiente está incentivando estudo e fundamento ou só a cobrança por funcionalidades?

E para finalizar do meu jeitinho, com um toque de seriedade 🙃:

  • Se você é do time que só sabe apertar a embreagem, tá tudo bem... até o carro morrer na subida, o cliente te ligar no fim de semana e você não ter ideia de onde está o problema.

  • Se você desmonta o motor todo só por esporte, maneiro... mas o cliente queria a corrida, não o museu de peças. Entregue o carro andando!

  • E se você consegue fazer as duas coisas, ou pelo menos tem a humildade de correr atrás do fundamento quando o motor engasga... meu amigo... te contrato ontem. 😅

A verdade está no meio: É preciso ter a humildade de saber que não se sabe, e a disciplina de aprender os fundamentos para que o carro (o sistema) não te deixe na mão.

E aí, de qual lado da pista você está? Deixa seu comentário!


Comentar

or to participate