Manual de Sobrevivência do Dev: Maio de 2025
Este não é um conteúdo técnico. Mas talvez seja o mais realista que você vai ler hoje sobre ser dev.
⚠️ Nota importante antes que alguém leve pro coração:
Este Manual de Sobrevivência do Dev em 2025 é uma obra de ficção tragicômica. Qualquer semelhança com a sua squad, seu PO, seu código legado ou seu deploy na sexta-feira… não é mera coincidência … é trauma compartilhado mesmo.
O objetivo aqui não é criticar, mas sim rir das dores reais que todo dev já enfrentou ou ainda vai enfrentar. Porque, convenhamos: se a gente não rir, a gente chora… e ainda tem que corrigir bug com o olho cheio de lágrima.
Então respira e bora sorrir um pouco.
Afinal, rir das nossas desgraças técnicas é o primeiro passo pra manter a sanidade no ambiente de produção. 😅
Com carinho… Um dev que também já quis jogar o notebook pela janela 😂
(100% baseado em histórias reais. As lágrimas são verdadeiras.)
🔥 Capítulo 1: Sprint não é corrida…
“A sprint acaba sexta, mas a depressão continua no backlog.”
Se a planning começar com “gente, essa sprint tá tranquila”, fuja.
Quando alguém diz “só falta subir em produção”, pode saber: vai cair.
Entenda: o ponto de história é uma unidade de sofrimento, não de tempo.
🐛 Capítulo 2: Bugs e outras criaturas mitológicas
“Se o bug sumiu quando alguém chegou perto, é porque ele tem vergonha.”
Nunca diga “agora vai” perto de um push. Ele escuta. Ele sabota.
Se o sistema só quebra em produção, parabéns: você desbloqueou o modo difícil da programação. 😬
A stack trace te odeia. Ela te mostra tudo, menos onde está o erro.
📞 Capítulo 3: Reuniões que poderiam ser uma mensagem no Slack
“Daily é aquele momento em que fingimos que está tudo sob controle.”
Reunião de alinhamento = ninguém entende nada, mas todo mundo finge que entendeu.
“Tem um minutinho?” = alerta vermelho, prepare-se emocionalmente.
A produtividade do dev é inversamente proporcional à quantidade de reuniões. Ou seja… a sprint tá andando, mas só na conversa
“Alguém quer compartilhar a tela?” — momento em que 7 devs desaparecem misteriosamente da call.
A regra é clara: quanto maior o número de pessoas na call, menor a chance de sair algo útil.
👻 Capítulo 4: O sistema legado e seus fantasmas
“Ninguém sabe quem escreveu esse código. O Git diz que fui eu. Eu nego.”
Nunca diga “só vou dar uma olhadinha nesse serviço antigo”. Ele vai te puxar.
O código roda em produção desde 2014. Não encosta. Repito: NÃO ENCOSTA.
Tem função com 400 linhas? Sim. Tem teste explicando? Claro que não.
“Refatora aí rapidinho.” – já atualiza seu currículo junto.
Quando alguém fala ‘vamos reescrever do zero’, um analista de sistemas chora em posição fetal.
🤖 Capítulo 5: A IA escreve código… e você paga o pato
“A IA gerou 90% do código. Os 10% que sobraram foram o meu colapso mental.”
Copilot é ótimo. Até você descobrir que ele te fez importar uma biblioteca que não existe desde 2021.
Nunca aceite um
for
da IA sem revisar. Ele pode estar tentando te sabotar discretamente.“Ajuda da IA” é o novo “peguei esse trecho no Stack Overflow sem ler”.
Nunca deixe a IA saber que você está com pressa. Ela sente o desespero e entrega um
null
disfarçado de solução.
🚒 Capítulo 6: Emergência nível produção
“Sou dev, mas nas horas vagas atuo como bombeiro de incidentes.”
Deploy na sexta? Só com carta assinada, testamento e bênção.
Nunca diga “estabilizou” até o monitor parar de piscar.
Compre uma sirene de bombeiro e coloque para tocar em toda war room. Ajuda a manter o clima honesto.
Nunca deixe seu PC saber que você está corrigindo um bug em produção. Ele vai travar por solidariedade.
Você não viveu um incidente de verdade até ouvir ‘tenta subir a versão anterior’ e perceber que ninguém sabe qual era.
A call de incidente começa com silêncio, passa pelo pânico, e termina com alguém dizendo ’acho que era caching’.
✌🏼 Capítulo 7: Cuide de você, porque ninguém mais vai…
Seu código merece qualidade. Você também. Dorme, criatura!
Seu corpo precisa de água, sono e silêncio. Nenhum deles está no seu backlog.
Terapia custa menos que antidepressivo. Vai por mim.
Não é normal achar que ‘resolver conflito de merge’ é mais fácil que conversar com alguém.
Se o seu smartwatch te parabenizou por ‘ficar sentado 12 horas seguidas’, talvez seja hora de repensar.
“Trabalhar com tecnologia” parecia legal… até você descobrir que seu cérebro nunca mais teria um minuto de descanso.
O DevOps pode escalar o sistema. Mas quem escala o dev quando ele quebra?
Se você está cansado logo depois da daily, não é coincidência. É o sistema nervoso tentando fugir.
🧯 Capítulo 8 – Cultura DevOps (também conhecida como “joga no colo do dev”)
“A cultura DevOps chegou. Só esqueceram de contratar o Ops.”
Hoje você é backend, amanhã você configura o pipeline do CI/CD.
O container subiu? Ótimo. Agora reza pra ele não afundar.
DevOps moderno: você programa, testa, monitora, deploya, resolve o incidente e ainda agradece pela oportunidade.
🤝 Capítulo 9 – Trabalhar em equipe (ou: sobrevivendo à squad)
“Trabalho em equipe é quando todos concordam que ninguém sabe o que tá acontecendo, mas seguimos juntos assim mesmo.”
Quando o PO fala, o dev escuta… mas consulta o Notion/Miro depois, só pra confirmar o que foi mesmo pedido.
Comunicação é chave. Pena que deixaram a chave no repositório errado.
A verdadeira sinergia acontece quando todo mundo resolve ignorar o bug e ir tomar café.
Aqui é colaboração real: um escreve código, o outro apaga incêndio, e o terceiro manda meme no Slack/Teams.
🧱 Capítulo 10 – Refatoração: o sonho que vive no backlog
“Refatorar? Sim. Quando? Quando der. Ou seja: nunca.”
O código tá pedindo socorro, mas a sprint só tem espaço pra entregar feature nova.
“Se funcionar, deixa assim.” — Frase que inicia a ruína de muitos sistemas.
Refatorar é como ir ao dentista: ninguém gosta, mas se não fizer, vai doer.
Refatoração é aquela promessa que toda squad faz com a mesma convicção de quem jura que segunda começa a dieta.
📦 Capítulo 11 – Documentação: o mundo mágico das promessas não cumpridas
“Aqui a gente entrega rápido… e documenta devagar.”
O sistema funciona? Sim. Alguém sabe como? Não.
Toda documentação tem três versões: a oficial, a desatualizada e o que está na cabeça do dev que saiu da empresa.
O verdadeiro desafio: manter documentação viva sem que ela vire ficção científica.
🧩 Capítulo 12 – Testes automatizados (ou a arte de evitar o caos)
“Se não quebrou nada, é porque ninguém testou direito.”
Cobertura de 100% nos testes? Só se for na apresentação pra diretoria.
Escrever teste é igual seguro de carro: você só valoriza quando dá ruim.
Teste que só passa na sua máquina não é teste, é amuleto.
Tem teste que só existe pra manter o pipeline feliz. O sistema, nem tanto.
TDD é sempre aplicado nas empresas e os programadores precisam saber aplicar essa técnica: Teste Depois do Deploy 🙃
💰 Capítulo 13 – Estimativas…
“O prazo é até sexta, mas a esperança já morreu na terça.”
‘3 pontos’ é o novo ‘vai demorar um mês, mas não quero assustar o PO’.
Estimar é simples: você multiplica seu palpite por dois e divide sua fé por três.
A melhor estimativa é: não sei, mas vou tentar fazer parecer que sei.
A única certeza na estimativa é que alguém vai cobrar como se fosse contrato assinado.
Quando o dev diz ‘é rápido’, o universo imediatamente começa a conspirar contra.
🧪 Capítulo 14 – QA e o talento de quebrar o que parecia funcionar
“Se passou pelo QA, é milagre. Se voltou do QA, é normal.”
O QA não dorme. Ele sonha com cenários de teste que ninguém imaginaria.
“Cliquei 17 vezes no botão em 2 segundos.” – ok, mas por quê?!
Aprenda com o QA: ele não testa para encontrar bugs. Ele testa pra provar que você errou.
Brincadeiras à parte, leve sempre a sério o trabalho do QA. 🫶
Eles são os guardiões silenciosos da sanidade do sistema — e muitas vezes, sofrem mais que os próprios devs.
Se possível, faça um PIX pra eles. Ou pelo menos um café. Eles merecem. ☕
🔐 Capítulo 15 – Segurança: o requisito invisível até o vazamento de dados
“O sistema não tem falhas de segurança. Ele só confia demais.”
Senha 123456 ainda é real em pleno 2025.
Cuidado com o SQL injection… e com o estagiário que tem acesso à produção.
A melhor política de segurança? Não deixar o sistema no ar.
⚽️ Capítulo 16 – Os POs: Meio de Campo, Tradutores e, às vezes, Camisa 10
“O PO é o cara que ouve o cliente dizendo ‘quero um botão mágico’ e traduz pra ‘vamos pensar numa solução viável’.”
O PO está no meio do fogo cruzado entre cliente, time de negócios e desenvolvedores — e sobrevive com café e planilhas.
Ele tenta proteger o time… até o cliente ligar no meio da daily perguntando “e aí, já tá pronto?”
O PO diz “prioridade alta”, o time escuta “caos absoluto”.
Requisito bem escrito é poesia. Pena que na prática chega como áudio de 2 minutos no WhatsApp, começando com ‘então… tava pensando aqui’.
Brincadeiras à parte, o PO é o responsável por dar sentido ao que a gente constrói.
Sem ele, o time fica perdido, o backlog vira zona e ninguém sabe pra onde o projeto tá indo. Dê valor ao seu PO, e se ele estiver sempre calmo, ele já desistiu por dentro.
📋 Capítulo final: O juramento do dev sobrevivente
Repita comigo:
“Prometo não fazer push direto na main, não aceitar PR de 500 arquivos e nunca mais dizer ‘só trocar o nome da variável’ como se fosse fácil.”
💬 Bônus: Frases que você vai ouvir (e fingir que não te afetam)
“Dá pra subir hoje ainda?”
“Mas rodou na minha máquina.”
“O cliente só pediu um botãozinho.”
“Isso é só front, né?”
“Tem como entregar mais rápido?”
Se você chegou até aqui, parabéns. Já está emocionalmente pronto pra encarar mais uma sprint cheia de tarefas mal estimadas, código legado com cheiro de mofo digital e reuniões que começam com “só pra alinhar rapidinho” e duram uma hora e meia.
Mas acima de tudo, lembre-se:
Este manual é uma expressão humorística, sem fins de crítica a ninguém.
Ele foi escrito para rir, aliviar o peso do dia a dia e relembrar — com um sorriso no rosto — os bons e maus momentos que todo mundo que trabalha com tecnologia já viveu (ou vai viver em breve).
Entre um bug e outro, entre um commit e um colapso, a gente segue.
Porque no fundo, apesar do caos, a gente ama essa loucura chamada desenvolvimento de software.
Agora vai lá… e não esquece: não faz deploy na sexta.