Off Topic: Um Desabafo

Só para variar, este artigo vai ficar meio “filosófico” de novo. Não tenho recursos para uma abordagem rigorosa, com pesquisa de campo e análise estatística de um espaço amostral enorme. Me resta confiar na minha experiência prática e em dados públicos.

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 a mim exatamente com esta proposta: “estou descontente com o que estou fazendo”.

Esses artigos pedem cuidado, porque a maioria traz dados do mercado americano. Este outro, por exemplo, diz que programadores são os mais bem pagos da tecnologia. No Brasil isso não é necessariamente verdade. Aqui o programador ganha o “suficiente”, e quem fatura mais são os analistas (formados nas áreas mais diversas, usando a tecnologia como ferramenta de trabalho). E são justamente esses analistas e consultores, alguns fazendo até R$ 100 mil por ano, que mais reclamam do próprio salário.

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

Deveria haver mais do que isso. Fora da área de programação existem Business Intelligence, 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 grande maioria dos “programadores” faz customizações em processos que já existem. Um departamento quer automatizar o cadastro de funcionários: compra ou cria cadastros próprios. Outro quer um formulário de vendas que alimente o sistema e notifique o parceiro externo para atualizar o inventário. Outro precisa de telas para controlar o fluxo de atendimento a clientes. Cadastros e mais cadastros, sempre alguma variação de cadastro.

Não é à toa que tantos programadores estejam insatisfeitos. Normalmente eles não sabem por quê, mas sentem que algo está errado. E, por favor, não levem nada aqui ao pé da letra. Existem dezenas de projetos interessantíssimos, com algoritmos complexos para tecnologia médica, aeroespacial, engenharia. Estou falando da maioria, não de todos.

Esse ciclo de cadastros é antigo. Desde Cobol, desde os anos 70, o processamento de dados trouxe dinamicidade ao mundo moderno, eliminando toneladas de papel e legiões de burocratas cuja única função era preencher e controlar esse papel. E isso nunca vai acabar, a menos que os computadores fiquem espertos o bastante para dispensar “meros” programadores. Nunca se sabe.

Enquanto isso, o mercado vai continuar precisando dos “programadores de cadastros”. Não importa se você usa Struts, Spring, Rails ou Symfony: vai fazer cadastro de usuários, de clientes, de materiais, de conteúdo, de reclamações, de contratos, de endereços, de fornecedores. A lista é enorme. Principalmente onde a “modernização” ainda não chegou, onde sobram burocratas e os processos ainda não foram estabilizados, muito menos automatizados.

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, surgiram aplicações sedutoras como search engines e webmail, e todo mundo quis fazer um website. Quem inventou TCP/IP, HTTP, HTML, SMTP, POP3 deve ter se divertido muito. Para o resto de nós, sobraram mais cadastros. Tela de e-mail é cadastro. Tela de e-commerce é cadastro. As empresas trocaram as telas de Visual Basic por browsers: cadastros travestidos de páginas Web.

Não é à toa que aparecem tantos frameworks no mercado: Struts, Velocity, Lucene, Jackrabbit, Spring, Guice. Programador de verdade gosta do “plumbing”, do encanamento. A gente gosta de entender como essa malha de código funciona, como otimizar, como tornar estável, como ligar as 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 o Apache Jakarta. Temos brasileiros colaborando em vários projetos open source, mas é uma fração pequena.

Vejo isso pelo caso Rails. Ele surgiu há pouco tempo, e não surgiu nos EUA. Mesmo assim se alastrou rápido por lá. 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 já são poucas). 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” vendeu dezenas de milhares lá fora. Deixando de lado qual livro é “melhor” ou “pior”, as vendas meteóricas, as dezenas de outros títulos lançados lá e o fato de o meu ainda ser o único aqui são um termômetro da diferença de cultura, tanto do mercado quanto dos programadores.

Tudo bem, tivemos um período negro de mercado fechado e anos de atraso. Mas hoje não vejo motivo para os programadores, principalmente os mais jovens, serem tão apáticos em relação à tecnologia.

Nessas horas sinto falta do fim dos anos 80 (é a época que eu vivi; quem é mais experiente vai sentir o mesmo sobre o fim dos anos 70). Éramos muito poucos, e era raro encontrar um programador ou pelo menos um entusiasta. Mas pensávamos diferente.

Mesmo em meados dos anos 90, pouco antes do boom da internet, meus amigos e colegas eram todos apaixonados por tecnologia. A gente conversava sobre o que havia de novo, o que cada um tinha aprendido, o que estava testando. Trocávamos ideias, discutíamos técnicas, e o objetivo era sempre aprender mais. Conheci gente cujo hobby era escrever pequenas animações em Assembly. Outros compravam componentes eletrônicos para montar o próprio MP3 player (não existia iPod na época). Alguns passavam horas fazendo ferramentas para essa tal de “internet” que ainda era novidade. Eram bons tempos.

De repente, o mercado brasileiro de informática explodiu, por diversas razões. De repente, muita gente viu na área uma maneira rápida de ganhar dinheiro. De repente, as faculdades ficaram lotadas de garotos aprendendo ferramentas em vez de tecnologia, saindo tecnólogos em sistemas de informação onde antes saíam bacharéis em ciência da computação. De repente, todo mundo “sabia” Java. E, finalmente, o mercado saturou de “programadores”.

Agora, tudo que ouço dos atuais “programadores” é “qual linguagem você acha que eu deveria aprender que vai dar mais dinheiro?” Dá para imaginar como isso é frustrante para mim, que já me sinto da velha guarda. Nunca pensei no custo-benefício do tempo de aprendizado. Sempre considerei que aprender era algo constante; se eu ganhasse dinheiro no processo, melhor, mas nunca foi o principal.

