«Idle Thread»

Muito tem sido falado a respeito da persistência do IE 6 como browser favorito de algumas de pessoas. Confesso que forço a barra no “algumas”, porque, dependendo de quem fornece os dados, o IE 6 permanece uma opção para quase 40% dos usuários. Tal permanência não dá sinais de esgotamento fácil. Vejamos os números do site TheCounter.com, que registra cerca de 7300 hits por hora provindos das páginas que incorporam seus serviços de estatísticas de acesso:

Uso dos três principais browsers, de agosto/2007 até junho/2008

Desespero geral na comunidade de desenvolvimento de software! O clima é de indignação: “como é que esses usuários conseguem usar um navegador desses? Sem suportar direito CSS, JavaScript? Isso é um absurdo! Salvem-nos!”

Colegas desenvolvedores, cabe agora um… momento de reflexão. Especificamente, reflexão sobre o mundo não-rosa onde nós sujamos a mão de graxa diariamente para facilitar a vida do usuário.

Antes, só para contextualizar, digo que o browser ultra-ultrapassado de hoje já foi, indisputavelmente, a melhor opção para o desenvolvimento de aplicativos para web. Lá em 2001 a coisa estava começando a deixar de ser realmente feia no mundo dos browsers: a Microsoft tinha passado o trator em cima da Netscape alguns anos antes, e esse trator tinha sepultado de uma vez por todas o monolítico, atrasado, bugado pra caralho, Netscape Communicator 4.0. A vida que prometia ser dura em 1998, com o programador se lascando pra deixar qualquer coisa minimamente uniforme nos “dois browsers”, já parecia muito mais confortável em 2002, quando a plataforma mais disseminada era, ainda por cima, funcional, extensível, rápida e estável. Obrigado, Microsoft.

O tempo passou e, como todo monopólio que se preste, a Microsoft relaxou com o IE. Pode ser que já então ela estivesse toda enrolada com o Vista e não se dispusesse a atualizar seu browser só porque umas ONGs tecnológicas estavam reclamando suporte a uns padrões esotéricos. “Usuário final não tá nem aí com teste ACID”, podem ter pensado. Ou ainda, “web standard é quando uma implementação atinge 90% dos consumidores”. Até aqui, suposição minha. O fato é que quase 5 anos se passaram até que o IE 7 fosse lançado. E desse momento em diante o desenvolvedor tem um problema: cadê o trator que poderia sepultar o legado do IE 6?

O trator, ironicamente, se chama Windows Vista. Houvesse uma migração em massa para o novo sistema, como ocorreu do Windows 9x para o XP, a coisa seria diferente. Mas agora “o mercado” não exibe mais aqueeela disposição para fazer um upgrade, seja pela dúvida tecnológica ou pelo comodismo. E isso se aplica aos browsers também: se está funcionando, por que eu preciso mudar? Muito complicado esse negócio de computador. Prefiro deixar assim, podem muito bem pensar os usuários. Agimos assim o tempo todo com o carro, com a casa, até com a própria saúde. Para o cidadão comum (aquele que só usa Alt para Ctrl+Alt+Del), o browser é uma preocupação a menos na vida. Tanto faz se suporta PNG transparente ou CSS 2 do jeito que o W3C mandou. Entrou no Orkut? Abriu o internet banking? Carregou o YouTube? Tá ótimo.

Agora, a reflexão. Uma campanha para sepultar o IE 6 é bobagem. Ignorar a existência dele é prejudicar o usuário de propósito. Tudo isso funcionaria se a grande massa fosse consciente de coisas que, na boa, só têm cabimento para desenvolvedor de software. Poucos além de nós vão associar um erro de script ou um box desalinhado à obsolescência do browser. Aposto que a maioria nem vai perceber.

E se você desenvolve sites como quem projeta um foguete intergaláctico, agregando o estado da arte da tecnologia, isso é problema só seu. Não espere que o resto da humanidade use a mesma tralha cibernética que você. Ou melhor ainda, espere sim e veja o que acontece.

