Como contratar um desenvolvedor — A teoria da laranja

Existem momentos que nos remetem à fatos do passado. Hoje, foi um desses dias e acredito que é o momento de compartilhar com vocês…

Em uma de minhas aulas do curso superior, um professor, me contou uma história que me marcou. Era uma aula de Cobol para Mainframe, e Deus sabe o quanto eu detestava aquela linguagem e o fato de poder compilar apenas uma vez ao dia. Sim, garotos, um dia isto foi realidade…

Porém, a partir daquela história, eu passei a dar mais importância aquelas aulas, passei a repensar minhas atitudes, passei a tratar cada linha de código que escrevia, como uma obra de arte, como um trabalho delicado de engenharia e a colocar uma marca, algo que dissesse quem escrevera aquela código, e a partir de então, era como se o código tivesse vida…

A história começa com um anuncio de uma vaga de desenvolvedor…

Não havia nada de importante na vaga, afinal estávamos nos anos 90, era um simples anuncio curto de jornal que tinha apenas uma ressalva, um comentário que dizia: "Apenas se candidate se você realmente é um desenvolvedor".

O processo se desenrolava como de costume, sem nenhuma diferença do que ocorre nos dias atuais e muitos de nós passamos quando estamos procurando uma nova oportunidade.

A diferença toda estava na entrevista, esta sim, era muito diferente. Digamos que quando ouvi pela primeira vez, achei bem estranha, até entende-la!

A empresa ficava num local muito bonito, bem cuidado e arborizado. Próximo a sala de entrevista havia um pequeno lago, não muito grande, raso e com alguns peixes exóticos.

Próximo a ele, havia algumas árvores frutíferas e algumas delas carregadas de frutos, fáceis de se identificar.

A sala de entrevista era à margem deste lago, a entrevista desenrolava-se normalmente, onde o gerente da área tirava algumas duvidas do currículo, validava algumas respostas a certas situações, avaliava se o candidato estava adequado a cultura da empresa e seus valores se alinhavam com a empresa, com o time, tudo dentro do clássico roteiro.

Porém, uma pergunta ao final da entrevista, fazia toda a diferença:

Gerente: "O que você vê no meio do lago?"

Candidato: "Eu vejo uma laranja"

O candidato saia e o gerente anotava na sua ficha, desqualificado.

Todas as entrevistas seguiram rigorosamente da mesma forma. Uma após a outra, o gerente anotava o mesmo resultado — desqualificado.

Até que um dos candidatos teve um comportamento diferente, em vez de responder diretamente, ele pediu licença, chegou mais próximo do lago, com algum auxilio, trouxe o fruto para perto. Avaliou o cheiro, textura, cortou o fruto, voltou a sala de entrevista e respondeu:

Candidato: "Decididamente, isto é uma laranja lima"

E o gerente retornou:

Gerente: “A vaga é sua, quando pode começar?”

Pra ser bem sincero, no início não entendi a moral desta história, afinal, tinha 17 anos e ainda não havia trabalhado, mas veio a luz, com uma explicação do mestre.

Mais que saber tudo sobre arquitetura de software, engenharia de software, qualidade de software, linguagens, teoria dos computadores, algoritmos, técnicas avançadas de otimização… O que realmente importa é saber se o seu software, faz aquilo que realmente diz que ele faz e quando diz que não faz, você responder somente após ter investigado profundamente, cada linha de seu código.

Um bug, deixa de ser um bug, somente depois de ser provado, isto nos remete a origem, em software, da própria palavra bug. Na época, o software não tinha um erro de código, porém, ainda assim por conta de um inseto — "bug", não funcionava corretamente.

Depois desta história, passei a tratar o código como uma obra de arte, a colocar marcadores para que pudesse ter certeza que o código era meu e não havia sido alterado, passei a entender que tão importante como saber escrever um excelente algoritmo, era ter o domínio sobre o seu propósito e a sua relação dentro de toda uma cadeia de valor.

E você Developer usa marcadores de código? E de que forma trata um bug? Para você é somente uma laranja?

Bom final de semana!