%w(Akita On Rails) * 2.0Sua referência de Ruby on Rails

Só para variar, acredito que este artigo acabe ficando meio “filosófico” novamente. Normalmente não tenho os recursos para uma abordagem mais rigorosa, com pesquisas de campo e análise estatística de um enorme espaço amostral, por isso me resta confiar na minha experiência prática e em dados que temos acesso publicamente.

Um desses dados é esta pesquisa: Pesquisa diz que 75% de profissionais de TI querem mudar de emprego. Ela é antiga, do meio do ano passado, mas eu vejo isso na prática. Alguns dias atrás alguns amigos chegaram à mim exatamente com esta proposição: “estou descontente com o que estou fazendo”.

Precisamos levar esses artigos com cuidado, a maioria são dados do mercado americano. Por exemplo, este outro diz que Programadores são os mais bem pagos da tecnologia. No Brasil isso não é necessariamente verdade. Na realidade os programadores ganham o “suficiente”, quem tem maior faturamento são analistas – formados em áreas adversas e que usam a tecnologia como ferramenta de trabalho. E normalmente são justamente esses analistas e consultores, que fazem até R$ 100 mil por ano que mais reclamam do que ganham.

Outra reclamação que ouço com freqüência é “não estou mais gostando de onde trabalho porque não me ‘agrega’ mais nada. Quero ir para outros projetos para aprender mais”. Sim, é louvável uma atitude de mudança, mas acredito que a maioria está mal direcionada. Um colega nosso uma vez resumiu isso: “a grande maioria dos projetos é tudo igual: cadastros e mais cadastros”. E é isso mesmo, é o derivado da antiga área chamada de Processamento de Dados que hoje apelidaram de Sistemas da Informação.

Deveria haver mais do que isso. Na área de não-programadores existem Business Intelligente, Customer Relationship Management, Supply Chain e várias outras áreas de ponta, que dão o diferencial às empresas que já sabem controlar o básico: contabilidade, vendas, compras, manufatura, manutenção, controle de qualidade.

No Brasil, a grossa maioria dos “programadores”, fazem customizações em processos que já existem ou em ‘adendos’. Um departamento quer automatizar o cadastro de seus funcionários: ela compra ou cria cadastros próprios. Outra quer um formulário de vendas que alimente seu sistema de vendas e notifique seu parceiro externo para motivos de atualização de inventário. Outra precisa de alguns cadastros para controlar um fluxo de trabalho de atendimento a clientes. Cadastros e cadastros, normalmente é alguma variação de Cadastros.

Não é à toa que tantos programadores estejam insatisfeitos. Normalmente eles não sabem ‘por que’, mas sentem que algo está ‘errado’. Claro, em meus artigos, por favor, não levem nada ao pé da letra. Existem dezenas de projetos interessantíssimos com a codificação de algoritmos complexos para controle de tecnologia média, aero-espacial, engenharia. Estou me referindo à ‘maioria’, não a ‘todos’.

Esse processo sistemático de cadastros e mais cadastros é antigo. Desde Cobol, desde os anos 70, o processamento de dados foi uma área muito importante para trazer dinamicidade ao mundo moderno, eliminando toneladas de papel e dezenas de burocratas cuja única função era preencher e controlar esses monte de papel. E isso nunca vai acabar, a menos que os computadores se tornem tão espertos que passem a não precisar mais de ‘meros’ programadores. Nunca se sabe.

Enquanto isso, o mercado ainda terá necessidade dessa categoria de profissionais: ‘programadores de cadastros’. Não importa se você usa Struts, Spring, Rails, Symphony, você estará fazendo cadastros de usuários, de clientes, de materiais, de conteúdo, de reclamações, de serviço, de contratos, de endereços, de parceiros, de fornecedores. A lista é enorme. Principalmente em locais onde a ‘modernização’ ainda não chegou, onde as empresas ainda tem muitos burocratas e onde os processos ainda não foram estabilizados e muito menos automatizados.

