Armadilhas para desenvolvedores: a síndrome do contato alienígena

Nos últimos dias tenho pensado muito sobre os poucos casos que conheço nos quais o uso do Grails foi um fracasso. Nisto encontrei um elemento em comum que, acredito, pode ser aplicado à adoção de qualquer tecnologia. Chamo-o de síndrome do contato alienígena.

Analogia alienígena

Considero alienígena qualquer objeto com o qual me deparo e em um primeiro momento não encontro qualquer analogia que me ajude a compreendê-lo melhor. Nestes momentos, é como se aquele ser não se parecesse com nada que conheço. É portanto alienígena!

Este contato alienígena me oferece algumas alternativas:

  • Fico parado observando o objeto (desespero)
  • Inicio um processo de tentativa e erro manipulando o alienígena buscando algum comportamento que me pareça familiar (repare como  parece uma autópsia) (desespero++)
  • Busco mais informações sobre aquele elemento

As duas primeiras alternativas caracterizam a síndrome do contato alienígena, enquanto a terceira é a única via sensata que conheço. Há uma razão pela qual estou usando repetidas vezes a palavra analogia: esta é a base do aprendizado, que é o problema que estou tratando neste post.

Douglas Hofstadter

( sobre analogia e cognição, recomendo muito a vocês que assistam a esta palestra do Douglas Hofstadter. )

Reproduzindo em escritório a síndrome do contato alienígena

Você precisará dos seguintes igredientes:

  • Um profissional mediocre ou desmotivado (qualquer um com preguiça de aprender, ao menos pra mim, está afogado na mediocridade)
  • Uma tecnologia com a qual este profissional não possua contato anterior
  • Ausência de introdução a esta tecnologia

É um cenário muito comum em fábricas de software. Como há forte pressão para que o lucro seja o maior possível, muitas vezes o contratado não é o melhor, mas sim o mais barato e que “dará conta do recado”. Como em cima deste indivíduo é colocada a forte necessidade de que suas tarefas sejam entregues no prazo, este passa a ver seu trabalho não como algo do qual possa tirar proveito, mas sim como um problema desagradável que precisa ser resolvido rápido.

Como “agilidade” é tudo e nosso amigo medíocre não possui tempo ou motivação suficiente para pesquisar a respeito, o que lhe resta fazer? Resta buscar desesperadamente qualquer semelhança entre aquela tecnologia e qualquer outra com a qual já possua alguma experiência, por mais mínima que seja.

Um caso

Um bom exemplo deste comportamento está em uma frase que ouvi de um “profissional” ao se deparar com Grails. Segue a pérola:

“Sabe, como não vou ficar muito tempo neste projeto, vou programar em Grails exatamente como faço em Java, pois é o que conheço”

Óbviamente, o fruto do “trabalho” deste indivíduo foi retrabalho para os que precisaram depois arrumar a casa. Na realidade, o único fruto foi esta frase, cuja autópsia vou iniciar agora.

(…) como não vou ficar muito tempo no projeto (…)

Chamo este trecho de “imbecil detector”. Não é necessário me aprofundar muito nesta sub-pérola. Fica nítido que o sujeito não possui comprometimento com a sua equipe ou com a qualidade do próprio trabalho.

(…) vou programar em Grails exatamente como faço em Java, pois é o que conheço

Olha ai a síndrome explícita. Primeiro quando o sujeito diz “vou programar em Grails”, expõe a sua ignorância completa sobre o assunto. Não se programa em Grails, mas sim em Groovy, que é a linguagem na qual o framework se baseia.

Logo em seguida, a busca desesperada por uma analogia fácil: “como faço em Java, pois é o que conheço”. Neste caso, Groovy realmente é uma linguagem próxima do Java, mas não é Java. O resultado foi que Grails, apesar de ser o framework mais produtivo que conheço, neste caso foi um dos mais desastrosos que já vi.

Uma terapia

Faça uma introdução gentil à ferramenta

