O título ficou um pouco “chamativo”, eu sei. Minha inspiração foi o post Por que aprender Haskell/Python o torna um programador pior. Esse post teve repercussões aqui e aqui , se quiserem dar uma olhada pode ser instrutivo.
Muito prazer – depois desse susto com o título – sou Fabio Akita, autor do livro “Repensando a Web com Rails”, espero que todos possam ter uma chance de dar uma olhada no livro ou então, ao menos, ler meu blog: Balance On Rails. Bem vindos à minha primeira coluna.
Deixando o minuto-marketing de lado: “por que aprender Ruby o torna um programador pior”? Claro, o título é uma provocação, resultado de uma frustração muito comum. Os autores dos posts acima descrevem como depois de aprenderem Python se sentiram frustrados quando retornavam a seus trabalhos para programar C# ou C++. Muitas vezes tentaram “adaptar” algumas coisas para ficar mais parecido com o “jeitão” de Python. Mas no fim o código acabava pior do que deveria ser. A conclusão é que não adianta aprender algo novo se não poderá utilizá-lo em seu trabalho. E pior ainda: seu trabalho será improdutivo pela frustração que você tem em querer fazer algo melhor mas não poder.
Tomarei a liberdade de citar e adaptar alguns trechos desse livro. E em primeiro lugar, o mais importante é que devemos nos lembrar de uma coisa: somos responsáveis por tomar nossas próprias decisões. Não podemos ser passivos e esperar que outros as tomem em nosso lugar.
Todos os dias, desde nossa infância, aprendemos a tomar decisões. Se pegar este caminho corro o risco de um trânsito mais à frente mas posso chegar mais rápido, se pegar este outro sei que é mais longo e não chegarei a tempo. Grandes ou pequenos, não importa. Sempre aprendemos a lidar com o conceito de risco e recompensa, custo e benefício.
Isso é relevante também nas nossas decisões de custo e benefício sobre em quais tecnologias investir. Quinze anos atrás, uma escolha de baixo risco seria aprender a programar em COBOL. Claro, havia muitos outros programadores de COBOL, já que era até mesmo ensinada nas faculdades. Portanto o salário de um programador COBOL não era nada fenomenal. Você poderia facilmente encontrar emprego, mas não seria especialmente lucrativo. Baixo risco, baixa recompensa.
Por outro lado, na mesma época, poderia ter escolhido investigar essa novidade que chamavam de Java, de uma tal Sun Microsystems. Teria sido difícil encontrar emprego nessa área, já que nenhuma empresa estava fazendo grandes investimentos nela. Quem poderia saber se eventualmente alguém faria algo com Java? Mas, se você era uma pessoa bem informada e estava observando o estado da indústria da época, como a Sun estava, poderia ter visto algo especial em Java. Ter sentido um forte sentimento de que um dia seria grande. Investir cedo poderia torná-lo um líder em um futuro grande empreendimento.
Claro, nesse caso, você estaria correto. E, se jogou direito suas cartas, seu investimento pessoal em Java teria sido muito lucrativo. Alto risto, alta recompensa. Nada disso é certo, também poderia ter dado errado, como muitas outras tecnologias que não vingaram.
Modismos vem e vão. E nos últimos anos, gerentes desesperados e donos de negócios tentaram igualar desenvolvimento de software com os processos de manufatura. É a falácia da “Fábrica de Software”. E não é surpresa que esse caminho tenha sido tomado, afinal gerentes “entendem” o trabalho de uma manufatura, de uma linha de produção de bens físicos de consumo.
Infelizmente, a analogia da manufatura não funciona em nossa indústria como gostaríam. Existe uma razão para programas serem “soft”ware e não “hard”ware: software é tão maleável quanto seus requerimentos. E nesse tipo de ambiente de mudanças rápidas, de negócios que aparecem e desaparecem, apenas os flexíveis sobrevivem. Quando a coisa aperta, o homem de negócios vai procurar o profissional que pode resolver o problema no momento. E como você se torna essa pessoa?
É muito pouco prático ser um daqueles cara de Unix que simplesmente se recusa a mexer com Windows. Ou um programador Java que não quer saber de .NET. O mesmo vale para aqueles que acham que podem ser apenas programadores ou apenas arquitetos e não se interessam pelo trabalho gerencial. Ou mesmo o administrador de banco de dados (DBA) que não entende nada do código sendo feito. Não há muito valor em alguém que se clama “especialista” dessa forma.
Para vocês, especialistas em Java, imaginem-se em uma entrevista de trabalho: “como você escreveria um programa, em Java puro, que pudesse derrubar uma Java Virtual Machine”? Silêncio. “Alô?”
“Uh, desculpe, nunca fiz isso antes.”
“Claro que não. E que tal essa pergunta: como escreveria um programa que NÃO derrubaria uma JVM?”. Chad Fowler estava procurando por bons programadores Java. No começo da entrevista pedia aos candidatos para se darem uma nota de um a dez. Este disse nove. Chad esperava uma estrela lá! “Se uma pessoa se dá uma nota tão alta, como não consegue pensar em um simples abuso de código que faria uma JVM dar crash?”
Falta de aprofundamento técnico.
Esse é alguém que clama ser um especialista em Java. Se o encontrasse em uma festa e perguntasse o que faz, ele diria, “Sou um desenvolvedor Java”. E mesmo assim, não consegue responder essa pergunta simples, nem mesmo tentar inventar uma resposta errada.
Claro, você não precisa saber essas coisas para codificar coisas básicas sob a supervisão de outros. Mas esses deveriam ser os “experts”.
Muitos acreditam que se especializar em alguma coisa simplesmente significa não conhecer outras coisas. Poderíamos, por exemplo, chamar nossas mães de especialistas em Windows, já que nunca usaram Linux ou OS X.
Você tem um problema médico e seu clínico geral lhe encaminha a um especialista para realizar uma biópsia. E se esse especialista apenas tivesse credencial de especialista porque não assistiu nenhuma outra matéria na faculdade a não ser as diretamente ligadas ao ato de realizar essa biópsia? E isso não quer dizer que ele se aprofundou neste procedimento. E se ele apenas viu a superfície desses tópicos e não sabe de nada mais?
“E se aquela máquina começa a bipar durante a operação?”, você perguntaria. “Oh, isso nunca aconteceu antes. Não vai acontecer agora. Sei lá o que faz aquela máquina, mas ela nunca bipa.”
Felizmente, muito felizmente, a maioria dos desenvolvedores de software não é responsável por situações de vida ou morte. Se fazem besteira, normalmente o resultado é um projeto atrasado ou erros de produção que simplesmente vai lhe custar mais dinheiro, não vidas.
Chad já lidou com muitos diferentes tipos de programadores. Uma vez perguntou a um de seus empregados. “O que quer fazer com sua carreira? O que quer ser?”. E ele ficou terrivelmente desapontado com a resposta: “Quero ser um arquiteto J2EE”. E ele perguntou por que não um “Microsoft Word designer” ou “Instalador RealPlayer?”.
O cara queria construir uma “carreira” sobre uma tecnologia criada por outra companhia da qual ele sequer era funcionário. E se a companhia desaparecer do mercado? E se ela deixar sua agora-sexy tecnologia se tornar obsoleta? Por que você confiaria sua carreira a uma empresa?
Por alguma razão, como uma indústria, nos enganamos pensando que “líder de mercado” é a mesma coisa que “padrão”. Então, para algumas pessoas, parece racional fazer o produto de outra empresa ser parte de suas identidades.
Qualquer economista ou agente de mercado financeiro lhe dirá para jamais colocar todo o seu dinheiro apenas em uma ação na bolsa, principalmente se você for um principiante. Sua carreira é um investimento e a tecnologia em que você está apostando é uma ação. Jamais coloque todos os seus ovos em um único cesto.
E lembre-se sempre: você já perdeu seu emprego. O trabalho para o qual foi contratado não existe mais. A única coisa certa é que tudo está em mudança. A economia está mudando, empregos se movem offshore e voltam. Os negócios estão tentando entender como se adaptar. As coisas, até hoje, ainda não encontraram um ponto estável em nossa indústria. Nossa indústria é como o adolescente esquisito através da puberdade: estranho, feio e diferente ano após ano, dia após dia.
Então, se foi contratado como programador, não pense em si mesmo como programador. Continue fazendo seu trabalho mas não se sinta muito confortável. Não tente se acostumar com sua identidade como programador, ou arquiteto, ou designer.
Não existem carreiras estáveis em nossa indústria. É muito bom ser ambicioso mas não tente vislumbrar muito no futuro. Se você quer atingir um alvo móvel, não se deve mirar no alvo, mas sim onde ele provavelmente estará mais à frente. O caminho daqui até ali não é mais reto.
O fato de você conhecer C# e achar frustrante aprender Python, ou Ruby, ou qualquer outra linguagem, porque não tem uso agora, neste projeto em particular, não é nem a metade da história. Chad, durante todo o seu livro, exprime sua experiência para nos ensinar como não nos tornarmos obsoletos. Aprender novas linguagens, novas técnicas, novas ferramentas nos ajuda no caminho de nos tornarmos “generalistas”, ou como costumo chamar, de “Provedores de Solução”. Um especialista tem utilidade limitada e se torna obsoleto rápido demais. Um generalista não tem preconceitos, está preocupado e tem a capacidade de resolver qualquer problema. Esse é o profissional de valor que nunca ficará desempregado.
Como disse Chad, é necessário termos a mente aberta para aprender rápido, absorver e entender o que acontece à nossa volta, em nossa indústria. Isso nos dá meios de tentar mirar onde nosso alvo chegará amanhã. Em seu livro, mencionou o índice TIOBE. Ela utiliza técnicas de pesquisa pela internet – que não são cientificamente rigorosas – para tentar medir a popularidade de uma linguagem. Quando seu livro foi publicado pela primeira vez, Ruby sequer entrava na lista das 20 linguagens mais utilizadas. Mas hoje, poucos meses depois, Ruby já figura como 13a linguagem mais popular e está subindo. É um indicador importante.
Mesmo que Ruby ou Rails falhem em se tornar o próximo “líder de mercado”, isso é irrelevante. Aprender nos faz executar nosso trabalho com mais qualidade e criatividade. Não existe nada novo que não valha a pena aprender. Portanto, contradizendo o título, “Aprender Ruby nos faz programadores melhores”.
Todos os diretos reservados a RubyOnBr. Copyright RubyOnBr .
This site is powered by Radiant CMS.