Archive Page 2

Resenha: Por que as pessoas de negócios falam como idiotas?

Num mundo onde o jargão e o palavreado vazio são a regra, expressar-se claramente e com objetividade pode ser um tremendo diferencial. Quando todos se esforçam para parecer iguais, ser a exceção garante um lugar de destaque e “Por que as pessoas de negócios…” é um livro que convence a aproveitar-se dessa situação.

O livro é estruturado em quatro partes, cada uma dedicada a uma das armadilhas: obscuridade, anonimato, venda agressiva e tédio. Na maioria das vezes as pessoas querem ser claras, mas o ambiente corporativo que as cerca não é exatamente um meio que as incentiva para isso. Na verdade, o caminho mais natural neste mundinho parece ser exatamente o contrário. Por isso o texto fala de armadilhas, são coisas que nos capturam sem que notemos e das quais ninguém se aproxima de propósito.

Acontece com todo mundo. Tem o gerente que quer parecer mais inteligente que os outros usando algumas palavras difíceis, como “aculturamento”, “objetivar” e “endereçamento”, mas que no fim das contas só deixa de ser compreendido. Qual o problema com “endereço”, afinal?

Tem também o programador sempre ligado na evolução da computação mundo afora que de tanto ler em inglês começa a escrever como se seus textos em português tivessem passado por um tradutor automático dos mais fraquinhos. Parece que o português está ficando obsoleto (ou seria “depreciado”?). O negócio agora é dificultar a compreensão falando portuglês através de expressões como “sistema irresponsivo” ao invés de “sem resposta” ou “comer a própria comida de cachorro” ao invés de “provar do próprio remédio”. Ou até perpetuar traduções tortas como “aplicativo de missão crítica”, que já vem da expressão completamente desprovida de significado “mission critical application” e deveria ser “aplicativo crítico para a missão”.

Muita gente deixa a personalidade em casa quando sai na segunda-feira de manhã e veste um manto de obscuridade disfarçado de profissionalismo junto com a roupa do trabalho. Por causa do ambiente esterilizado da vida corporativa, pensam que precisam deixar aquela pessoa engraçada bem longe e tornarem-se uma versão pausterizada de si mesmos oito horas por dia, cinco dias por semana.

O livro tenta mostrar sempre com muito bom humor quais são as armadilhas mais comuns do discurso corporativo e insiste no argumento de que são exatamente isso: armadilhas. As pessoas não se esforçam para parecer evasivas e vazias de propósito. É bem verdade que às vezes elas querem realmente sair de alguma saia justa, mas isso não acontece todo dia. Portanto, da próxima vez que vir alguém se perdendo com termos esquisitos como “governança” e “missão crítica”, controle a raiva e não ataque ninguém. Ao invés disso, alerte a pessoa para o fato de que talvez os outros não a estejam entendendo muito bem e que talvez seja interessante mudar um pouco o estilo de comunicação.

Por falar nisso, se isso acontecer aqui neste blog, por favor não hesite em avisar. Eu não vou achar que você está sendo implicante nem chato. Prometo.

Pó de estrelas

Parece que Thomas Thurman, um programador envolvido no projeto Metacity, andou falando (ou pelo menos sugerindo) que os astros e estrelas da programação não estão interessados em fazer pequenos consertos. Houve uma discussão interessante sobre esse tema em um dos últimos episódios do LugRadio e os caras citam o Metacity como exemplo de aplicação que não deve parecer muito atrativo para os astros. Para quem não sabe, Metacity é um gerenciador de janelas, um programa responsável, entre outras coisas, por organizar as janelas na tela, decidir onde uma janela vai ser aberta e lidar com redimensionamento e movimentação; ou seja, um programa que quanto mais invisível melhor. Este projeto em particular é tão invisível que nem um website tem. Se você tomar o cuidado de verificar o link que coloquei acima, vai ver que fui obrigado a referenciar um site ftp que contém o código fonte, já que é a referência usada por todo mundo. O raciocínio é que programas de infra-estrutura invisíveis como este não são muito bons para massagear a fama, afinal é difícil ser visto dentro de algo invisível.

