Armadilhas para desenvolvedores (ou, o que o tornará mais um idiota)

Com o passar do tempo, ficam nítidas para mim algumas situações nas quais desenvolvedores  talentosos (ou não) entram e das quais saem completamente idiotas (raríssimas vezes com algum tipo de salvação). Chamo estas situações de “armadilhas para desenvolvedores” e, a partir deste post, pretendo expor algumas das que presenciei ou virei a me deparar a partir de então (sintam-se abertos a me contarem as suas).

A palavra “armadilha” foi selecionada a dedo. Isto porque todas as situações que irei mencionar aqui possuem uma característica em comum: apresentam um ambiente ou objeto aparentemente confortável e desejável que, uma vez penetrado ou obtido, mostra-se incrívelmente cruel.

Armadilha #1: Determinismo linguístico

É o meu pior pesadelo sem sombra de dúvidas. Para aqueles que não o conhecem, o determinismo linguistico consiste na hipótese segundo a qual a nossa percepção do mundo é definida por nossa linguagem. Exemplo clássico: os esquimós. Estes conseguem distinguir n tons diferentes de branco, cada um com seu próprio nome, ao passo que nós, brasileiros, basicamente conseguimos distinguir apenas o branco e o cinza. Em contra-partida, conhecemos n tipos diferentes de bananas (nanica, caturra, serra d’água…), ao passo que um esquimó só consegue distinguir de cara um tipo de banana.

Como isto se aplicaria a um desenvolvedor? Simples: aquele que só utiliza o mesmo ambiente de desenvolvimento/linguagem normalmente tem uma dificuldade monumental em aprender qualquer outro. Exemplo clássico: o pessoal que trabalha com ambientes RAD como Visual Basic ou Delphi (mais específicamente, os amontoadores de componentes (há pessoas absurdamente competentes trabalhando Delphi e VB)). Ao tentarem aprender outra linguagem como Java, por exemplo, a primeira coisa que tentam fazer consiste em aplicar exatamente as mesmas técnicas que utilizavam até então neste novo ambiente. Resultado: fracasso total. É possível diagnosticar alguém que tenha caido nesta armadilha ao ouvir alguma das frases abaixo:

  • “Linguagem/Ambiente X é um LIXO!”
    O sujeito está tentando aplicar técnicas específicas de um ambiente/linguagem em outro. Como não irão funcionar, consequentemente, vê a culpa NO ambiente/linguagem, e não em si mesmo.
  • “Sou muito mais produtivo na linguagem/ambiente X. Se estivesse trabalhando nele, o trabalho já estaria pronto!”
    O problema se torna nítido. O sujeito basicamente confirma que realmente só consegue trabalhar em um ambiente/linguagem.
  • “Linguagens de programação são todas iguais. Só varia a sintaxe…”
    Aham… Se fosse verdade, só existiria UMA linguagem de programação (a que o sujeito conhece, provávelmente)

Um aspecto interessante de quem caiu nesta armadilha consiste em uma certa arrogância. Culpam a linguagem/ambiente por todos os problemas que estão enfrentando e se esquecem de que o mesmo ambiente/linguagem foi utilizado com sucesso incontáveis vezes em projetos do mesmo ou maior porte do que aquele no qual o indivíduo se encontra em dificuldades.

Na realidade, o determinismo linguístico fica exposto ao perceber o modo como o sujeito inicia sua produção no novo ambiente. Muitas vezes nem sequer chega a estudá-lo direito. Simplesmente cata a primeira IDE que encontra e começa a trabalhar exatamente como fazia no ambiente/linguagem com o qual estava habituado.

Armadilha #2: software = banco de dados relacional

O sujeito não acredita que exista desenvolvimento além do CRUD. Como detectar alguém que tenha caido nesta armadilha? Simples: mencione qualquer tipo de estrutura de dados diferente de tabela ou índice. Se disser que conhece, vá além: peça para que lhe descreva o funcionamento (alerta: criará inimigos com isto). Ou, pior ainda, pergunte ao indivíduo se ele consegue programar algo sem um banco de dados relacional por trás.

