Bugman of the bugmen

Você nasceu dentro de uma cultura que tem seus costumes, sua religião e seus estilos de vida e trabalho, não importa o quanto você tentar negar, essa cultura não sai mais de você. 

Chega uma pessoa estranha, que nunca viu como a vida anda na sua cultura, nunca viu a bela que você e sua comunidade vê nela, e que tem uma visão superficial e rápida de como as coisas funcionam e como não funcionam dentro dela. Essa mesma pessoa começa a ditar que tudo que você faz, não tem sentido algum, por algum argumento racional(tm) ou por algum achado “cientifico”.

Qual a chance de você dar atenção a essa pessoa e abandonar parte da sua cultura? Quais as chances de algo que mudou por “um motivo racional” ao custo de abandonar uma tradição dar certo?

Esse é o exemplo de como “racionalizadores” de tecnologia pensam. Eles chegam em algum ambiente novo ditando tudo que está errado e como está errado. Ele não tem competência para arrumar nada e nem nunca correu riscos para fazer valer esse ponto de vista. Sempre aposta com a pele dos outros.

“C#? Não, agora precisamos usar a linguagem que saiu 1 ano atrás, vai servir melhor para a nosso uso”. Após falar isso e deixar algum projeto de POC mal feito e inacabado, o racionalizador vai resolver sair do ambiente (em parte porque ele sabe que está errado) e vai procurar uma outra vítima para a próxima tecnologia.

Para recomendar ou advogar por uma tecnologia, você precisa arriscar a própria pele.

Abriu uma empresa com essa tecnologia e ela gerou zilhões de reais?

Entregou algum projeto e tem uma sólida experiência com a tecnologia?

Se todas as respostas foram “não”, não adianta usar slides para tentar convencer outros desenvolvedores cairem no seu papo.

Nunca melhorias pontuais, sempre megalomanias.

O racionalizador nunca consegue apenas adicionar algo que vai melhorar a experiência e produtividade. Ele sempre pensa em substituir a forma como os outros já trabalham.

Nunca vai adicionar mais rastreabilidade em uma aplicação. Nunca vai adicionar métricas de uso que custam pouco mais ajudam no dia-a-dia. Nunca vai escrever cenários úteis de teste ou criar infraestrutura para rodar os mesmo. Não, isso (para ele) é trabalho para outro fulano, ele está ocupado demais fazendo desenvolvimento “de verdade”.