Pular para o conteúdo principal

6 publicações com a etiqueta "Dev Cansado"

Cronicas do cansaco profissional

Ver todas as etiquetas

O Projeto Legado do Zero

· 3 min para ler
Dev Cansado
Dev Full Stack Especialista XGH

Ou: quando o passado é copiado sem ser entendido.

O projeto é novo.

Novo de verdade.
Repositório zerado.
Stack atual.
Nome bonito.
Arquitetura “repensada”.

Nunca foi pra produção.

E mesmo assim, alguém solta:

“Isso aqui já virou legado.”

E virou mesmo.


📄 O detalhe que ninguém achou importante

Não tinha documentação.

Nenhuma.

Nem do sistema antigo.
Nem do domínio.
Nem das regras.
Nem dos fluxos.
Nem das decisões.

Só tinha código.

Código velho.
Confuso.
Acoplado.
Cheio de exceções históricas.

E alguém decidiu:

“É só copiar o que funciona.”


🧠 O dev e o voo às cegas

O dev não conhecia o domínio.
Não sabia o porquê das regras.
Não sabia o que era exceção.
Não sabia o que era gambiarra.
Não sabia o que era requisito real.

Mas tinha prazo.

Então fez o que todo mundo faz nessas condições:

👉 copiou o legado
👉 adaptou o nome das classes
👉 removeu o que parecia estranho
👉 manteve o que dava medo de mexer

E torceu.


🧩 Copy-paste não é reescrita

O problema é que:

  • copiar código não transfere entendimento
  • copiar regra não transfere contexto
  • copiar gambiarra não transfere motivo

O legado antigo tinha problemas.
Mas tinha história.

O novo projeto só herdou:

  • acoplamento
  • confusão
  • regras obscuras
  • comportamento inesperado

Sem saber por quê.


💥 A surpresa que ninguém esperava (mas todo mundo devia)

Depois de algumas sprints:

  • regra conflitante
  • bug inexplicável
  • fluxo impossível de testar
  • código que ninguém confia
  • medo de alterar qualquer coisa

E alguém percebe:

“A gente não entende mais esse sistema.”

Parabéns.
Você criou um legado.

Do zero.


🤡 O discurso padrão

A explicação oficial aparece rápido:

“A arquitetura não ficou boa.”
“Talvez a stack não tenha ajudado.”
“Acho que o design não foi bem pensado.”

Mentira.

O design não existiu.
O entendimento não existiu.
A base nunca existiu.

O projeto não falhou tecnicamente.
Ele nasceu sem chance.


♻️ Legado instantâneo™

Normalmente, um sistema vira legado depois de:

  • anos de mudanças
  • dezenas de devs
  • pressão de negócio
  • decisões contextuais

Aqui levou:

  • 2 sprints
  • 1 deadline
  • 0 documentação
  • muito copy-paste

Eficiência máxima.


😬 O impacto no time

Pro dev, fica assim:

  • sensação de incompetência sem culpa
  • medo de tocar no código
  • desmotivação precoce
  • dúvida constante
  • retrabalho iminente

E a frase que dói mais:

“Você que fez, deveria saber.”

Não deveria.

Nunca deram condição.


🚨 A verdade que ninguém gosta

Projeto novo que já nasce legado
não é problema de stack.
Não é problema de linguagem.
Não é problema de arquitetura.

É problema de:

  • ausência de conhecimento
  • falta de documentação
  • pressão sem entendimento
  • herança cega do passado

Copiar o legado sem entendê-lo
é só propagar o erro em versão nova.


🪦 Moral da história

Quando ninguém sabe como o sistema funciona,
reescrever não resolve.

Sem domínio,
sem documentação,
sem decisão consciente…

o projeto novo
vira legado
antes mesmo de nascer.

E o próximo,
se seguir o mesmo caminho,
vai morrer ainda mais rápido.

A vida fácil do Dev Tercerizado.

· 3 min para ler
Dev Cansado
Dev Full Stack Especialista XGH

A Consultoria Pede Paciência.

O cliente é problemático.

Sempre foi.

Processo inexistente.
Escopo mutante.
Prazo impossível.
Cobrança agressiva.
Zero responsabilidade interna.

Mas existe uma regra implícita:

👉 quem apanha são os devs.
👉 quem pede calma é a consultoria.


🧨 O cliente: sempre no modo ataque

No dia a dia, o clima é simples:

  • cobrança pública
  • ironia em call
  • pressão desproporcional
  • ameaça velada
  • urgência constante
  • erro zero (só pros outros)

Qualquer atraso vira:

“Isso é inaceitável.”
“Estamos pagando caro.”
“O time não está entregando.”

Mesmo quando:

  • requisito muda toda semana
  • decisão nunca vem
  • aprovação demora dias
  • ambiente não funciona
  • acesso falta
  • dependência externa quebra

Mas nada disso importa.

O importante é ter alguém pra fritar.


🧍‍♂️ O alvo preferido: dev terceiro

Nunca é o time interno.
Nunca é a gestão do cliente.
Nunca é o processo.

É sempre:

  • o dev da consultoria
  • que não decide
  • não define prazo
  • não escolhe escopo
  • não controla dependência

Mas responde por tudo.

É o bode expiatório perfeito.


🤝 A consultoria entra em cena

E aí vem a parte mais surreal.

Depois de uma call humilhante,
de cobrança pública,
de dedo apontado…

A consultoria chama o dev no privado:

