Recentemente cheguei a uma triste conclusão: boa parte dos programadores com os quais lido não sabe ler, o que me tranquiliza com relação ao desabafo que farei neste e-mail (afinal de contas, não será lido).
No meu dia a dia, é muito comum responder a uma média de 5 a 10 e-mails relativos a dúvidas de programação (em sua maior parte, Groovy/Grails e Java em geral). Destes e-mails que respondo, em aproximadamente 60% dos casos, envio um artigo relacionado para complementar a minha resposta ou que, simplesmente, já contém a solução para o problema/dúvida.
E é exatamente ai que a coisa fica interessante: quando envio um e-mail contendo um artigo em inglês, há dois comportamentos distintos (claro, há excessões (e significativas)): ou o remetente me envia uma dúvida que já se encontra elucidada no artigo em questão ou simplesmente me envia a dúvida novamente, porém relativa a algum código presente no artigo (a pessoa só leu o código fonte).
Se o artigo não possui código algum, a dúvida inicial normalmente volta em sua forma original, expondo assim que o artigo sequer foi lido. Ao indagar estas pessoas do porquê (de uma maneira sutil, como “uai, você não leu isto no artigo?”, é muito comum receber a resposta: “sim, mas estava em inglês”.
E é neste ponto que o bicho pega. Se você trabalha com desenvolvimento, e não sabe inglês, você é analfabeto. Isto porque infelizmente, 90% do (bom) conteúdo produzido para a nossa área ESTÁ em inglês. Isto quer dizer que não há conteúdo de qualidade em português? Claro que não! Muito pelo contrário, a DevMedia e a Editora Mundo tem feito um trabalho maravilhoso neste aspecto, porém, por mais que se esforcem neste sentido, não mudarão o fato de que a maior parte da produção intelectual AINDA é produzida em inglês.
Quando o artigo é escrito em português, também observo um comportamento muito interessante: se o artigo contém código fonte, a partir dos e-mails que recebo em resposta, fica nítido que o sujeito só leu o código fonte, ignorando completamente o texto que o envolve. E ai recebo respostas maravilhosas: “o código que você me passou naquele artigo não funciona”.
Percebe-se neste caso um triste comportamento: há preguiça de se ler algo que não seja código Java/C/Groovy/Pascal/etc. Um argumento que escuto normalmente é “eu não tenho tempo”. Mas por trás dos panos, o que percebe-se é o famoso comportamento do “siga o exemplo”.
Entra o “usuário avançado”
Acredito que se trate, em nosso caso, de um problema grave de formação cuja raiz se encontre no usuário avançado: aquele sujeito que vai um pouco além do Windows/Office básico, e que inicia sua “carreira” escrevendo algumas macros e arquivos em lote.
Infelizmente, boa parte dos “profissionais” presentes no mercado atualmente não passam de usuários avançados. Pergunte-lhes o que é uma árvore binária e receberá um olhar interrogativo (sério: faça a experiência). Para este tipo de profissional, curso superior se trata de um luxo desnecessário, o que é facilmente compreensível levan
do em consideração que 99% dos trabalhos realizados por estas pessoas consiste em produzir formulários que alimentem bancos de dados e, em seguida, exponham estes dados na tela.
Realmente, para este tipo de trabalho, conhecimento de algoritmos é quase desnecessário. Afinal de contas, temos ai o Access que produz formulários automaticamente, ou mesmo o Visual Basic e Delphi, que possibilitam a criação de aplicações apenas arrastando componentes e relacionando-os com tabelas e campos presentes em um banco de dados.
(nada contra Visual Basic ou Delphi (minto: tenho alguma coisa contra). Sei que vão além da “programação orientada a mouse”, porém é inegável que em 90% das vezes são usados desta maneira)
E, pior ainda: aqueles que se esforçam em crescer na profissão, e trabalham com ambiente visual de desenvolvimento, ao comprarem algum livro nas livrarias, 95% das vezes topam com livros que apenas ensinam a arrastar e soltar componentes. São raríssimos os livros para estes ambientes de desenvolvimento que realmente cheguem a descrever de maneira decente como funciona a linguagem por trás dos mesmos.
É quando a bomba explode: invariavelmente chega um dia em que estes “programadores” cometerão erros graves, capazes de gerar prejuízos reais a seus clientes. Neste momento, toda uma classe é desmoralizada: a dos desenvolvedores.
Sim, porque para o cliente, não há distinção entre um usuário avançado e um desenvolvedor. Se um usuário avançado se apresenta como desenvolvedor, a partir daquele momento todos serão nivelados para o cliente. E, pior que isto: como este “usuário avançado” considera fácil o que está produzindo, acaba por minar o mercado cobrando preços baixíssimos pelo seu produto, tornando “caro” qualquer serviço prestado por um desenvolvedor de verdade.
Sendo assim, criei um pequeno checklist para se identificar este tipo de profissional:
- Conhece algum algoritmo básico de ordenação ou busca?
- E estruturas de dados? Quais além da matriz você conhece?
- Já trabalhou em algum ambiente de desenvolvimento não visual?
- Quais os outros sistemas operacionais além do Windows você já trabalhou?
- Consegue imaginar uma aplicação que não utilize um banco de dados?
- Uma aplicação sem interface gráfica é possível? Como seria? (este tipo de desenvolvedor não consegue sequer SONHAR em uma aplicação sem janelas)
- E o mais cruel de todos: observe que o sujeito simplesmente não consegue trabalhar em NENHUM outro ambiente de desenvolvimento que não seja o visual NO QUAL aprendeu a programar.
Caso o sujeito em questão se encaixe no perfil descrito acima, escute meu conselho: CORRA!
Quer coisa mais comum do que programadores que não sabem ler mensagens de erro, logs, stacktraces, etc? Existem aos montes. Triste, mas verdadeiro.
Faltou:
* Para TODAS as perguntas sobre tecnologia/framework/api ele sempre responde: “Sim conheço”, e quando você pergunta o que ele já fez, ganha um “Ahh, eu já li sobre isso, mas nunca usei”.
:)
Clássica! :)
Há um clássico também para a lista: nosso “programador” vai programar em alguma linguagem não visual e a chama de lixo por não saber usar.
Exemplo: “pô! este JComboBox do Java é um Lixo! To mandando adicionar itens nele com o método add e o bicho não adiciona!”
Pois é, isso é muito comum pelo fato de não termos nenhum CRM, CREFITO ou seja, não temos conselho regional, nem federal nem nada.
O que fico mais chateada é que, mesmo depois de perder anos fazendo graduação e pós graduação, no meu último emprego como desenvolvedora, meu salário era menor do que os dos caras que eram contadores e administradores, e estavam trabalhando com informática, ou pior ainda, era menor que o cara que tinha feito um cursinho de informática de um mês em uma escola qualquer e achava que sabia tudo…
É triste mas é a verdade, num outro emprego eu, que estava terminando a especialização, ganhava 3 vezes menos dos caras que tinham segundo grau técnico e nenhuma faculdade!
Mais triste ainda porque além de não ter o merecimento de todos os anos que estudei, ainda tenho que aguentar competir com quem nao entende e nao sabe nada e aguentar salários menores pelo simples fato de eu ser mulher. Já sofri muito com isso e chego a pensar em desistir da informática, já que nada é regulamentado e você tem que concorrer desde a meninos de 15 anos que “entendem de computador” até com caras que nunca estudaram e se acham o máximo.
Gostaria muito que tivéssemos algum órgão que regulamentasse a nossa profissão.
Ah, e quanto aos analfabetos, esses caras que se acham “grandes desenvolvedores” não são só analfabetos em inglês, eles conseguem cometer cada absurdo com o português, já vi até escrever “Universidade” com C!!! É uma grande vergonha!!
Um abraço e obrigada pelo espaço para eu também poder desabafar um pouco!
Pingback: Armadilhas para desenvolvedores (ou, o que o tornará mais um idiota) — /dev/Kico
“É quando a bomba explode: invariavelmente chega um dia em que estes “programadores” cometerão erros graves, capazes de gerar prejuízos reais a seus clientes. Neste momento, toda uma classe é desmoralizada: a dos desenvolvedores.”
uhAUHauhAHUa, cara, eu acho que você não tá sabendo se expressar… você está falando de cliente como se esse “programador” fosse capaz de conseguir clientes grandes o suficiente para sofrerem com “erros graves capazes de gerar prejuízos”, me desculpa, eu não sei como é no mundo Java, mas no mundo que eu trabalho existem empresas grandes, e essas empresas grandes contratam programadores, analistas, arquitetos, etc., e é dever da EMPRESA reconhecer o tipo de “programador” que você acabou de descrever.
do jeito que você está falando aí dá a sensação de que um “programador” seria capaz de entrar em uma empresa grande (e mexer com um sistema importante), me desculpa, mas até hoje não conheci uma empresa bem conceituada que não fizesse testes escritos e entrevistas relacionadas com o cargo para saber se o cara estaria apto a trabalhar (incluindo validação de conhecimentos voltados a area academica)… e além disso, mesmo que um “programador” desses passasse pelo processo seletivo, ele não consegueria chegar no ponto de cometer (citando você novamente) “erros graves capazes de gerar prejuízos”, porque se a empresa tem clientes grandes que dependem altamente das regras de negócios e do sistema que esta empresa desenvolve, a empresa não vai colocar o zé ninguém, ops, “programador”, pra mexer com isso
repetindo, não sei como é no mundo Java, mas o cenário que você acabou de me descrever é o que eu conheço por “porta de buteco”, gente sem formação mas que também não tem futuro simplesmente porque se acomoda pelas razões q vc destacou
@leandro koiti. Leandro, como eu gostaria de viver no seu mundo. Conheço diversos casos de empresas gigantescas nas quais ocorre EXATAMENTE o que descrevi.
Normalmente, o que ocorre é o seguinte: a empresa ainda não é tão grande, e tem lá o seu programador meia boca que “quebra o galho”. Conforme a empresa vai crescendo, e este sujeito vai continuando, a bomba vai se armando.
Aliás, não só no Brasil. Já vi isto ocorrer fora daqui também (com menor intensidade). E acredite: infelizmente, VARIAS vezes.
No caso, em todas as vivências, o problema não foi com Java, mas sim com “programadores” que trabalham com ferramentas RAD como VB e Delphi. Isto porque difícilmente quem se “forma” apenas nestas ferramentas vêm a de fato aprender princípios básicos de OO, arquitetura de software, padrões de projeto, etc.
concordo plenamente, na verdade eu já vi casos como o você citou na resposta, mas apesar de tudo, as empresas que eu vi eram empresas pequenas onde até os clientes não sofreriam as consequências dos atos impensados (ou simplesmente burros) dos funcionários (e consequentemente da empresa que contratou), fico triste em saber então que existam empresas grandes por aí que precisam entregar sistemas críticos e ainda dependam desse tipo de pessoa, já que até hj eu só vivenciei isso em empresas pequenas (ou q não serviam sistemas que prejudicassem o cliente dessa forma)
Excelente post, concordo plenamente com o exposto e reforçando, grandes empresas de desenvolvimento têm sim este tipo de problema. Sou desenvolvedor a mais de 20 anos, o que de certa forma me credencia para julgar quando uma aplicação é bem ou mal construída. Atualmente trabalho numa empresa que tem produtos oriundos de duas das maiores empresas brasileiras de software e francamente, precisamos evoluir muito para chegarmos no patamar do “razoável” já que o ótimo ainda está a anos luz. Falta de padronização, falta de documentação, falta ate mesmo de um simples “Try-catch” para contornar um possível erro e o mais sério, falta de um controle de qualidade que evite de o software ir para o cliente com um “bug” no lugar de corrigir um ja existente.
Existe na verdade uma enorme falta de vontade de se levar a sério o trabalho de desenvolvedor. Tecnologia da informação não é algo estanque, evolui continuamente e como tal, precisa de dedicação por parte dos seus profissionais no sentido da busca contínua por conhecimento que possibilite aos mesmos melhorarem seus processos de trabalho e à categoria como um todo o reconhecimento de seus valores por parte da sociedade e do mercado.
Concordo com sua posição sobre o assunto, porem discordo da sua postura quanto a programadores Delphi. Intencional ou não, passa uma certa arrogância em relação a estes profissionais, como que dizendo “Não se misture com esta gentalha”. Conheço programadores ótimos e medíocres de todas as áreas e linguagens. Porém, nunca conheci um programador Delphi que vivesse apenas de arrastar componentes. A tela é fácil de fazer, ótimo, temos mais tempo pro que interessa : a lógica. O código por trás das telas exige o mesmo esforço e tem mesma complexidade e variedade que qualquer outra linguagem, oscilando de algoritmos simples a códigos complexos e extensos, de rotinas básicas a instruções em Assembler. É como zombar de construções pré-fabricadas, preferindo construir com tijolos feitos a mão. É pensar como peão, não como arquiteto. Fica apenas a recomendação de uma boa prática, não de programação, mas de conduta : respeitar o leitor, seja ele um expert ou um iniciante, do delphi ou do java, concordando com você ou não.
Oi Guto. Tem razão: peço portanto desculpas a todos os programadores Delphi que podem ter se sentido ofendidos com esta minha opinião ok?
Mas a intenção realmente não foi esta.
Ok, foi só pra constar. O post está ótimo, claro e destaca bem sua idéia.
Pingback: Armadilhas para desenvolvedores (ou, o que o tornará mais um idiota) « Mundo do Programador