Posts Tagged Humor

E se motoristas fossem contratados da mesma maneira que programadores?

E se motoristas fossem contratados da mesma maneira que programadores?

Cargo: Motorista.

Exigências do trabalho: Competência profissional em condução de veículos leves como carros e pesados como ônibus e caminhões, ônibus articulados, bondes, metrô, tratores, escavadoras e pás carregadoras, e tanques pesados atualmente em uso pelos países da OTAN.

Habilidades em Rali e de condução extremas são obrigatórios!
Experiência na Fórmula-1 é um diferencial.

Conhecimento e experiência em reparação de motores de pistão e rotor, transmissões automáticas e manuais, sistemas de ignição, computador de bordo, ABS, ABD, GPS e sistemas de áudio automotivo dos fabricantes conhecidos mundialmente – obrigatória!

Experiência em tarefas de pintura e funilaria de automóveis é um diferencial.

Os candidatos devem ser certificados pela BMW, General Motors e Bosch, mas não por mais de dois anos.

Compensação: R$ 15 – R$ 20/hora, dependendo do resultado da entrevista.

Exigências da instrução: Bacharel em Engenharia Mecânica

Nenhum comentário.

Quantos programadores são necessários pra trocar uma lâmpada?

Resposta curta: Nenhum, trocar lampadas é um problema de hardware.

Respostas longas…

Programadores da Microsoft:
Nenhum. Se a lâmpada estiver queimada, a microsoft vai declarar isso um novo padrão.

Programadores do Google:
Nenhum, porque acreditam que lâmpada é coisa do passado. E desenvolvem o GSunLight.

Programadores C:
6. 1 para trocá-la e 5 para seis mais tarde entenderem como ele fez isso.

Programadores Java:
1 para fazer o levantamento de requisitos, 1 para fazer os diagramas, 1 para instalar o TomCat, 1 para definir as classes, 1 para analisar as classes criadas, 1 para declarar os objetos, 1 para documentar o sistema, 1 para inserir a lâmpada na máquina virtual.

Programadores Clipper:
Só um, mas ninguém o encontra.

Programadores Python:
Já trocou?

Programadores PHP:
Só um, desde que haja alguém para desenhar o layout da lâmpada.

Programadores Delphi:
Estão procurando os módulos de troca de lâmpada nos fórums.

Programadores Whitespace:
” ”

Programadores Ruby:
Só um, e garante que só ele sabe fazer isso da melhor forma.

Nenhum comentário.

Corrida dos 16 bits

O que aconteceria quando os personagens mais famosos dos jogos mais queridos da época mais saudosista dos games disputassem uma corrida? Neste pequeno vídeo, inúmeros personagens da era 16-bits aparecem numa suada corrida para ver quem vence. O maior desafio mesmo é você, espectador, reconhecer e nomear todos os personagens!

Confira o vídeo, que pode te surpreender no final!

Fonte: Jovem Nerd

,

Nenhum comentário.

Remake de Doom com uma nova arma: Vuvuzela

Creio que 95% dos leitores deste blog já jogaram Doom (pelo menos os que tiverem mais do que uns 22 anos de idade). Então curtam esse remake com uma nova “super arma”…

,

Nenhum comentário.

XGH – eXtreme Go Horse Process

Acabei de ler e preciso compartilhar, rs… Um concorrente forte para as metodologias ágeis de desenvolvimento! Afinal, humor sempre faz bem…

eXtreme Go Horse (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 (Vide Axioma 14).

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 reativo.

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 malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

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 (Vide Axioma 8).

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 (Vide Axioma 4).

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 (Vide Axioma 10).

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 *****. 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 (Vide Axioma 1).

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 (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), 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á fudido. O XGH não permite refactoring (vide axioma 10), 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 (Vide Axioma 10). 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 Doc 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! Nesse caso, utilize o Axioma 8.

Site oficial: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

1 Comentário

8 perfis profissionais da área de TI

Um artigo bem divertido que lí hoje na ComputerWorld sobre perfis profissionais da área de TI. Vale a pena ler! Identifique seus companheiros das baias ao lado, rs…

Confira uma visão divertida dos profissionais que devem sentar ao seu lado e que compõem o departamento de tecnologia da sua empresa.

O mercado de trabalho geralmente tem três tipos de personalidades: Tipo A, Tipo B e Tipo TI (Tecnologia da Informação). Este bem afastado do resto. O Computerworld americano identificou oito tipos clássicos de personalidades que são encontrados na maioria dos departamentos TI.

Muitas deles – quase todas – estão em algum cubículo próximo ao seu local de trabalho neste momento. Considere isso como um guia para a “fauna e a flora” da sua vida de trabalho.

Para ler o artigo na íntegra, clique aqui!

,

Nenhum comentário.