A linha dos web standards indica apenas para onde devem convergir os esforços de desenvolvimento das aplicações. Não garante 100% de uniformidade entre os browsers, sejam eles da Microsoft ou da Mozilla ou de quem for. Em outras palavras: extensões proprietárias, ajustes, frameworks JavaScript e gambiarras vão continuar existindo. Assim como browsers ultrapassados e usuários que não manjam de coordenadas X e Y em CSS.

Pela segunda vez em menos de 4 meses, vou mudar de emprego. E, por motivos diferentes da ocasião passada (já comentada por aqui), pedir demissão também foi muito chato. Conversando com meu atual chefe, acho que não me justifiquei bem, devo ter demonstrado um puta nervosismo, enfim, não foi a coisa tranqüila que devia ser.

Eu podia interpretar a situação da maneira mais profissional e impessoal possível, observando apenas o fato de que, no novo emprego, eu vou começar a reposicionar a minha carreira numa direção muito mais favorável e confortável. Uma direção tecnologicamente melhor, financeiramente melhor, com responsabilidades mais ao encontro do que eu quero fazer. E eu vou entrar num ambiente mais familiar, já que muitos ex-colegas trabalham lá. Então, sob o ponto de vista profissional, eu não tinha outra escolha. Não tem como o meu trampo atual cobrir o conjunto da oferta.

Mas mesmo assim, me incomoda ter que deixar um projeto difícil e por isso mesmo interessante, numa plataforma complicada e por isso também interessante, com pessoas de outra geração de sistemas, difíceis e interessantes. Acho que é uma sensação parecida com a de um aborto. Em poucos dias tenho que interromper tudo, amarrar as pontas soltas, e seguir em frente. Não estou acostumado a fazer isso, e espero não precisar de novo.

Uma coisa triste em especial é que talvez essa mudança signifique a minha aposentadoria na linguagem C++. Primeiro, porque cada vez menos vou conseguir conciliar programação e condução de projetos. Eu preciso partir para desafios diferentes de gestão, e isso significa abandonar um pouco do conforto de programar. E segundo, ainda que C++ seja algo que escolheria para a vida toda, não há a oportunidade. Eu provavelmente ficaria fechado em um nicho de mercado, e não tenho segurança financeira para me estabelecer assim.

Essas considerações e algumas outras coisas me falam alto. Mas mesmo com a bola murcha, tenho a certeza de estar fazendo a coisa certa. E isso me fala mais alto ainda.

Tenho uma sensação ruim (vergonha mesmo) toda vez que relembro o fato de que passei cerca de 12 anos sem conhecer o valor da palavra const. Vergonha por dois motivos. O primeiro é que eu sempre tratei a keyword com desleixo*. O segundo é pela constatação de que sempre tem alguma coisa muito importante que eu deixo de lado na profissão.

Como já falei antes, eu não tive assim um treinamento formal em programação ou análise de sistemas (descontando as aulas de Pascal no 2° grau técnico). Eu fui aprendendo com o tempo, seja arrumando trabalho pra fazer, seja por diversão. (É, eu já programei por hobby.) Nessas de ir aprendendo sozinho, fui adentrando a carreira e hoje não posso pensar em fazer outra coisa para viver, mesmo porque passaria fome.

O que isso tem a ver com const? Bom, a pergunta devia ser: o que const tem a ver com isso? Resposta: não tem nada a ver, e é esse o ponto. Você não arruma problemas sérios na profissão se não souber o significado de const. const não vale em tempo de execução. Se o programa vai funcionar ou não, dificilmente será por uso ou desuso de const.

Vou fazer uma comparação com o Português. Você não depende de saber o que é um verbo transitivo direto para viver. Você pode se comunicar perfeitamente por escrito sem usar crase direito. Ou pode ficar abusando do gerúndio à vontade, OK. Mas o que esses exemplos deixam claro é que a pessoa que os comete não tem domínio sobre a linguagem, sobre a lógica da língua portuguesa. São erros na expressão, no encadeamento de palavras.

Espero que a comparação com o Português pareça só ilustrativa, porque para mim a ignorância a respeito de const é mais grave do que não saber fazer análise sintática. Programação é uma forma de comunicação na qual a capacidade de expressão do emissor (programador) é 100% responsável pela precisão da mensagem (programa) recebida pelo ouvinte (computador). No Português a expressão pode ser ruim porque o ouvinte interpreta a mensagem corrigindo e completando os seus eventuais problemas.

Mas como o computador ainda não é tão esperto, a obrigação do desenvolvedor é procurar ininterruptamente melhorar sua capacidade de expressão, aprendendo a sintaxe da linguagem e quantos “dialetos” (idiomas) aparecerem na frente. Eu tenho me dedicado a isso neste ano e tenho certeza de que meu código melhorou, porque:

• eu já não uso tantos casts
• estou menos dependente de pointers
• agora relaciono objetos levando em conta efeitos colaterais
• estou mais preocupado com a forma do código, e não só com a função do código

O principal é a postura diferente em relação à linguagem. Dá para construir um programa de mil maneiras diferentes, do mesmo jeito que é possível fixar um parafuso com um martelo ou com araldite. Do momento em que são conhecidas as características do parafuso, da madeira, do martelo e principalmente da chave de fenda, você se pergunta: como é que eu conseguia trabalhar antes?

———————————–
*Na maioria dos casos eu fazia um cast qualquer sem pensar no significado do const que estava ali me “atrapalhando”.

No começo do meu envolvimento com a informática, lá pelo início da década passada, eu tinha uma bronca com os chamados analistas de sistemas. Para aquela antiga instância de mim mesmo, os analistas eram as pessoas que elaboravam e negociavam os equívocos que seriam, posteriormente, construídos tijolo por tijolo pelos vassalos programadores, que, ao final da história, nunca levavam a glória, mas sempre a culpa pelos eventuais problemas. Claro que eu me incluía junto aos vassalos, únicos detentores do talento genuíno da arte de escrever software.

O tempo passou, e eu fui vendo que a história não é bem assim. Criar um modelo de sistema e supervisionar o seu desenvolvimento tinha lá o seu charme também, além de pagar mais. Comecei até a achar que uma pessoa unicamente programadora tinha algo incompleto na carreira, uma espécie de inadequação para as tarefas mais abrangentes e multidisciplinares. (O tempo ia me provar errado novamente depois, mas essa é outra história.) O fato é que eu aceitei muito bem a minha transformação em analista de sistemas. E assim permaneci até hoje.

Um mero detalhe é o fato de eu não ter cursado nenhuma faculdade de “sistemas”: Ciência da Computação, Engenharia da Computação, Análise de Sistemas, Processamento de Dados, ou qualquer outra. Eu até tenho curso superior (incompleto) em Administração de Empresas, o que certamente não me habilita a fazer nada além do que eu já faço: pensar, programar, entregar. Quando eu digo mero detalhe, é literal: exceto nos momentos de troca de emprego, não sinto falta de um diploma pendurado na parede (ou no fundo da gaveta). Qualquer diferença que eu sinta em relação a outro profissional vem da comparação do talento, conhecimento e experiência que temos. Nunca do título estampado no diploma do nobre colega.

Pois eis que hoje (olha que desinformado) fiquei sabendo que tramita no Senado Federal uma grande sacanagem (bom, lá é o lugar dessas coisas mesmo): um projeto de lei para regulamentar a profissão de Analista de Sistemas. Pra quem não quer sujar seu browser indo até o site do Senado, um resumo: o excelentíssimo senador Eduardo Azeredo (aquele do mensalão mineiro) sugere que apenas aqueles ilustres bacharéis graduados em computação & correlatos podem ganhar a vida denominando-se Analistas de Sistemas. Pronto, é o meu fim, pensei.

Ou não!, pensei de novo. Eu posso criar uma subclasse de Analista de Sistemas, ou uma classe irmã, ou até mesmo todo um novo framework curricular só pra mim. O que me traria grandes problemas empregatícios, já que nenhuma empresa iria precisar de quadros tão específicos. Sejamos genéricos então. Eu abandonaria o título de Analista de Sistemas, se fosse possível migrar para uma das seguintes profissões, felizmente ainda não regulamentadas:

• Produtor de Sistemas: assim como um produtor musical, eu poderia me dedicar à organização dos componentes de um sistema de modo a extrair o melhor resultado possível, ou apenas o resultado desejado, se assim for. Por mim, seria uma profissão bacana e hypada, garantia de dinheiro e fama.
• Tradutor Português-Assembler: na prática, no fundo, é isso o que acontece né? O cara te pede: “Quero poder imprimir direto daquela tela”, e você diz o mesmo para o computador, só que em outras palavras.
• Bacharel em Aprendizado com ênfase em (insira plataforma aqui): afinal, você pode até sair graduadíssimo da facul e louco para trabalhar regulamentado, mas terá a obrigação de, até o fim dos seus dias, aprender continuamente coisas novas que serão descartadas pouco tempo depois. E você será pago por isso.
• Empresário de Sistemas: você abre uma empresa e contrata a si mesmo (sem exigir diploma). Sua empresa viverá de fazer sistemas sob contrato. As empresas contratantes nem precisam saber que, do outro lado, quem faz tudo é um sub-graduado, um técnico, um curioso qualquer. Tanto faz, pois é interessante em termos fiscais: as leis trabalhistas estão cada vez mais inadequadas mesmo, e não tem senador se mexendo nesse sentido.

Começo a ficar feliz em deixar de ser um Analista de Sistemas.

Nós, profissionais de TI (ou IT, pra quem gostar mais), gastamos boa parte do tempo mudando nosso jeito de trabalhar para que possamos acompanhar os movimentos do mercado — especialmente o de trabalho, se você é como eu e não tem onde cair morto. Qualquer um que passe dois anos entretido com a informática percebe o fluxo de novidades, modas, big players e big losers que vêm e vão incessantemente. Tirando o COBOL, pouca coisa veio para ficar na boa e velha tecnologia da informação.

No meio de tantas (propaladas) mudanças de paradigma persiste um modelo de comportamento, uma erva daninha coletiva, que eu não resisto em dizer que é um grande sucesso da informática: o desinteresse, a apatia que os trabalhadores do ramo desenvolvem com o passar do tempo. Pode observar: o gestor cínico de hoje foi o programador passional há vinte anos. O cara que não quer mudar nada agora tinha uma cabeça fervilhando igual à sua, não muito tempo atrás.

Claro que existem programadores apáticos de 19 anos e gestores muito dinâmicos com 45 anos ou mais. Mas eu me atrevo a dizer que são exceções. E se me permitem voltar ao assunto principal, quero entender o que é que sustenta o sucesso do cinismo. Não pode ser motivação pessoal: “o meu sonho é ficar totalmente apático em 15 anos!”

As pessoas que têm o maior poder, hoje, nos nossos ambientes de trabalho, são, em grande parte, desconectadas de qualquer coisa que represente mudança ou melhora. No máximo elas fazem um curso para melhorar alguma habilidade ou algum “processo”, seja para não ficar “desatualizado”, seja por pressão das empresas. Estão condicionadas a esperar soluções prontas que ou têm efeito imediato ou não prestam. Estão, em português claro, de saco cheio. Qualquer sinal ou sugestão de melhora que implique empenho pessoal genuinamente interessado e disciplinado é encarado como uma futilidade, uma ingenuidade, algo que “claro que não vai funcionar”.