O que ocorre nesta situação: o sujeito trabalha em um ambiente no qual a esmagadora maioria das demandas consista apenas na criação de aplicações que armazenem e busquem informações presentes em bancos de dados (apenas CRUD). No máximo, um relatório ou outro mais complexo, envolvendo somatórios e agrupamentos. O que se percebe é a armadilha #1, ou seja, o determinismo linguístico. A diferença é que este é O caso mais comum da armadilha E o que também causa os maiores prejuízos.

Como o resultado de uma consulta SQL é imediato, o sujeito acredita que seu trabalho terminou na criação dos formulários de exposição e cadastro. No entanto, a partir do momento em que o problema se tornar mais complexo a coisa muda de figura.

O mais fascinante desta armadilha consiste no fato da vítima conseguir fazer coisas incríveis com SQL, porém falhar miserávelmente quando precisar de qualquer coisa que vá além desta.

Neste caso, no entanto, há uma bomba relógio ativada: está provado que os SGBDs relacionais não escalam bem em ambientes paralelizados (mais sobre isto aqui, aqui e aqui(terceiro link particularmente interessante, por apresentar o CouchDB)). Como o número de processadores por computdor está aumentando, e o clock de cada um destes tende a diminuir e cloud computing está crescendo MUITO, veremos problemas imensos de performance nos próximos anos cuja origem se encontra justamente neste tipo de profissional que acredita no mito de que uma aplicação é composta por um banco de dados relacional apenas.

Este tipo de indivíduo se esquece de algo básico: os dados são o resultado de um processamento, e não o contrário!

Armadilha #3: ambientes de desenvolvimento RAD

O sujeito aprende a programar em um ambiente RAD e se atém a este. O utiliza para criar um CRUD simples, sempre utilizando a mesma linguagem (99% das vezes VB, Delphi e Visual Studio). Resultado: armadilhas #1 e #2 engatilhadas com um agravante: a ilusão de que desenvolvimento de sistemas é uma tarefa simples.

Não tenho nada contra estes ambientes (sendo assim, por favor, não me ataquem), porém tenho contra o seu mal uso. O maior problema aqui ocorre quando se esquece que um ambiente como VB ou Delphi deve ser usado apenas para facilitar a execução de tarefas repetitivas e tediosas, como por exemplo a criação de um formulário, e que estas tarefas repetitivas e tediosas são apenas uma PEQUENA parte do processo de desenvolvimento, e não o seu todo.

O que se observa é basicamente o contrário: o indivíduo passa HORAS (ou DIAS) buscando componentes terceirizados para finalizar as tarefas que não envolvam CRUD, os incorporam em seus “sistemas” porcamente e se esquecem de outros elementos que também deveriam estar presentes no processo, como por exemplo segurança, escalabilidade, usabilidade e, mais importante ainda: código de qualidade, que seja fácil de ser mantido e compreendido.

Quer detectar alguém com este problema? Simples: remova deste indivíduo a sua IDE.

Armadilha #4: português é seu único idioma

Parece impensável, mas a quantidade de “programadores” que ignora completamente o inglês é alarmante. Como consequencia, tem de se virar apenas com o que existe publicado em português. Dado que a qualidade é muito inferior à que é produzida no exterior, o sujeito acaba se tornando limitado com o passar do tempo.

Claro, as coisas estão melhorando aqui no Brasil, porém, por mais que melhorem, difícilmente se igualarão à publicação atualmente produzida em inglês. Mesmo porque até os países no qual o inglês não é o idioma oficial costumam publicar conteúdo para nossa área em… inglês.

Armadilha #5: preguiça de ler

O sujeito acredita que não precisa ler para se tornar um bom profissional. Resultado? Programadores analfabetos. Já escrevi sobre isto aqui, sendo assim, não irei me alongar muito sobre o assunto.

Armadilha #6: medo da mudança

O indivíduo pira a cada mudança que ocorre em seu ambiente de trabalho. Mudou um pouco a especificação? Boom! Crise, o sujeito pensa em pular do último andar do prédio em que trabalha. Chamo este tipo de profissional de “desenvolvedor autista”.

O desenvolvedor autista não consegue ver que a mudança é a principal razão pela qual recebe seu dinheiro todo mês. Que se estas cessarem, seu trabalho automaticamente torna-se desnecessário e, pior ainda, nega o básico da realidade: tudo muda. No século V a.C Heráclito já dizia: panta rei (tudo muda). Se as coisas mudam na natureza, por que não muariam no seu trabalho? Será possível que 2500 anos depois, as pessoas ainda não conseguem aceitar este fato???

A origem do problema consiste na crença de que o desenvolvimento de sistemas é uma ciência exata. Noção esta completamente equivocada, se levarmos em consideração o fato de que nosso trabalho consiste em modelar no ambiente digital um problema que ocorre no mundo físico. Problema este que normalmente é criado por seres humanos que, como todos sabemos (com excessão do desenvolvedor altista), mudam de opinião o tempo inteiro!

Como identificar alguém com este problema? Varia do nível: nos casos extremos, basta mudar a posição do seu mouse.

Conclusão

Estas são as principais armadilhas que já presenciei. Após analisá-las, alguém poderia me fazer alguns questionamentos, como os a seguir:

Por que não foram mencionadas armadilhas de gerenciamento?

Simples: por que se alguém quer gerenciar uma equipe de desenvolvimento, você tem de saber o que está gerenciando, ou seja: tem de pelo menos uma vez na vida ter programado ou pelo menos tentado. Caso não tenha se mostrado um bom programador, ao menos deveria saber como reconhecer um.

Como eu evito estas armadilhas?

Basicamente evitando a primeira, ou seja, reconhecendo a diversidade e o fato de que desenvolvimento de sistemas é uma atividade complexa, que requer estudo constante e que poucos conseguem levá-la a cabo com sucesso, ou seja: diminuindo a arrogância.

