Redirect

Para conveniência minha, o blog mudou pro Wordpress. Se você é um dos dois leitores do blog (incluindo eu), favor direcionar seu leitor de feeds para http://myidlethread.wordpress.com/

Valeu, Blogger.

Parafusando com martelo

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".

Um futuro ex-analista de sistemas

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.

A apatia é um hit

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.

Avaliação: "The Mythical Man-Month"

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é.

O corredor de saída ou Lições de humildade

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.

Please press the <foda-se> key

Isso que eu escrevi no primeiro post ali embaixo ocorreu no exato instante antes da realidade cair sobre a minha cabeça. Vamos dizer que eu estava suficientemente iludido com algumas possibilidades... ou seria melhor dizer impossibilidades? Nem estou falando de promessas de dinheiro, poder e mulheres. Eu mesmo é que me iludi sozinho.

E não foi difícil criar a ilusão, pois eu tinha um monte de problemas para resolver, uma enorme vontade de passá-los para trás, e ninguém na minha frente para dizer o que eu podia ou não podia fazer. Isso tudo me pareceu completamente estimulante, mas na verdade eu não sabia o quanto eu estava perdido e o quanto a situação estava perdida.

Eu me conheço e tenho essa característica de achar que tenho a resposta para os problemas dentro da minha cabeça, e tudo o que preciso fazer é, simplesmente, colocar as soluções em prática. E mesmo sabendo que essa é a parte difícil, que eu precisaria coordenar vários esforços meus & alheios para algo acontecesse, de vez em quando eu entro no embalo e só um chacoalhão pode me fazer parar pra pensar e ver a merda que está prestes a feder.

Pra ser sincero, a queda na real tinha acontecido na última semana de dezembro -- facilmente a pior semana de trabalho de toda minha vida. Eu me vi responsável por um software condenado a ser uma massa disforme de código, dados, remendos, idéias prematuras, incompetências prolongadas, esforços perdidos. Eu me vi responsável por manter, entregar e evoluir um monstro. Por diversos momentos, pensava: OK, depois de 12 anos de trabalho, é isso o que você faz de melhor?

Eu estava decidido a pedir demissão antes que dezembro acabasse, mas algumas circunstâncias não ajudaram e foi possível começar janeiro com algumas doses extras de otimismo -- infundado, mas otimismo mesmo assim. Relax, just a little pinprick. There'll be no more 'aaaah', but you may feel a little sick.

O post ali embaixo é uma amostra desse estado de espírito "confortavelmente anestesiado".

Mas como eu ia dizendo, em algum momento a merda ia feder. O dito chacoalhão não foi assim um evento súbito, mas sim a mera entrada do mês de fevereiro. Janeiro tinha sido definido como o mês das mudanças, dos estudos, das discussões. Fevereiro já seria num outro esquema. Já seria o fruto do nosso trabalho intelectual de janeiro! Mas enfim, 31 dias se passaram e o produto do "trabalho intelectual" tinha sido a organização (urgente e inadiável -- circunstancial, é a palavra certa) de alguns servidores. Tínhamos estabelecido um roteiro de discussões nos primeiros dias do ano, e esse roteiro não sobreviveu à segunda semana. Eu fiquei muito decepcionado com esse resultado. Sem contar mr. Easy, ninguém mais achou que estava faltando alguma lição de casa pra ser feita.

Claro que o mês de fevereiro, como sempre, trouxe aquela historinha de "trabalho, só depois do carnaval" e com isso alguns projetos periféricos entraram com tudo na ordem do dia. Ou na desordem do dia, que seja. Esses projetos também estavam condenados, por má condução e má concepção. Para atestar a minha incapacidade, eu não tinha participado decisivamente deles. E então ali estava eu novamente no Visual Studio, noites adentro, fins de semana, tentando tirar o atraso, as inadequações do projeto. Até o momento do CHEGA.

Em caso de pânico, aperte a tecla <foda-se>

Pedi férias, interrompi tudo, deixei algumas pessoas de orelha em pé, e fui cuidar da minha vida. Duas semanas depois já estava vendo tudo com outros olhos, com o passado ficando gostosamente distante um dia de cada vez.