Lembro que comecei fazendo cadastros no fim dos anos 80, com dBase e Clipper. Boa parte da era Cliente-Servidor (2-tier) era isso: um banco de dados no servidor e telas de cadastro no cliente. Quando a Web chegou, vimos aplicações muito sedutoras, como search engines, webmails. De repente, todo mundo queria fazer um Website. As pessoas que inventaram as tecnologias: TCP/IP, HTTP, HTML, SMTP, POP3, etc devem ter se divertido muito, mas para o resto de nós: mais cadastros. Telas para escrever e-mais = cadastro. Telas para e-commerce = mais cadastros. De repente as empresas substituíram o modelo de telas Visual Basic por browsers. Cadastros travestidos de páginas Web.

Não é à toa que aparecem tantos frameworks no mercado: Struts, Velocity, Lucene, Jack Rabbit, Spring, Guice. Programadores de verdade, gostam do ‘plumbing’, do encanamento. Gostamos de entender como funciona essa ‘malha’ de códigos, como otimizar, como tornar estável, como ligar coisas. Existem muitos no Brasil que pensam assim, mas muito menos do que nos Estados Unidos. Não temos nada sequer próximo de um repositório como Apache Jakarta. Temos colaboradores brasileiros em diversos projetos open source, mas é uma fração pequena.

Vejo isso pelo caso Rails. Surgiu faz pouco tempo. Não surgiu nos EUA. Mesmo assim ele se alastrou muito rapidamente por lá. Enquanto isso, aqui, tirando pequenas comunidades como a competente RubyOnbr, não temos nada. Nada de interessante na mídia, nada de interessante em convenções (que temos muito poucas, aliás). Nothing, zip, nada. Meu livro, ‘Repensando a Web com Rails’, mal vendeu sua primeira edição de 1000 exemplares. Já o [excelente] ‘Agile Web Development with Rails’ vendou dezenas de milhares lá fora. Não é apenas por ser um livro ‘melhor’ ou ‘pior’: as vendas meteóricas e o lançamento de dezenas de outros lá e o fato do meu ser o único aqui ainda, são um termômetro da diferença de culturas tanto do mercado quanto dos programadores.

Tudo bem, tivemos um período negro de mercado fechado, anos de atraso, mas hoje não vejo motivos para que os programadores, principalmente os mais jovens, sejam tão ‘apáticos’ à tecnologia.

Nessas horas sinto um pouco de falta do fim dos anos 80 (é a época que eu lembro, alguns mais experientes vão sentir a mesma coisa sobre o fim dos anos 70). Naquela época sabíamos que éramos muito poucos. Era raro encontrar alguém que fosse programador ou pelo menos um entusiasta. Mas pensávamos diferente. Mesmo no meio dos anos 90, pouco antes do boom da internet, nossos amigos e colegas eram todos amantes de tecnologia. Sempre conversávamos sobre o que havia de novo, o que havíamos aprendido de novo, o que estávamos testando de novo. Trocávamos idéias, discutíamos técnicas. O objetivo era sempre aprender mais e mais. Conheci pessoas cujo hobby era escrever pequenas animações am Assembly. Conheci outras que compravam componentes eletrônicos para criar seu próprio mp3 player (naquela época não havia iPods). Alguns passavam horas fazendo ferramentas para essa tal de ‘internet’ que ainda era nova para nós. Eram bons tempos.

De repente, o mercado brasileiro de informática explodiu, por diversas razões. De repente, muita gente viu na área de informática uma maneira rápida de ganhar dinheiro. De repente, as faculdades ficaram lotadas de garotos aprendendo não tecnologia, mas ferramentas. Tornando-se não bacharéis em ciência da computação, mas tecnólogos em sistemas de informação. De repente, todo mundo ‘sabia’ Java. E, finalmente, de repente o mercado se tornou saturado: com centenas de ‘programadores’.

Agora, tudo que ouço dos atuais ‘programadores’ é “qual linguagem você acha que eu deveria aprender que vai dar mais dinheiro?” Alguns podem imaginar quão frustrante isso é para mim, que já estou me sentindo alguém da velha guarda. Eu nunca pensei no custo-benefício do tempo de aprendizado. Eu sempre considerei que aprender era algo que eu deveria fazer constantemente, se eu ganhasse dinheiro no processo, melhor, mas nunca foi o principal.