Porém programadores não costumam ficar famosos por programar. Então não faz muita diferença se alguém está programando um novo jogo revolucionário ou se dedica seu tempo a escovar bits em um driver para um dispositivo usado por um total de duas pessoas no mundo todo. Eu sei que dizer isso deve ser algum tipo de clichê, mas não posso evitar: programadores famosos não ficaram assim por se preocupar com código, mas por se preocupar com as pessoas.

Isso obviamente não significa que programadores famosos não cuidam do seu código. A maioria deles se preocupa bastante, mas esta não é a razão que os torna admirados por seus pares. Eles conseguem chegar aos pedestais porque tomam o cuidado de compartilhar idéias com os colegas e tornar a indústria toda um lugar melhor para se trabalhar.

Tomemos o Linus Torvalds como exemplo. O cara dispensa qualquer tipo de apresentação, ninguém consegue esquecer o que ele inventou. O que ele escreveu é um núcleo de sistema operacional, algo que, simplificando grosseiramente, só faz se comunicar com o hardware e distribuir tempo de processador e memória para os vários programas que as pessoas querem realmente usar. Ninguém usa o kernel em si, este é só um mal necessário para quem quer rodar programas úteis e é provavelmente o mais longe do usuário final e perto da máquina que se pode chegar. Ninguém nota o kernel trabalhando, assim como ninguém nota o Metacity. As pessoas só notam esses programas quando eles dão pau, se um driver não funciona direito ou se as janelas não querem sair do lugar, por exemplo. O programa do Linus é talvez ainda mais invisível do que o Metacity e mesmo assim ele é um dos programadores mais conhecidos atualmente.

Ele não chegou a este ponto simplesmente por ter escrito um kernel fantástico, mas porque tomou o cuidado de envolver as outras pessoas nisso. Pediu e ofereceu ajuda em listas de discussão, publicou seu código para ser estudado e criticado pelos outros, fez palestras sobre seu modelo de desenvolvimento e até escreveu um livro para contar a história. Ele divulgou uma mensagem e isso fez muita gente crescer junto com ele.

Para alguns exemplos aqui da terrinha vamos considerar primeiro alguns caras que publicam código, como Vitor Pamplona ou o Marcos Tapajós. Da última vez que olhei, o Vitor tinha quatrocentos e vinte e cinco mil, duzentos e noventa e dois projetos publicados como software livre (e o número já deve ter aumentado enquanto eu digitava esta frase). Mas ninguém ia saber quem ele é se não tivesse feito coisas como montar um fórum para reunir a comunidade Java, organizar um blog para escrever textos que ajudassem os outros a se desenvolver e publicar o código dos seus programas para os outros verem. Do mesmo modo, o Tapajós ainda estaria escondido em um buraco em algum lugar se não contribuísse com os outros através de comentários construtivos e se não compartilhasse sua experiência. Eles poderiam gabar-se de como seus programas são maravilhosos em quantas listas de discussão quisessem, se não fizessem nada pelos outros, ninguém iria dar muita atenção.

Não é necessário ter programas famosos para um programador ser respeitado. Um bom exemplo, também brasileiro, é o Vinicius Teles. Ele até andou divulgando um sistema de busca de imóveis misterioso no blog dele, mas acho que ninguém viu ainda o tal sistema até hoje. Também não sei se ele tem algum projeto com o código publicado em algum lugar da Internet. A questão é que eu nem preciso saber. Ele tem o meu respeito — e o de vários outros programadores — porque ajuda seus colegas de alguns outros zilhões de maneiras diferentes como ao publicar entrevistas e até pequenos desabafos em formato de podcast, ao participar em listas de discussão sempre com mensagens detalhadas e esclarecedoras ou até ao organizar conferências das quais não vou poder participar.

Para conseguir reconhecimento e respeito, um programador não precisa só programar muito bem: precisa divulgar seu trabalho. O segredo é que não adianta simplesmente bater no peito e gritar seus feitos aos quatro ventos. Se quiser que alguém o respeite, é preciso ajudar os demais. Ninguém gosta de um sabe-tudo. O crédito que um programador tem dentro de sua comunidade é muito mais uma função do tempo que ele dedica a seus colegas do que do tempo que investe em escrever código.