“Calma…
Tenha paciência…
O cliente está se organizando…
Isso vai melhorar.”

Sempre vai melhorar.

Só nunca melhora.


🧠 A narrativa oficial

A consultoria repete como mantra:

  • “É fase de adaptação”
  • “O cliente está sob pressão”
  • “Precisamos ser parceiros”
  • “Não leva pro pessoal”
  • “É só um momento difícil”

Enquanto isso:

  • o cliente segue desorganizado
  • a cobrança aumenta
  • a agressividade cresce
  • o desgaste acumula

Mas o pedido é sempre o mesmo:

“Tenha paciência.”


🔥 O dia a dia real (fora do discurso)

Enquanto a promessa de melhora nunca chega:

  • sprint vira caos
  • prioridade muda toda hora
  • dev apanha em reunião
  • erro vira espetáculo
  • acerto vira obrigação
  • burnout vira rotina

E quando o dev reclama, escuta:

“Você precisa ser mais resiliente.”

Resiliente a quê?
A desrespeito?


🤡 O paradoxo da consultoria

A consultoria:

  • vende “parceria estratégica”
  • promete governança
  • fala em maturidade
  • cobra postura profissional

Mas na prática:

  • não protege o time
  • não confronta o cliente
  • não impõe limite
  • não assume risco
  • não compra a briga

Quem segura a pancada?

O dev.

Sempre o dev.


🚨 A verdade que ninguém fala

Cliente problemático não se organiza sozinho.
Caos não melhora com paciência.
Abuso não diminui com silêncio.

E quando:

  • só o dev é cobrado
  • só o dev é exposto
  • só o dev é pressionado

Isso não é parceria.

É terceirização de sofrimento.


🪦 Moral da história

Quando o cliente quer fritar os devs
e a consultoria só pede paciência…

👉 o problema não é técnico
👉 não é de processo
👉 não é de comunicação

É falta de coragem.

Coragem de dizer “não”.
Coragem de impor limite.
Coragem de proteger o time.

Sem isso,
o cliente continua batendo,
a consultoria continua prometendo,
e o dev continua apanhando
à margem da sociedade corporativa.

As Bigtechs e as Pigtechs

· 2 min para ler
Dev Cansado
Dev Full Stack Especialista XGH

BigTechs X PigTechs.

Nem toda empresa grande é uma BigTech.

Algumas só cresceram errado.

E é aí que entram as PigTechs.


🏢 BigTechs

BigTechs são empresas grandes com complexidade real.

Elas têm:

  • escala de verdade 
  • problemas difíceis 
  • sistemas distribuídos reais 
  • engenharia levada a sério 
  • decisões baseadas em dados 
  • processos que existem por um motivo

Nada é simples. 
Mas quase tudo faz sentido.

Quando algo é burocrático, 
normalmente é porque alguém já se machucou antes.


🐷 PigTechs

PigTechs também são grandes.

Mas só no tamanho.

São empresas que:

  • cresceram rápido 
  • sem base técnica 
  • sem cultura 
  • sem engenharia 
  • sem aprendizado

Elas não escalam arquitetura. 
Elas empilham coisa.

E chamam isso de inovação.


🧠 A diferença não está na tecnologia

PigTechs adoram falar de:

  • microservices 
  • cloud 
  • agile 
  • kubernetes 
  • clean architecture 
  • DDD 
  • inovação 
  • transformação digital

Mas só falam.

Na prática:

  • microservice é Web API gigante 
  • cloud é VM cara 
  • agile é reunião 
  • kubernetes é slide 
  • clean architecture é pasta vazia 
  • DDD é palestra 
  • inovação é mudar nome de cargo

🧩 Como reconhecer uma PigTech rapidamente

Alguns sinais clássicos:

  • tudo é urgente 
  • ninguém decide nada 
  • todo mundo manda 
  • prioridade muda todo dia 
  • prazo é dado antes de estimar 
  • culpa sempre cai no dev 
  • ferramenta vira solução mágica 
  • processo existe só no papel

E, principalmente:

ninguém assume responsabilidade técnica.


🔥 PigTechs adoram teatro

  • Agile Theater™ 
  • Arquitetura PowerPoint™ 
  • Scrum de Cerimônia™ 
  • Jira como solução universal™ 
  • Microservice de mentira™

Tudo é performático.

Tudo é discurso.

Pouca coisa é real.


😬 O impacto no dev

Trabalhar numa PigTech causa:

  • frustração constante 
  • síndrome do impostor (sem motivo) 
  • cansaço mental 
  • perda de referência técnica 
  • depressão profissional 
  • vontade de largar a área 
  • ou virar o “dev chato” que reclama de tudo

E o pior:

a PigTech faz você achar que o problema é você.

Não é.


🎯 BigTechs doem. PigTechs apodrecem.

BigTechs são difíceis.

  • código complexo 
  • sistemas enormes 
  • decisões pesadas 
  • trade-offs reais

Mas você aprende.

PigTechs não são difíceis. 
Elas são confusas.

E confusão constante corrói.


🪦 Moral da história

Nem toda empresa grande é BigTech.

Algumas são só PigTechs:

  • grandes 
  • barulhentas 
  • desorganizadas 
  • vaidosas 
  • e convencidas de que são modernas

E enquanto BigTechs tentam resolver problemas difíceis, 
PigTechs seguem:

criando caos, 
culpando o time, 
e chamando isso de crescimento.