hotfix/self-sabotage-v1
Sabe aquele if os.getEnv(environment) == "dev" { cleanDb() }? Pois é… parece inocente, mas na prática é só um DROP DATABASE disfarçado de ternário feliz. É o clássico “não vai dar nada” que todo dev já disse antes de um git push origin master numa sexta-feira às 17h59.
Sanity check, o cinto de segurança do dev
Esses ifzinhos são tipo airbag: a gente coloca achando que nunca vai precisar, mas quando precisa, é porque já bateu de frente com o caminhão chamado produção. E ainda assim, o airbag pode ser só um console.log("não era pra rodar aqui") — porque claro, logs salvam vidas (ou não).
O eterno autoengano dev
Você matou a charada com a citação do Feynman: nós somos mestres em auto-sabotar. A diferença é que, em vez de partículas subatômicas, nossas experiências envolvem connection strings que deveriam estar em secrets.dev.json mas misteriosamente foram parar no docker-compose.override.yml de prod.
No fundo, todo dev é um estagiário disfarçado de sênior tentando convencer a si mesmo que sabe o que está fazendo.
História do colega que limpou 200 cadastros
Essa aí é digna de RFC: “User Acceptance Test as a Service (UATaaS)”. O sistema passou no teste, mas o banco não sobreviveu. Ainda bem que eram só 200 usuários — imagina se fosse aquele cliente enterprise que já tinha importado o Excel com 18 mil linhas e CPF duplicado.
Minha interpretação filosófico-dev
No fim das contas, programar é isso: criar mecanismos não pra impedir a cagada, mas pra reduzir o impacto quando ela inevitavelmente acontecer. É assumir que somos falhos, que o código mente, que o Docker engana e que o futuro “eu” é sempre o pior dev da equipe.
Pull request de vida
A lição é simples:
desconfie do seu código como desconfia de código copiado do Stack Overflow de 2012,
trate a prod como se fosse um servidor nuclear: com luvas, checklists e medo,
e nunca confie em você mesmo sem um sanity check.
Porque, no final, todo dev já escreveu seu próprio malware acidental — só muda o dia em que ele vai rodar.
hotfix/self-sabotage-v1
Sabe aquele if os.getEnv(environment) == "dev" { cleanDb() }? Pois é… parece inocente, mas na prática é só um DROP DATABASE disfarçado de ternário feliz. É o clássico “não vai dar nada” que todo dev já disse antes de um git push origin master numa sexta-feira às 17h59.
Sanity check, o cinto de segurança do dev
Esses ifzinhos são tipo airbag: a gente coloca achando que nunca vai precisar, mas quando precisa, é porque já bateu de frente com o caminhão chamado produção. E ainda assim, o airbag pode ser só um console.log("não era pra rodar aqui") — porque claro, logs salvam vidas (ou não).
O eterno autoengano dev
Você matou a charada com a citação do Feynman: nós somos mestres em auto-sabotar. A diferença é que, em vez de partículas subatômicas, nossas experiências envolvem connection strings que deveriam estar em secrets.dev.json mas misteriosamente foram parar no docker-compose.override.yml de prod.
No fundo, todo dev é um estagiário disfarçado de sênior tentando convencer a si mesmo que sabe o que está fazendo.
História do colega que limpou 200 cadastros
Essa aí é digna de RFC: “User Acceptance Test as a Service (UATaaS)”. O sistema passou no teste, mas o banco não sobreviveu. Ainda bem que eram só 200 usuários — imagina se fosse aquele cliente enterprise que já tinha importado o Excel com 18 mil linhas e CPF duplicado.
Minha interpretação filosófico-dev
No fim das contas, programar é isso: criar mecanismos não pra impedir a cagada, mas pra reduzir o impacto quando ela inevitavelmente acontecer. É assumir que somos falhos, que o código mente, que o Docker engana e que o futuro “eu” é sempre o pior dev da equipe.
Pull request de vida
A lição é simples:
desconfie do seu código como desconfia de código copiado do Stack Overflow de 2012,
trate a prod como se fosse um servidor nuclear: com luvas, checklists e medo,
e nunca confie em você mesmo sem um sanity check.
Porque, no final, todo dev já escreveu seu próprio malware acidental — só muda o dia em que ele vai rodar.