Testes não são para testar

Um teste é uma verificação feita sobre um programa para garantir que uma determinada entrada produza uma saída esperada. Testes são, de acordo com esta definição (propositalmente vaga), finitos e pontuais. Portanto não podem ser utilizados para verificar completamente a saída de um programa com entradas infinitas. A não ser que se disponha de tempo infinito.

Mas alguém tem tempo infinito?

Como a maioria dos programas úteis têm conjuntos de entrada extremamente grandes (e os infinitos nem são tão raros assim) e tempo não é um recurso muito abundante, testes só podem ser executados para um subconjunto necessariamente pequeno das entradas. Isso limita bastante a efetividade deles como recursos de validação. Não há como verificar se um programa está completamente correto com testes apenas, mas há várias técnicas que podem ser usadas para aproveitar melhor o pouco de certeza que eles podem oferecer. Testes não são perfeitos para validação, mas ainda são a melhor opção disponível.

Para que os testes sejam minimamente úteis, o programa precisa ser escrito com testabilidade em mente. A explosão combinatória pode derrubar os melhores programadores num piscar de olhos. Testar uma função de três parâmetros não costuma ser tão fácil quanto testar duas de dois. Quem quiser escrever testes um pouco menos complicados vai precisar tomar cuidado para não fazer tanta coisa dentro de uma função só. Do mesmo modo é mais fácil testar uma rotina que recebe um parâmetro de um sistema externo como entrada do que uma que faz a chamada internamente.

Estes são exemplos simples de separação de responsabilidades. Talvez sejam até óbvios, mas os defeitos ficam ainda mais destacados quando se está escrevendo o código dos testes junto com o código do programa em si. O maior valor dos testes está aí. Testabilidade é sinônimo de baixo acoplamento, que por sua vez é característica essencial do software bem escrito. Claro que testes servem para verificar corretude, mas somente de código bem feito. Atentar para os testes é mais do que validar saídas para entradas, é garantir que não está escrevendo uma grande bola de código entrelaçada de todos os lados.

Blog novo

Quem costuma acompanhar este blog já deve ter notado que de vez em quando cito Ruby em um exemplo ou outro e às vezes analiso algum aspecto da linguagem. Porém nunca dediquei muito tempo à linguagem, bibliotecas associadas e nem a frameworks interessantes. Nunca escrevi nenhum tutorial, fiz resenha de nenhuma biblioteca nem publiquei novidades sobre Ruby por aqui.

Para estas e outras coisas relacionadas a Ruby vai servir o Minerama. Este novo blog foi uma idéia do João Paulo Lins e estou entrando junto com ele nessa com o objetivo de criar mais um ambiente colaborativo para aprendizado de Ruby (como se já não houvesse milhares). Por “colaborativo” quero dizer que vamos aceitar textos assinados por outros autores. Este é um blog verdadeiramente multi-autor e espero conseguir algumas colaborações bastante interessantes. Por enquanto só há um texto introduzindo os objetivos do projeto, mas não vai demorar para começar a aparecer novidades.

Por fim, não, eu não abandonei nem pretendo abandonar o Mergulhando tão cedo. Apesar de um mês e meio ser um bocado de tempo sem textos novos, pretendo voltar a publicar dentro de uma semana no máximo. Quem preferir pode “ficar no aguardo”, mas fico feliz se você só esperar um pouco. (Notaram como ninguém mais “aguarda” ou “espera”? Todo mundo agora só “fica no aguardo.” Parece que o corporativês vai dominar o mundo mesmo.)

Resenha: The Pragmatic Programmer

Acabei de ler um dos clássicos da literatura de desenvolvimento de software: The Pragmatic Programmer, de Andy Hunt e Dave Thomas. Os nomes na capa não são esses, mas os caras já são figuras tão carimbadas que todo mundo já conhece os apelidos.