É errado enfiar tecnologia em um profissional que não a conhece (ei! seres humanos não possuem entrada pra cartuchos, sabia?). De fato: fazer isto é o mesmo que implorar pela mediocridade. O mais interessante é, em situações de contato alienígena, fornecer ao indivíduo um tempo (1 a 2 semanas) para que se adapte à tecnologia fora do ambiente de trabalho (de preferência, com algum material que possa ser usado como ponto de partida).

Por que fora do escritório? Para reduzir a pressão sobre o seu aprendizado. Nada pior que alguém o tempo inteiro lhe perguntando: “e ai? tá entendendo melhor agora?”. Além disto, é também um modo interessante de se medir o interesse do indivíduo pelo seu trabalho.

Se passado o período, o sujeito continua completamente cru no assunto, então é sinal de que não vale a pena o investimento naquela pessoa.

Comprometa-se com a tecnologia

Se a ferramenta X te oferece um modo de trabalhar parecido com o de Y que você já conhece, trabalhar com X como se fosse Y é burrice. A adoção de uma tecnologia envolve comprometimento.

Toda tecnologia envolve riscos, porém ter medo de usá-la plenamente é bobagem. Se você vai usar Grails ou Camel ou Erlang ou qualquer outra coisa no seu projeto, mergulhe de cabeça. Pense de acordo com o paradigma adotado pelo que você está usando, e não pelo que gostaria de usar.

Se mesmo assim você ainda estiver inseguro com relação à ferramenta adotada, acredito que auto crítica seja fundamental. Eu sempre me faço a seguinte pergunta:

Esta tecnologia foi desenvolvida por pessoas altamente capacitadas (muito provávelmente mais capacitadas que eu). Será que o problema está na ferramenta, comigo ou no fato de não ser a opção certa para o meu projeto?

Se acreditar que não é a escolha certa para o seu projeto, e esta não foi uma decisão sua, neste caso, o ideal é procurar o responsável por esta decisão. Normalmente (se esta pessoa não for debilóide) há uma excelente razão para que esta escolha tenha sido tomada.

Concluindo

Vejo duas causas possíveis para este “contato alienígena”.

  • Gerência mediocre: quando não são dadas ao indivíduo as condições necessárias para que este se adapte (e quem sabe, até venha a gostar) da tecnologia.
  • Profissional medíocre: quando o sujeito sequer pensa em pesquisar a respeito do assunto e já de cara inicia um processo de tentativa e erro buscando alguma forma barata de extrair suco de pedras

Resumindo: se não houver o esforço para que o aprendizado ocorra, sua realidade não será terrena jamais! :)

PS: normalmente a mediocridade é o resultado de você estar fora do seu lugar