Eu tive essa reflexão depois de pensar um pouco sobre o livro aí embaixo (The Mythical Man-Month) e também sobre outras leituras por aí. Existem literalmente toneladas de bom senso que podem ser facilmente digeridas por qualquer um. E as pessoas insistem em achar que não dá certo, não se aplica, ninguém faz isso, é muito difícil… e demais evasivas ainda mais fracas. Ficam desconfiados de tudo, ou acham que tantas boas idéias não passam de teoria — e que na prática, a teoria é outra. (Essa é a pior de todas.)

Admito que bate um desespero ao saber que, do lado de fora do guarda-chuva da metodologia, existe uma tempestade de equívocos e más-intenções no seu cliente, parceiro, concorrente e até no seu círculo imediato de trabalho. A metodologia, qualquer uma, é frágil demais, é o vinho que, ao ganhar uma gota de água suja, já não presta. Talvez o tempo vá nos revelando que estamos cada vez mais sozinhos na nossa boa-vontade. Talvez o cinismo seja menos um sinal de covardia do que uma forma de atravessar a selva sem ser liquidado.

Eu gostaria de ver colaboração como regra, e não caso isolado. Mas desconfio que estou querendo demais. Acho que estou me deixando levar pelo idealismo. O que é isso, nem parece que eu tenho 30 anos.

Possivelmente o mais célebre livro sobre engenharia de software — e admito que foi essa celebridade que me levou a lê-lo –, este foi comprado por mim num surto de auto-aprendizado a respeito de gerenciamento. A empresa estava passando pela fase “consultoria externa para revertermelhorar apocalipseprocessos e eu estava participando centralmente. Ou pelo menos acreditava que sim. Nessa época comprei uma penca de livros, dentre eles O Mítico Homem-Mês.

Mencionei o contexto do meu interesse pelo livro porque isso foi determinante no que eu extraí dele. A cada página, Fred Brooks, com décadas de antecedência, descrevia o inferno que eu atravessava. O que, no início da leitura, me deixava intrigado: se isto tudo foi verdade 30 anos atrás, o que acontece HOJE para que os mesmos problemas se perpetuem?

É como se ainda estivéssemos tentando erradicar uma doença que já fora diagnosticada décadas antes. Só que não estamos lidando com medicina ou pesquisa “tradicional”. Estamos lidando com software — tão dinâmico, não? –, onde supostamente as coisas acontecem mais rápido. A natureza do software — “pure thought stuff”, diz Brooks — deveria, na minha leiga opinião, permitir evolução mais rápida e certeira.

Ao avançar a leitura, porém, entendi que o problema do desenvolvimento de sistemas está menos na natureza do software do que naquilo que existe ao redor dele, a saber: comunicação entre os interessados. O problema central do projeto de software é a qualidade da informação que trafega entre desenvolvedores, gerentes, vendedores e clientes.

O título do livro já entrega o jogo: as expectativas que se estabelecem são falsas. O resto deste parágrafo é opinião pessoal derivada disso: ingenuamente ou por má-fé, o projeto de software é uma arena onde os interesses mais díspares sugam muito da atenção que deveria ser aplicada na realização do que Brooks chama de “value to customers” — os resultados concretos do projeto. Quais interesses? Políticos, do lado gerencial (seja no cliente ou no fornecedor de software). Corporativos, do lado dos desenvolvedores. No intervalo, um monte de gente preocupada unicamente em sair da reta. Não há interesse concentrado e ordenado em se considerar, sempre em primeiro lugar, a solução do problema que originou o projeto.

E se o fator humano não ajuda, tampouco adianta apelar para que o software, por si, dê origem à solução mágica (”silver bullet”), algum dispositivo que permitisse ganhos de magnitude na qualidade e no desempenho do desenvolvimento de sistemas, da mesma forma que a indústria de hardware consegue ganhos exponenciais na qualidade e no desempenho dos seus produtos. Brooks analisa algumas silver bullets — melhores ferramentas, geradores automáticos de sistemas, inteligência artificial, orientação a objetos, entre outros — para profetizar a impossibilidade desse dispositivo (ao menos enquanto valerem as circunstâncias em que ele escreveu). Pois o que move a roda, enfim, somos cada um de nós, nossas necessidades, caprichos e restrições. Se conseguíssemos mecanizar essas condições, quem sabe poderíamos evoluir o mecanismo e, assim, gerar os tais ganhos de magnitude. Mas, é óbvio, somos imprevisíveis, e é aí que reside o problema da mecanização. Então, no silver bullet.