Este livro deve ser um dos maiores culpados pela disseminação — e posterior perda de significado — do termo “pragmático”. A essa altura a palavra já percorreu todo o caminho rumo à terra perdida dos termos de efeito. Talvez a intenção original dos autores tenha sido boa, mas a decisão de usar o termo como um tipo de marca registrada (Pragmatic Press, Pragmatic Unit Testing, etc.) com certeza não ajudou a preservar o significado original.

Não é à toa que o livro é indicado pelos melhores programadores que conheço e virou um clássico moderno. A desvirtuação do termo muito provavelmente foi conseqüência disso: muita gente talentosa comentando e muita gente não tão talentosa assim lendo somente o prefácio. Os capítulos são auto-contidos e parecem muito com textos de blogs (e digo isso como elogio). O estilo é bem informal, gostoso de ler e sempre abarrotado de referências relevantes — tanto internas quanto externas (uma das piores coisas do mundo é gente que só faz referência ao próprio trabalho).

As páginas estão repletas de conselhos sábios de dois dos mais geniais praticantes da arte da programação. Lá pode-se encontrar as práticas óbvias que sempre são ignoradas como usar controle de versão para tudo, preferir formatos de texto puro e dominar um ambiente de linha de comando. Além disso há discussões sobre como organizar equipes, sobre linguagens específicas de domínio e, claro, o mundialmente famoso princípio DRY. Não se vê citações de institutos de pesquisa obscuros para provar nenhum argumento. Ao invés disso, tudo é muito bem argumentado com bastante lógica, sensatez e experiência.

O texto é digerível para os novatos sem se tornar entediante para os veteranos. Às vezes é necessário dar um desconto para o tom fundamentalista do texto (o que é um certo paradoxo para algo com o termo “pragmático” no título), mas em geral a relevância dos conselhos é das mais altas. Este certamente é um daqueles livros que todo programador deveria ler e reler periodicamente.

Muletas de papel

Há organizações que se esforçam bastante para ter um processo de desenvolvimento de software determinístico e completamente detalhado. O modo mais comum de realizar isso é confeccionar algum tipo de documento eletrônico (um site interno ou algo parecido) especificando todos os procedimentos que os funcionários precisam seguir, que formulários precisam preencher, com quem devem falar e em que momento espera-se que realizem cada uma das atividades. Em muitos desses lugares o Processo é tratado como um verdadeiro tesouro, o recurso mais importante da empresa, por razões um tanto quanto “pragmáticas”. Pelo menos é o que os responsáveis pelo Processo dizem. Ninguém que pretende ser profissionalmente respeitável vai falar que faz algo por intuição ou crendice.

O Processo teoricamente permite que a empresa aproveite as novas contratações com um mínimo de tempo de treinamento e entrosamento. Com um Processo elaborado, quando um novato chega ele só precisa consultar as escrituras, seguir as ordens, conseguir os mais novos modelos de documentos e preencher as lacunas. A idéia é que, se toda a equipe fizer isso e tiver bastante sorte, no fim das contas vão produzir software útil, interessante e barato.

Mas obviamente isto não costuma passar de uma idéia bem intencionada.

Documentos detalhando tudo o que qualquer funcionário possa um dia precisar fazem todo o sentido para organizações em que novatos inexperientes são maioria. Eles podem começar a produzir mais rapidamente do que se esperássemos o tempo necessário para que se adaptassem e evoluíssem. Eles não precisam perder tempo absorvendo a cultura da empresa, porque a cultura oficial já está escrita e devidamente catalogada. Novatos inexperientes também costumam ficar mais exigentes quando começam a se tornar um pouco menos inexperientes. Um processo bem documentado permite trocá-los por sangue novo quando começam a pedir aumentos e benefícios.

