Tem muito profissional de TI que já entregou sistema para cliente, apagou incêndio em produção, fez freela de site, desktop, integração e automação — e mesmo assim ainda sente que não virou um “dev de verdade”.
Essa sensação apareceu com força em um relato publicado no Hacker News. O autor, um desenvolvedor de 33 anos da Coreia do Sul, contou que já entregou software para cerca de 40 empresas e mais de 380 clientes individuais, mas grande parte desse trabalho foi no modelo “entrega e vai embora”: adaptar template, repetir padrões, subir projeto e partir para o próximo. Segundo ele, isso o deixou com pouca vivência de produto, manutenção contínua e evolução de software no longo prazo.
O ponto pega porque muita gente no Brasil se reconhece nisso. Não por falta de esforço. Pelo contrário. A rotina de freela, software sob demanda e projeto curto costuma ensinar velocidade, improviso e sobrevivência. O problema é que quase sempre ela ensina menos sobre ownership, operação e decisão de produto.
Quando a carreira gira em torno de entregar e sumir
No post original, o desenvolvedor descreve uma carreira construída em cima de software industrial, aplicações desktop em WinForms e WPF, projetos pequenos de web e muito serviço B2B prático. Tudo isso tem valor real. Só que existe uma diferença grande entre entregar um sistema funcional e participar da vida inteira de um produto.
No modelo de entrega, o foco costuma ser esse:
- fechar escopo, prazo e orçamento;
- resolver o que o cliente pediu;
- fazer o sistema funcionar o bastante para a entrega;
- passar para o próximo projeto o mais rápido possível.
No modelo de produto, a conversa muda. Não basta entregar. É preciso conviver com as consequências técnicas e de negócio daquilo que foi entregue: deploy, feedback de usuário, backlog real, monitoramento, custo, bug recorrente, refatoração, priorização e evolução.
É justamente aí que muita gente percebe um buraco na própria formação. A pessoa sabe programar, sabe se virar, sabe entregar. Mas quase não teve chance de ver o que acontece depois que o software cai no mundo real.
O que muda quando o jogo deixa de ser projeto e vira produto
Esse relato bate com uma discussão maior do mercado. Em um artigo da TechTarget sobre product mindset, a diferença central é simples: projeto é guiado por entregáveis; produto é guiado por resultado e evolução contínua.
Na prática, isso muda várias coisas ao mesmo tempo:
- o sucesso deixa de ser “entreguei no prazo” e passa a ser “o produto melhorou de verdade”;
- o código deixa de ser fim e vira parte de um sistema vivo;
- feedback de usuário, operação e manutenção entram na conta desde o começo;
- quem constrói precisa entender melhor o impacto do que coloca em produção.
Outro texto, da Equal Experts, resume bem essa virada com a lógica do you build it, you run it: quem constrói também precisa sentir o peso da operação, dos incidentes, da qualidade e do contato com a realidade do usuário. É isso que transforma entrega em responsabilidade de verdade.
Para quem veio de freela ou software sob demanda, essa pode ser a virada mais difícil. Não porque falte talento, mas porque o ambiente anterior quase nunca cobrava isso.
O relato também derruba uma ilusão comum sobre senioridade
Tem outro detalhe forte nessa história: o autor diz que passou anos trabalhando longe dos grandes polos de tecnologia, sem muita gente ao redor para revisar código, discutir arquitetura ou trocar repertório. Isso ajuda a explicar por que tanta gente com anos de estrada continua se sentindo atrasada.
Não é só uma questão de tempo de carreira. É contexto. É tipo de problema. É o quanto você foi exposto a manutenção, revisão, versionamento, operação e decisão de produto.
Um texto da GeekHunter toca num ponto parecido ao dizer que senioridade não deveria ser medida só por tempo, mas por adaptação e atualização real. Em outras palavras: repetir o mesmo tipo de entrega por muitos anos pode dar experiência, mas não necessariamente amplia o repertório que separa um executor forte de alguém que assume produto de ponta a ponta.
Como sair desse lugar sem romantizar a virada
A parte boa do caso é que ele também mostra uma direção prática. O desenvolvedor conta que começou a mexer no próprio stack, trocar SVN por Git, montar site bilíngue e buscar contato com comunidades e fontes mais fortes de engenharia. É um movimento pequeno na superfície, mas grande na cabeça: parar de estudar só para a próxima entrega e começar a estudar para operar software melhor.
Para quem está num cenário parecido, a transição costuma ficar mais concreta quando você faz quatro movimentos:
- Entrar em ambientes com feedback técnico real. Código sem revisão quase sempre engana para cima ou para baixo.
- Buscar software vivo. Projeto sem manutenção ensina menos sobre custo de decisão técnica.
- Aprender ferramentas e fluxo de time moderno. Git, observabilidade, backlog, deploy, incidentes e documentação pesam mais do que modinha de framework.
- Trocar o critério de orgulho. Em vez de contar quantas entregas fez, olhar quanto do que você construiu continuou saudável depois.
Isso não significa desmerecer freela, software local ou projeto sob demanda. Muita gente constrói carreira e paga as contas nisso. O que o relato escancara é outra coisa: dá para trabalhar muito, entregar para dezenas de clientes e ainda assim sentir falta da camada de engenharia que aparece quando o software precisa sobreviver.
O ponto mais honesto desse caso
Talvez a parte mais forte do texto original seja justamente a honestidade. Em vez de vender imagem de “pleno domínio”, o autor admite que as ferramentas de IA reacenderam o entusiasmo, mas também mostraram o tamanho do que ainda faltava aprender. É desconfortável, só que útil.
Porque a pergunta certa não é “sou dev de verdade ou não?”. A pergunta melhor é: eu só entrego software ou já consigo construir e sustentar produto?
Essa diferença parece semântica até o dia em que você precisa lidar com usuário real, feedback real, manutenção real e trade-off real. Aí ela vira carreira.