Por causa do atual estágio de aberração do mercado, presencio coisas que me dão medo. Num certo cliente, “integraram” o sistema de vendas com o de ativação de um equipamento. A lógica é simples: feita a venda, o equipamento do consumidor deveria ser ativado. Mesmo sem uma solução de two-phase commit (todos sabem o que são transações atômicas, certo?), o requisito pedia salvaguardas para garantir isso.

Obviamente não existia salvaguarda nenhuma, e ninguém nunca questionou: nem os programadores, nem os analistas e, claro, muito menos os gerentes. Resultado: hoje há várias pessoas empregadas cuja única função é formatar planilhas com os erros e corrigir manualmente. Mais cadastros foram criados para lidar com esses erros. Houve ganho de automação no projeto? Claro, mas muito menos do que deveria. E ninguém liga. Já vi coisas piores.

Me entristece ver como o grosso dos programadores e toda a cadeia acima (programadores que viraram analistas, programadores que viraram gerentes) tem tão pouco conhecimento e, por consequência, cria arquiteturas e soluções tão pobres.

E retorno às indagações que me fizeram: o descontentamento com o que fazem, a sensação de não aproveitar o “potencial”, a vontade de aprender algo novo para ganhar mais dinheiro. Não tenho respostas para isso porque não consigo pensar assim. Mais do que isso: acredito que essas perguntas são fundamentalmente erradas. E pergunta errada não tem resposta certa.

Eu tento disseminar a cultura que conheci quando era um jovem programador: aprender. As desculpas que ouço são sempre as mesmas: “não tenho tempo para aprender quando preciso trabalhar para me sustentar”, “não sei ler inglês, por isso preciso fazer cursos e só posso aprender uma coisa de cada vez”, “não adianta 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 de desculpas.

Faz parte da natureza humana não querer sair da zona de conforto e, pior, reclamar quando se torna obsoleto. “A culpa é do governo”, “a culpa é do capitalismo”, “a culpa é do meu chefe”. Mais desculpas.

Quando escrevi meu livro, fiz por 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, na realidade brasileira, não pensar em dinheiro não é uma opção. Eu encontrei um equilíbrio entre as duas coisas, e não vejo por que mais ninguém conseguiria. Ficar parado, sentado no pouco que aprendeu tempos atrás, reclamando sem parar, nunca levou ninguém a lugar nenhum.

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

• Quanto mais se aprende, melhores serão suas soluções. O cliente sabe reconhecer um profissional que sabe do que está falando, e todo mundo percebe quando alguém está só enrolando.

• As demandas que mais vão crescer são 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 num curso não vai ajudar.

• O ciclo de tecnologia está cada vez mais curto. Antes uma nova versão levava anos para sair; hoje leva meses. Quando você sair do curso, o que aprendeu já está obsoleto. Lide com isso. Adiante-se. Aprenda o máximo possível antes mesmo de a tecnologia ficar disponível.

• Ficar pulando de emprego não resolve. Um projeto novo não necessariamente vai trazer coisas novas (as chances de ser só mais um cadastro são grandes). E deixar para aprender quando já precisa, dentro do projeto, é tarde demais: você será ultrapassado por quem já sabe o que você deveria saber. Um bom programador se adianta e aprende antes de precisar. Depois que um produto de péssima qualidade entra em produção, o resultado é ruim para o cliente e para a sua reputação.

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

• Você se considera um bom programador mas se acha subutilizado? Então se utilize melhor: crie ou participe de projetos open source. Essa é uma das qualidades do código aberto: usar de graça o que outros fizeram, aprender de uma base sólida e ainda ter a oportunidade de contribuir de volta.

• Pare de reclamar. Reclamar cria uma mentalidade negativa, irrita os outros e não leva a solução nenhuma. Reclamação é mais uma desculpa, um barulho que esconde o problema real. E o problema real é este: você reclama do trabalho, do projeto, do chefe, mas quem você queria reclamar é de si mesmo. Reclamar é a externalização da frustração de ser como é e não conseguir ser mais. E isso não é uma incapacidade física: é preguiça mental.

• Esqueça cursos e livros traduzidos: estão sempre desatualizados. Nos anos 80 não existiam certificações e brincadeiras do tipo. Dormíamos com um livro de algoritmos na cabeceira e acordávamos com a especificação de uma linguagem nova no café da manhã.

Bons cozinheiros apreciam boa comida nas férias. Bons engenheiros analisam o próprio carro numa viagem de passeio. Bons artistas desenham ideias novas no guardanapo do restaurante. Bons profissionais GOSTAM do que fazem, e não só no ambiente de trabalho. Gostar aqui quer dizer apreciar, respeitar e querer aprender mais sobre a profissão, o que é bem diferente de levar trabalho para casa. Da Vinci não precisou fazer cursos. Mozart não precisou fazer cursos. Curso só ajuda quem já está encaminhado e tem consciência exata do que quer tirar dele.

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 antispam bloqueia algo, 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 ele funciona (sabiam que seu hardware novo suporta proteção via DEP, mas isso provavelmente está desabilitado no seu Windows? Aliás, alguém parou para saber o que é DEP?). Quando uso a rede de terceiros, quero ter certeza de que ninguém vai espionar o que estou fazendo (vocês já usaram um servidor SSH externo para criar túneis dinâmicos?). Quando compro uma TV nova, quero tirar o máximo proveito dela (alguém aí comprou uma TV de plasma e ligou uma antena nela? Ou pior: ligou o DVD com cabo composite e não consegue entender por que a qualidade é tão ruim?).

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