Olá! Eu sou Gabriel Almir, e este post é um recado super pessoal — e profissional — para você que está dando os primeiros passos no desenvolvimento em 2025. É o que eu realmente gostaria de ter ouvido anos atrás.
Eu chamei este texto de Desenvolvimento não é 8 ou 80!, porque percebi que muita gente cai nessa armadilha.
Como eu sempre digo, “O código é o meio, não o fim. A verdadeira inovação acontece quando a tecnologia faz sentido pra quem usa”.
Meu objetivo aqui não é te empurrar um curso, um framework novo ou a tendência do momento. É um papo reto sobre enxergar o quadro completo do que está acontecendo no mercado de tecnologia agora.
O que eu gostaria de ter ouvido lá atrás
Nos últimos anos, ficou claro para mim que ensinar a programar deixou de ser apenas sobre digitar código. Hoje, o jogo mudou para as conexões — conexões entre sistemas, entre pessoas e entre ideias.
Claro que o básico continua essencial, e não tem como fugir disso:
- Saber programar, isso é óbvio.
- Conseguir transformar uma ideia em uma solução que o computador consiga entender.
- Entender os trade-offs de arquitetura (saber por que estou escolhendo A em vez de B).
Mas, gente, isso é só o começo da jornada.
O cenário que eu vejo
No mercado real, o cenário é duplo.
Pequenos negócios
Pense na padaria, na loja do bairro. Eles estão automatizando processos com ferramentas no-code e IA. Isso, para nós, não é uma ameaça; é uma oportunidade de aprender a criar soluções que sejam mais simples e que entreguem valor de verdade.
Grandes empresas
Nas grandes empresas, o bicho pega. Elas estão numa corrida insana para reescrever sistemas inteiros, lidando com milhões de usuários simultâneos, requisitos que mudam toda semana, arquiteturas cada vez mais complexas e, claro, a eterna dor de cabeça de integrar sistemas legados com o que há de mais novo.
Mas no fim das contas, a essência do nosso trabalho se mantém firme: resolver problemas reais de pessoas reais. Quem está chegando agora precisa internalizar isso o quanto antes.
Por que digo que não é 8 ou 80
Você não precisa escolher entre dois extremos:
- Ser aquele "codador" que só recebe a tarefa e executa (meio caminho para a frustração).
- Ou ser aquele "arquiteto de software" que vive flutuando no mundo dos diagramas e nunca bota a mão na massa.
O segredo, na minha visão, está no equilíbrio. É sobre:
- Entender o problema antes de começar a escrever qualquer linha de código.
- Conhecer as ferramentas, mas sem se tornar refém delas.
- Construir pontes entre o lado técnico e as necessidades reais do negócio.
- Ter uma visão de produto, e não apenas uma visão puramente técnica.
- Aprender sempre, mas sem cair no hype de cada nova biblioteca que aparece no Twitter.
O que eu aprendi que realmente importa
1. Saber uma stack não é tudo
Decorar frameworks é conhecimento com data de validade. O que fica, o que é para sempre, é entender os princípios fundamentais: Estruturas de dados, algoritmos, padrões de design (Design Patterns), arquitetura de software e como os sistemas se comunicam (APIs, mensageria e por aí vai).
2. É preciso ter visão de produto
Eu sempre me pergunto: Por que estou construindo isso? Quem vai usar? Qual problema real estou resolvendo? Existe um jeito mais simples de fazer isso?. Sem essa visão, a gente só gera complexidade desnecessária.
3. Desenvolver sensibilidade técnica
É aquela "intuição" que só o tempo e a experiência dão. É o que te ajuda a escolher a ferramenta certa, a saber a hora de otimizar (e, o mais importante, a hora de não otimizar), e a pesar os prós e contras de cada decisão de arquitetura. Lembre-se: Código sem propósito é só um monte de texto. Construa com intenção.
Minha experiência na trincheira
Nos meus mais de 6 anos trabalhando com backend, eu aprendi na marra:
- Sistemas reais são bagunçados. Não, nem tudo é Clean Architecture de livro. Dívida técnica e sistemas legados são parte do nosso dia a dia. Deadlines apertadas existem, e requisitos mudam no meio do caminho. É normal.
- O valor está na entrega. Um código que resolve o problema do cliente, mesmo que pareça "feio", é melhor do que um código "lindo" que nunca chega na produção. Mas, claro, um código sustentável é a meta, e não um que funciona uma vez e depois quebra. O que busco é pragmatismo com qualidade.
- Comunicação é 50% do trabalho. Você precisa saber explicar suas decisões técnicas para quem não é da área, entender a dor do time de negócios e colaborar ativamente com PMs, designers e outros desenvolvedores. E, por favor, documente o que você fez de forma clara.
Para quem está começando
Se você está começando em 2025, o volume de informação pode ser intimidador. Em vez de cair no "inferno dos tutoriais" e seguir todo hype, concentre-se em aprender os fundamentos sólidos. Como eu disse, frameworks vêm e vão, mas os princípios de arquitetura e design de sistemas são eternos.
A melhor forma de aprender é construir projetos reais, mesmo que sejam pequenos. Pegue um problema, comece do zero e crie a solução até o fim.
Invista pesado em soft skills como empatia e comunicação para entender o negócio e colaborar. E a síndrome do impostor é real, mas não deixe que ela te trave. Evite comparações tóxicas e aquele perfeccionismo que te impede de entregar. E quando o primeiro bug aparecer (porque ele vai aparecer), não desista. Programar, na essência, é isso: resolver problemas.
O futuro da nossa profissão
Com a IA, a automação e o no-code, o nosso papel não está desaparecendo, está evoluindo. Estamos migrando:
- De executor para arquiteto (pensando no sistema como um todo).
- De codificador para solucionador (entendendo o problema a fundo).
- De técnico para tradutor (conectando o mundo do negócio com o da tecnologia).
- De especialista para generalista em T (profundo em um ponto, mas com conhecimento amplo em várias outras áreas).
Minha reflexão final
Gravei o vídeo e escrevi este texto como um recado direto. Não quero ditar regras — eu ainda tenho muito a aprender —, mas sim compartilhar a visão de quem vive isso diariamente e sente a mudança do cenário.
Lembre-se:
O código é o meio, não o fim. A verdadeira inovação acontece quando a tecnologia faz sentido para quem usa.
Não existe atalho, nem fórmula mágica. Existe a sua jornada, o seu ritmo e os seus desafios.
Desenvolvimento não é 8 ou 80. É sobre encontrar o seu equilíbrio:
- Entre o técnico e o humano.