O problema com os processos detalhados e rígidos aparece quando a organização quer ter um relacionamento saudável e de respeito com os funcionários, incentivando e premiando o aprendizado ao invés de puní-lo. O Processo serve como aquelas rodinhas para quem está aprendendo a andar de bicicleta. Elas ajudam a não cair, mas nenhum campeão olímpico cogita usá-las. Depois que as pessoas aperfeiçoam suas habilidades e tornam-se capazes de andar sozinhas, aquela parafernália toda só atrapalha. Como já são experientes, sabem instintivamente o que é importante e podem adaptar o processo padrão conforme necessário sob demanda. Eles conseguem eliminar gargalos e otimizar procedimentos sem muita burocracia e muitas vezes sem nem perceber que estão fazendo isso. Gargalos atrapalham o desenrolar dos trabalhos e costumam ser flagrantemente visíveis, as pessoas eliminam alguns deles todos os dias simplesmente porque as incomodam.

Infelizmente fazer isso fica infinitamente mais difícil na presença do Processo, por causa das diversas lacunas a serem preenchidas e dos procedimentos a serem seguidos. Como tudo precisa ser muito bem pensado, definido e aprovado, não sobra espaço para coisas bobas como instinto e melhoria inconsciente. O triste resultado de todo este esforço de formalização é ver pessoas que poderiam se programadores brilhantes se limitando a domar a burocracia. Não adianta se concentrar em ter o formato dos documentos padronizado se o conteúdo não tem valor. Do mesmo modo, não é possível adaptar o formato a um conteúdo de valor se ele é definido previamente e gravado em pedra por alguma entidade externa à equipe. Planos são úteis somente na medida em que ajudam o planejamento, afinal o importante é realizar a atividade, não produzir o documento seguindo à risca o modelo padrão. O importante é o planejamento, não o plano. A atividade, não o sub-produto.

Os lindos modelos, diagramas coloridos e documentos reluzentes servem como muletas de papel feitas para ajudar quem está mal das pernas. Se pensarmos bem, não há nada mais natural para quem não quer confiar no talento das pessoas. Mas para quem quer andar com desenvoltura e desviar dos obstáculos do caminho, muletas só servem para atrapalhar.

Mais sobre aquele programador Java que você não quer

Houve muitos comentários interessantes aqui sobre meu último texto e alguns deles falavam em algo chamado “lógica de programação”. Um dos leitores comentou que muita gente se limita a aprender uma nova sintaxe, mas continua usando a mesma lógica para programar (*). Ou seja, continua a pensar do mesmo jeito.

Não há sentido em aprender uma nova linguagem assim.

Não existe “a” lógica de programação, apenas “uma” lógica de programação. Quando escrevi o texto anterior era nisso que eu estava pensando, mas precisei de outras pessoas para me abrir os olhos. O importante é que cada linguagem tem uma forma diferente de interpretar a máquina, uma nova filosofia. O que você vai querer aprender é isso, não a sintaxe simplesmente.

Não há grandes ganhos em aprender C# se você já sabe Java, porque o modelo de pensamento das duas é basicamente o mesmo (e conseguir um exemplo foi bem difícil, já que até mesmo neste caso ainda há o que se aproveitar). Mas a lógica para programar é bem diferente se você usar Haskell no lugar de C. Para quem está acostumado com linguagens em que efeitos colaterais são a regra e não a exceção, aprender Haskell dói. É a dor do cérebro ajustando-se a uma linha de pensamento diferente.

Nem precisamos ir tão longe assim para observarmos a dor. Acontece até mesmo quando se passa de C para C++ (por causa das noções de orientação a objetos) e de Python para Io (por causa da orientação a objetos sem classes). A causa disso tudo é a necessidade de absorver uma lógica diferente. Pensar que existe uma única lógica de programação só vai piorar as coisas. Novas linguagens demoram tanto para se disseminar também porque as pessoas acham que já dominam “lógica de programação” há muito tempo e que só precisam se adaptar a uma sintaxe nova. Elas não querem aceitar a dor.

A moral dessa história já foi escrita por Alan Perlis e citada pelo grande Peter Norvig há muito tempo: “Uma linguagem que não afeta seu modo de pensar sobre programação, não é digna de ser estudada.” A conclusão direta disso é que o que devemos procurar em uma linguagem é um novo modo de pensar, não uma sintaxe nova para o antigo.

* Estas não foram as palavras exatas dele, mas acho que é uma interpretação válida



Seguir

Obtenha todo post novo entregue na sua caixa de entrada.