Por causa do atual estágio de aberração do mercado eu presencio coisas que me dão medo. Em um certo cliente, ‘integraram’ um sistema de vendas com outro de ativação de um certo equipamento. A transação é lógica: efetuada a venda, o equipamento do consumidor deveria ser ativado. Mesmo que não se use alguma solução de two-phase commit (todos sabem o que são Transações Atômicas, certo!?) deveria ser parte do requerimento haver salva-guardas para garantir esse tipo de coisa. Obviamente, não existia, ninguém nunca questionou – nem os programadores, nem os analistas e, claro, muito menos os gerentes. Resultado: agora existem várias pessoas empregadas cuja única função é formatar planilhas com os erros e fazer as correções manualmente. Mais cadastros foram criados para lidar com esses erros. Houve um ganho de automatização no projeto? Claro, mas não tanto quanto deveria. E ninguém liga para isso. E já vi coisas piores. Me entristece ver como o ‘grosso’ dos programadores e toda a cadeia daí para cima (programadores que viraram analistas, programadores que viraram gerentes) tem tão poucos conhecimentos e, portanto, por consequência, criam arquiteturas e soluções tão pobres.

E retorno às indagações que me fizeram antes: “estou descontente com o que estou fazendo”, “acho que não estou aproveitando meu ‘potencial’”, “quero aprender algo novo para ganhar mais dinheiro”. Eu não tenho respostas para isso porque eu não consigo pensar assim. Mais do que isso: acredito que essas perguntas são fundamentalmente erradas. E não há como encontrar a resposta certa com uma pergunta errada.

Eu tento disseminar a cultura que eu conheci quando ainda era um jovem programador: aprender. As desculpas que ouço são sempre as mesmas “não tenho tempo para aprender tanto quando preciso trabalhar para me sustentar”, “não sei ler inglês por isso preciso fazer cursos, portanto só posso aprender uma coisa de cada ves”, “não adianta eu aprender esse tal ‘X’ porque não sei se vou usar no trabalho”, “já me estresso o suficiente no trabalho, nas horas vagas quero só descansar”. E assim por diante. Uma lista enorme exatamente disso: de desculpas. Acho que faz parte da natureza humana não querer sair de sua zona de conforto e pior, depois de reclamar quando se tornam obsoletos. “A culpa é do governo”, “a culpa é do capitalismo”, “a culpa é do meu chefe”. Mais desculpas.

Quando escrevi meu livro, por exemplo, fiz com dois motivadores: aprender algo novo e ajudar outros a aprender junto. Aprender e Ensinar, são os dois motivadores fundamentais de todo bom programador. Entendo que numa realidade brasileira, não pensar em dinheiro não é uma opção. Eu encontrei um equilíbrio entre as duas, não é possível que mais ninguém consiga. Ficar parado, sentar no pouco que se aprendeu tempos atrás e apenas reclamar, reclamar e reclamar, nunca levaram ninguém a lugar nenhum.

Se vale alguma coisa, aqui vão algumas sugestões pessoais:

• Quanto mais se aprende, melhores serão suas soluções. Os cliente sabem reconhecer um profissional que sabe exatamente do que está falando. Todo mundo sabe quando alguém está apenas enrolando.

• As demandas que irão crescer mais tem a ver com integração de sistemas e análise de grandes quantidades de dados. A única forma de lidar com isso é conhecer dezenas de conceitos e tecnologias. Aprender uma ferramenta em um curso não vai ajudar.

• O ciclo de tecnologia está ficando cada vez mais curta. Antes uma nova versão levava anos para sair. Esse tempo se reduziu a poucos meses. No momento em que você sair do seu curso, o que você aprendeu já é obsoleto. Lide com isso. Adiante-se. Aprenda o máximo possível até mesmo antes da tecnologia se tornar disponível.