14 thoughts on “Armadilhas para desenvolvedores: a síndrome do contato alienígena

  1. Nice! Belo texto, lembrei quando estava aprendendo, tentativa e erro, até encontrar o caminho das pedras da documentação do início ao fim… hehehe

    Responda

    admin Reply:

    Oi Humberto, fico feliz que tenha gostado. Valeu!

    Acho que todos nós já passamos por esta espécie de “contato alienígena” :)

    Responda

  2. Caramba, curti bastante. Quem nunca viu ou passou por uma situação em que é obrigado a usar uma linguagem totalmente desconhecida e sem preparo para isso =/.
    Pior é que se o cara quer fazer bem feito, reclamam que está demorando (não estava no planejamento que ele ainda teria que aprender a linguagem).

    Esses gerentes merecem um tapa na cabeça xD.

    []s

    Responda

    admin Reply:

    Oi Alex, legal que tenha gostado cara. Valeu.

    É uma faca de dois gumes. De um lado, há o profissional medíocre, do outro um gerente sem noção. :)

    Talvez nesta semana me aprofunde um pouco mais no assunto, vamos ver. :)

    Responda

  3. Excelente post, como sempre!

    Estou lendo um livro inglês sobre o Grails q é completíssimo! Como tenho pouco tempo para tal (tb estou aprendendo Android), minha meta é terminá-lo até o fim do mês, pois estou replicando o projeto do livro em meu ambiente de testes, para ter um melhor aprendizado. Para mim essa é a melhor forma de aprender!

    Confesso que a cada capítulo fico mais apaixonado pelo framework e pelo Groovy… É incrível a produtividade q este “alienígena” proporciona… :-)

    Responda

    admin Reply:

    Que bom que gostou Carlos. Valeu!

    Responda

  4. Ótimo post, lembra muito as situações pelas quais passei, na empresa onde trabalho tive que bater de frente contra a maioria dos paradigmas para buscar uma melhora de produtividade (sofri pra caramba durante todo esse processo).

    Além que sempre existe aquela exigência de que se estar funcionando deve deixar do jeito que estar, em qualquer empresa esse termo é usado.

    Uma coisa interessante a se notar é que de fato passei um bom tempo estudando o grails (foi com ele que conseguir ser contratado), mas no final das contas acabei deixando o grails de lado, um dos fatores que me propiciou a isso na época foram os constantes erros na hora de levantar o servidor, caramba quebrava muito a cabeça com isso, nem mesmo a documentação me ajudava tanto, no final tinha que resolver diversos pontos de configuração para voltar a funcionar (geralmente por culpa da IDE), tanto que resolvir conhecer o vRaptor (tão produtivo quanto, além de ser mais leve e mais sujeito a extensiabilidade), uma das coisas que mais gostei do vRaptor frente ao Grails é o fato do próprio vRaptor conseguir tornar a programação em Java exponicialmente mais produtiva, a mesma simplicidade usada no Grails também é vista no vRaptor com a vantagem de ter um menor overhard além de ser mais muito mais simples de ser extendido, estava trabalhando em um projeto usando vRaptor (a principio usei Grails, mas o overhard o tornava impraticável para meu ambiente de desenvolvimento).

    Atualmente me encontro meio que descontente com os sistemas de código gerenciado em geral, e estou investindo meus estudo mais sobre Vala que me parece bem mais promissor.

    Responda

    admin Reply:

    Oi Cristovao,

    bacana que tenha gostado.
    Com relação aos seus problemas com Grails, tenho algumas observações ok?

    * Problemas com servidor normalmente são decorrentes de algum problema no seu build. Muitas vezes sem querer incluimos arquivos jar no diretório lib que adicionam incompatibilidades no sistema. Depois da uma olhada nisto.

    * Como o VRaptor é mais propenso a extensibilidade? (achei interessante isto. conta ai!)

    * Programação em Grails é com Groovy. É muito comum ver gente sofrendo com o framework porque tentou programar nele exatamente como faze em Java.

    * Conta mais desta sua experiência ai com o Vala. Como está indo?

    Grande abraço,
    Kico

    Responda

  5. Parabéns !!!

    Gostei de mais do post, achei até engraçado pois estou passando por esta situação nas ultimas semanas mas já estou me habituando ao novo ambiente rs.

    Não sou tão experiente mais boa parte do meu conhecimento é em java, na empresa em que trabalho, logo quando entrei comecei a aprender Android ainda não estava nos meus planos mais foi bem legal afinal e acabei acelerando um processo no qual seria inevitável passar (ainda pretendo me especializar em desenvolvimento mobile) no começo achei que era igual java que eu poderia programar como estava acostumado mas depois com mais tempo em pesquisas o conceito de desenvolvimento mobile entrou na minha cabeça rs.

    E agora uma fase que está sendo realmente complicada, tive que aprender .Net de ultima hora =p, mas já estou me habituando depois de muita pesquisa. E já estou vendo que não é nenhum bixo de 7 cabeças

    Achei até engraçado quando li o post e percebi que estava passando exatamente por esta situação xD.

    Responda

    admin Reply:

    Oi tuma, que bom que gostou cara, valeu!

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *