Extreme Go Horse - XGH

Como identificar um verdadeiro Extreme Go Horse, vulgo XGH!

Símbolo conhecido dos XGH. Animal venerado por eles!

   Caros leitores e visitantes do blog Nerds Attack!. Vou lhes falar agora sobre um assunto que existe em todo lugar. Na verdade, não exatamente sobre um assunto, mas sim sobre um tipo de pessoa, um tipo de profissional. O Extreme Go Horse, conhecido mais popularmente como XGH. O que seria este profissional? Como identificá-lo? Não se preocupe! Vou mostrar abaixo o que é um XGH e como fazer para o identificar. Se você é um XGH, não continue lendo esta matéria.

   O XGH é aquele profissional existente em toda a empresa que ninguém que trabalha com ele sabe como ele ainda está ali. Normalmente ganha mais do que você, porque teoricamente ele resolve os problemas e você não. Abaixo você saberá o porquê.
   O profissional XGH é aquele cara que utiliza gambiarras. Mas aí você me fala: "Poxa, todo mundo já usou uma gambiarrazinha uma vez na vida né!?". Sim, respondo eu. Sei muito bem que todos já usaram uma gambiarra pelo menos uma vez na vida. Eu usei e vez por outra tenho que fazer uso da mesma, raramente. A questão é que o XGH não usa gambiarra. Ele É a gambiarra. Todo o trabalho dele é baseado em gambiarras e tudo que ele utiliza para fazer seu trabalho, da forma que só ele consegue, é gambiarra. E depois que ele termina o que tinha pra fazer, tendo cagado todo o resto, pra quem sobra arrumar o que ele cagou? Você! Sim, você arrumará tudo que ele fez de errado. E de quem vai ser a culpa quando um trabalho não for entregue no prazo? Sua culpa! Porque? Leia abaixo as características do XGH e entenda o motivo de eu ter falado que a culpa é sua!

Como identificar um XGH

1. Pensou, não é XGH. XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção. A única opção é a mais rápida.
2. Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida. XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece.
3. Quanto mais XGH você faz, mais precisará fazer. Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.
4. XGH é totalmente relativo. Os erros só existem quando aparecem.
5. XGH vale tudo, só não vale dar o toba. Resolveu o problema? Compilou? Commit e era isso.
6. Commit sempre antes de update. Se der merda, a sua parte estará sempre correta e seus colegas que se $%&#@...
7. XGH não tem prazo. Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script suspeito).
8. Esteja preparado para pular fora quando o barco começar a afundar…ou coloque a culpa em alguém, qualquer coisa do tipo. Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.
9. Seja autêntico, XGH não respeita padrões. Escreva o código como você bem entender, se resolver o problema, commit e era isso.
10. Não existe refactoring, apenas rework. Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar.
11. XGH é totalmente anárquico. A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo.
12. Se iluda sempre com promessas de melhorias. Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito.
13. XGH é absoluto, não se prende à coisas relativas. Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!
14. XGH é atemporal. Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.
15. XGH nem sempre é POG. Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina.
16. Não tente remar contra a maré. Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.
17. O XGH não é perigoso até surgir um pouco de ordem. Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH, é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda. Não tente gerenciar o XGH, ele é auto suficiente, assim como o caos.
18. O XGH é seu brother, mas é vingativo. Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará ferrado. O XGH não permite refactoring e seu novo sistema cheio de "frescurites" entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.
19. Se tiver funcionando, não rela a mão. Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe. Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.
20. Teste é para os fracos. Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.
21. Acostume-se ao sentimento de fracasso iminente. O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!
22. O problema só é seu quando seu nome está no nome da classe. Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar!

   Pois é senhores leitores, é exatamente isso! Sei que vocês lembraram de alguém na hora que estavam lendo as características de um XGH, provavelmente já usou uma delas em seu trabalho, mas nunca todas. Se identificou muitos destes pontos com coisas que costuma fazer, preocupe-se: Você é um XGH!
   Compartilhe e divulgue essa matéria para que possa fazer com que seus conhecidos tomem ciência disso e quem sabe se dêem conta do que estão fazendo...Não. XGH sabe que é XGH e não quer deixar de ser.
   Continuem acompanhando o blog, assinando feeds e o canal do mesmo, bem como adicionando a página do blog em seu stream. Mantenha-se atualizado tanto com as novidades tecnológicas bem como também com as notícias de descontração, como esta.

Nerds Attack!