O livro contém muito mais do que análises de problemas. É um condensado de observação prática, opinião, bom senso e rigor, escrito com simplicidade e humildade. É muito bem vindo, inclusive quando o autor se concentra em detalhes técnicos ultrapassados — no mínimo você sai conhecendo melhor a história da computação, contada por um dos protagonistas. Ah, você não tem tempo para essas coisas, né.

Sair do meu ex-trampo não foi complicado. Eu já estava me sentindo um fantasma naquela empresa, já não tinha nenhuma participação decisiva em nada. Exceto, claro, nas emergências softwerísticas ou situações-limite propulsionadas por fatores que, OK, vou poupá-los dos detalhes. Como eu ia dizendo, já estava ali sobrando mesmo, falei que estava caindo fora e arrumei outro trabalho.

Arrumar outro trabalho significou investir um bom esforço na elaboração (palavra exata) de currículo, tentativas de contato com colegas e ex-colegas, sem falar na cabeça 100% voltada para as expectativas vindouras. Será que vão me retornar? Será que eu fui bem na entrevista? Será que eu pedi pouco? Será que eu pedi muito? Aquela ansiedade pré-adolescente.

Ansiedade alimentada por uma série de impressões erradas a respeito de mim mesmo e das minhas capacidades. Eu acreditava ser um profissional de muito valor, mas não é bem assim. Eu estou muito, muito longe disso, a despeito das minhas qualidades. (Algum dia eu posto a respeito delas.) Tenho passado por boas lições de humildade, que corrigem algumas presunções encalacradas na minha noção de “carreira”:

1. Eu não sou um bom programador em C++. O fato de eu ter me envolvido, por bastante tempo, em projetos ligeiramente complexos (leia-se: multithreading e integrações chatinhas) implementados em C++, não quer dizer, de jeito algum, que eu seja proficiente na linguagem ou que domine as ferramentas, construções, sintaxes, libraries, padrões e convenções conhecidos de trás pra frente pelo programador C++ mediano (ou medíocre, tanto faz).

   Atualmente estou começando a escalar a curva de aprendizado que, em algum dia, vai permitir que eu diga, sem constrangimento, que eu sou um programador em C++.

2. Eu sou baby-boomer do desenvolvimento web. Dizer que eu já dormia com a mãe do <DIV> há 12 anos não é distintivo pra nada. É antes um sinal de senilidade, como a barriga de chopp depois dos 30, ou pêlos na orelha. Eu estou totalmente por fora da Web. Teria que aprender um monte de coisas de novo.

   Quando eu surfava na onda da tecnologia Web, o Java estava na versão 1.2, havia guerra dos browsers, falava-se em applets e cgi-bin, o formato GIF pertencia à Unisys e no rádio tocava Bittersweet Symphony. Pra ficar numa gíria idosa, muita água passou pela ponte.

3. Eu sou fraco em engenharia de software. Por mais que a palavra metodologia provoque uma ereção mental em qualquer pessoa minimamente ambiciosa no setor informático, parece que a coisa real só é praticada mesmo por meia dúzia de afortunados, que depois vão contar vantagem em seus blogs. Eu fico só lendo os relatos e imaginando se um dia vai acontecer comigo também. Por enquanto, mal encostei na engenharia de software. Se eu quiser penetrar nela, vou precisar ser muito menos vacilante.

Este não é um post de chororô ou auto-humilhação. Escrevo essas coisas porque elas facilitam a minha vida, me dão rumo, me tiram da água parada. Eu corro na direção da dúvida. Se você me conhece e algum dia me perceber cheio de certeza, pode crer que eu não estou numa fase boa.