• Não adianta apenas ficar mudando de emprego, por dois motivos: não necessariamente um novo projeto vai lhe trazer coisas novas (as chances de ser apenas mais um cadastro, são grandes). E deixar para aprender apenas quando já se precisa, em um projeto, já é tarde demais. Você será ultrapassado por outros que sabem o que você já deveria saber. É obrigação de um bom programador saber das coisas antes, não depois: depois que um produto de péssima qualidade entra em produção o resultado será ruim tanto para seu cliente quanto para sua reputação.

• Tente inovar dentro do seu próprio projeto. Não estou incentivando ninguém a arriscar um projeto trazendo coisas tão novas que tem o potencial de explodir no dia seguinte. Sempre existe uma maneira melhor de se fazer o que você está fazendo sem impactar o cronograma nem o custo do projeto. É parte da obrigação de um programador aprender a ser eficiente com qualidade. É preciso muito treino para isso.

• Você se considera um bom programador mas acha que está sendo sub-utilizado? Pois utilize-se melhor: crie ou participe de alguma forma de projetos open source. Essa é uma da qualidades do código-aberto: lhe dar não só a oportunidade de utilizar de graça o que outros fizeram, mas aprender de uma base sólida e lhe dar a oportunidade de contribuir de volta.

• Para de reclamar. Reclamar cria uma mentalidade negativa, irrita os outros e não leva a nenhuma solução. Reclamar é mais uma desculpa, um barulho que esconde o verdadeiro problema. O problema é esse: você está reclamando do trabalho, do projeto, do chefe mas na realidade gostaria de estar reclamando de si mesmo. Reclamar é apenas a externalização da frustração de ser como é e não conseguir ser mais. E isso não é uma incapacidade física, é apenas preguiça mental.

• Esqueça cursos e livros traduzidos. Eles sempre são desatualizados. Nos anos 80 não tínhamos certificações e outras brincadeiras parecidas. Dormíamos com um livro de algoritmos na cabeceira da cama e acordávamos com especificações de uma nova linguagem no café da manhã.

Bons cozinheiros apreciam a boa comida nas férias. Bons engenheiros analisam seu próprio carro durante uma viagem a passeio. Bons artistas desenham suas novas idéias no guardanapo do restaurante. Bons profissionais GOSTAM do que fazem, e não apenas no seu ambiente de trabalho. Isso não significa levar trabalho para casa. Significa apreciar, respeitar e querer aprender mais sobre sua profissão. Da Vinci não precisou fazer cursos. Mozart não precisou fazer cursos. Cursos apenas ajudam aqueles que já estão encaminhados e tem exata consciência do que se quer tirar desse curso.

Quando compro meu iPod quero saber como ele é feito (sabiam que ele usa um HD com gravação perpendicular de bits, o que aumenta a densidade de dados?). Quando um filtro contra spam quero saber como funciona (sabiam que alguns dos mais eficientes são baseados em algoritmos estatísticos Bayesianos?). Quando instalo um sistema operacional preciso saber exatamente como funciona (sabiam que seu hardware novo suporta proteção via DEP mas isso está provavelmente desabilitado no seu Windows? Aliás, alguém aí parou para saber o que é DEP?). Quando uso a rede de terceiros, quero ter certeza que ninguém vai ficar espionando o que estou fazendo (vocês já usaram um servidor externo SSH para criar túneis dinâmicos?). Quando compro uma nova TV quero tirar o máximo proveito dela (alguém aí comprou uma TV de plasma e ligou uma antena nela? Ou pior: ligou seu DVD com cabo composite e não consegue entender porque a qualidade é tão ruim?).

E essas coisas não são apenas curiosidades para conversa de bar. Eu leio muito, quase 100 feeds sobre mais mais diversos assuntos. Mais de 100 posts por hora, todos os dias. Fora dezenas de podcasts, mais um tanto de livros (impressos ou PDFs). E ainda não acho ser o bastante. Certificação apenas pelo mérito de uma linha a mais do seu currículo é o mesmo que nada. Continuo partindo do princípio que profissionais que realmente apreciam – e demonstram isso aprendendo mais e mais – nunca ficarão sem emprego. Já aqueles que partem do princípio de ganhar dinheiro – ironicamente – serão os que terão mais trabalho para conseguir isso.