21 thoughts on “Armadilhas para desenvolvedores (ou, o que o tornará mais um idiota)

  1. Muito interessante esse post, a questão do inglês ainda é algo que me impressiona bastante até hoje.

    Responda

  2. Bom levantamento! Eu ainda incluiria:

    #7 Egocentrismo: Achar que só precisa programar de forma inteligível pra si mesmo (mesmo um projeto pessoal um dia pode crescer e se tornar aberto…) ou não saber trabalhar em equipe. Assim como não saber ouvir, não apoiar projetos de terceiros, etc.

    #8 Inércia: Achar que não precisa aprender mais nada, seja na própria área ou em outras. Se bem que essa armadilha cobre um pouco todas as outras.

    Abraço!

    Responda

  3. Legal o post!
    Apesar de parecer com o “#6: medo da mudança”, um tipo que passo muita raiva é o “Ser Apático”.
    Este ser não chega a ter medo de mudar nada, porém, também não faz questão de mudar uma palha pra ajudar. Este tipo é um dos piores, principalmente quando se transformam em “Gerentes-Programadores”.

    Responda

  4. Nada mais do que a realidade…

    muito bom o post, demonstra que a nossa área tem muito o que amadurecer.

    Legal também a citação da pérola dos Design Patterns no Twitter “Design Pattern é sintoma de linguagem ruim.Uma boa ling oferece os meios para expressar tudo sem precisar copiar e colar”

    Abraços

    Responda

  5. Opa Kico! Eu tinha trabalhado contigo na ecm.
    Só dei uma passada no texto e me identifiquei e muito com o item 4 ainda mais quando trabalhava contigo.
    A impressão que eu tenho é que usava daqueles óculos de natação com o vidro de 2 cm. Agora que já melhorei bastante no inglês, afinal dediquei bastante e já devo estar no 2 ano de inglês, me sinto uma pessoa livre e independente.
    Agora enxergo tudo em widescreen. Não é uma maravilha?

    Have a nice day!

    Responda

  6. no geral foram ótimas linhas-guias do que os desenvolvedores devem se afastar, só acho que incitar aversão ao VB e ao Delphi tira um pouco a credibilidade dos seus comentários já que fica parecendo que você só consegue falar bem do Java (armadilhas 1, 2 e 3 maybe?), eu só comentei sobre o VB e o Delphi pois apesar de você falar que não tem nada contra, em um outro post você falou que tem algo contra (citando: “(nada contra Visual Basic ou Delphi (minto: tenho alguma coisa contra)”), eu não sei a intenção do blog em geral, se for só para o pessoal do Java peço desculpas, mas se for um blog com intenção de instruir outras pessoas, esses comentários tendenciosos muitas vezes acabam ajudando as pessoas a “terem medo de mudança (armadilha 6)” e acabam caindo na armadilha 1 também já que provavelmente vão optar por falarem mal de VB ou Delphi sem as vezes nunca ter mexido

    eu já trabalhei com Java usando Eclipse e o Netbeans, PHP usando o Dreamweaver e o Bloco de Notas, .NET usando o Visual Studio, assembly usando o edit, C++ usando o Builder e concordo plenamente… quando a pessoa enfia na cabeça que algo é ruim ela tende a só piorar sua imagem

    Responda

    admin Reply:

    @leandro koiti, na realidade, eu realmente nada tenho contra VB ou Delphi (trabalho com ambos). Tenho muito contra o mal uso dos mesmos. Isto é o que eu tenho contra.

    Na realidade, eu tenho contra os dois o fato de acidentalmente acabarem incitando este mal uso. Por mal uso, no caso, eu quero dizer aqui ficar apenas no arrastar e soltar, e acabar se esquecendo que esta é apenas uma pequena parte do processo de desenvolvimento de software.

    Responda

  7. Outro excelente post, concordo em gênero, número e grau. Acredito que em grande parte essas “armadilhas” são decorrentes de uma mesma, ou seja, a completa falta de interesse por parte dos desenvolvedores em evoluírem, abrirem a cabeça para o novo, lerem (aprenderem inglês antes).
    A melhoria de uma categoria como um todo passa antes pela melhoria individual de seus componentes, busquemos a melhoria e a evolução contínua que seremos reconhecidos pela sociedade e principalmente pelo mercado de trabalho.

    Responda

  8. Nossa, show de bola a leitura desse post! Voce capturou o que realmente acontece! O ponto que acho mais relevante (pq tem outros mais importantes) eh o do portugues como lingua unica. Faz parte do desenvolvimento do profissional de informatica aprender outra lingua, e pecar nesta area significa pecar com o desenvolvimento profissional. Parabens!

    Responda

  9. Interessante esse post,é uma verdade quando vc diz o quanto estamos amarrados
    a um banco relacional.

    Responda

  10. Muito bom o post.
    Desenvolver envolve N fatores e realmente estamos sujeitos a armadilhas. A mais curiosa que já vi entre desenvolvedores RAD partindo pra web (como o PHP), pois em VB/Delphi um objeto está sempre acessível e na web dependemos de GET/POST para manipular e acessar objetos/vetor. Fica aí uma dica importante. Desenvolver é aprender sempre… Parabéns!

    Responda

  11. huahuahauhauhauahuha Adorei a armadilha 6. Pior que isto existe mesmo hauhauhauhau. Parece brincadeira.

    “Como identificar alguém com este problema? Varia do nível: nos casos extremos, basta mudar a posição do seu mouse.”

    Responda

  12. Em geral contratam pessoal qualificado pra trabalhar com um conjunto de tecnologias, daí chegam um dia e impõe outra tecnologia por mero capricho, jogando no lixo anos de desenvolvimento profissional.

    E depois não querem que o mercado esteja cheio de gente incapaz e pulando de empresa em empresa.

    Leva-se anos para conquistar o dominio sobre alguma tecnologia e não se pode descartar isso apenas por modismos.

    E uma dica pra você:
    Seu texto carrega uma forte carga de preconceitos, cuide disso pois é péssimo para qualquer pessoa.

    Responda

    admin Reply:

    Opa,

    claro que carrega forte carga de preconceitos. Como todos, eu sou preconceituoso também. Mas há uma diferença: eu os assumo e sou feliz com isto, você devia tentar também! :D

    Responda

    Tambem achei Reply:

    Também achei… Ou melhor .. Programe em Java e não sofrera este preconceito

    Responda

Leave a Reply

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