Mergulhando no Caos

Eu definitivamente não estou entre os mais antigos praticantes da indústria do desenvolvimento de software, mas já vi alguns fenômenos se repetirem o suficiente para desconfiar que devem ser alguma espécie de lei universal ou coisa parecida. Como sou um fanático por linguagens de programação, minha observação está nesse campo. Mais precisamente nas comunidades que se formam ao redor delas. Eu sei que comunidade é meio que uma palavra da moda hoje em dia, então pode abandonar este texto e passar para o próximo da sua lista de leitura de feeds de hoje: isso aqui certamente vai ser bem vazio e superficial.

Assim como qualquer coisa, linguagens de programação também passam por um período de maturação antes de se tornarem populares. No início elas só são usadas por verdadeiros geeks de linguagens que se divertem em procurar não a próxima grande revolução, mas boas idéias em termos de expressividade. Muitos deles nem chegam a usar direito as linguagens, preferindo aprofundar-se em uma e só ficar de olho em outra meia dúzia.

A maioria dessas pessoas atraídas nessa fase embrionária são programadores excepcionais e começam a ajudar a fazer várias das bibliotecas que vão servir de apoio para as massas que virão a usar a linguagem dali a alguns anos. Eles não fazem isso porque querem ser os senhores daquelas pequenas comunidades no futuro, mas simplesmente porque gostam e se divertem com isso. Afinal de contas, o que pode ser mais divertido do que fazer seu próprio cliente HTTP, por exemplo?

Não precisa responder.

Quando estão nesta fase, as listas de discussão, blogs e fórums sobre essas linguagens costumam ser bastante interessantes. O cara que está fazendo o cliente HTTP conversa com o cara que está tentando melhorar a biblioteca de coleções e todos têm idéias boas para dar. Toda semana alguém bola uma nova expressão idiomática elegante e você se impressiona cada vez mais. Começa a surgir o sotaque da linguagem.

Contraste isso com o que costuma acontecer cinco a dez anos depois se a linguagem chegar a se tornar popular. Neste ponto as listas de discussão começam a se repetir e parece que todo mundo só quer saber como redimensionar uma imagem para mostrar numa aplicação web.

Hora de partir para a próxima linguagem…

Não sei exatamente porque, mas as comunidades pequenas funcionam melhor. Talvez porque os geeks iniciais sejam simplesmente mais interessantes do que a horda de invasores que só querem “fazer um sisteminha” e usar a nova linguagem da moda. A linguagem não costuma mudar muito neste meio tempo. O sotaque usado pelos mais antigos continua mais ou menos o mesmo, mas a comunidade cresce. Com o aumento do número de participantes, qualquer um esperaria que aumentasse a quantidade de boas idéias. Mas ao invés disso, elas parecem diminuir. Ao invés de serem um grupo organizado de pessoas, as multidões se comportam mais como uma manada de touros: ficam pastando no mesmo lugar até que alguém resolva correr tresloucadamente para um lado, hora em que todo mundo decide fazer o mesmo e que alguns são atropelados no meio do processo.

Quando comecei a me interessar por Ruby, era bastante instrutivo acompanhar a ruby-talk. Dava pra distinguir facilmente a voz de gente como Jim Weirich e Hal Funton. Agora, três anos e várias reportagens em grandes revistas depois, tudo o que se vê nos mais variados fóruns da linguagem são as mesmas perguntas sobre como estabelecer relacionamentos NxN. Pelo menos a comunidade Ruby ainda não chegou na proporção da Java, onde encontra-se facilmente gente tentando desenhar diagramas de seqüência para qualquer porção de código que precise ser escrita.

Há coisas que fazem bem para uma linguagem de programação e ser citada em revistas de grande circulação não é uma delas. Isso com certeza faz com que mais gente tome conhecimento, mas as pessoas que importam já haviam sido apresentadas à tecnologia por outros meios. Estas são as pessoas que lêem, pesquisam e estão sempre tentando permanecer atualizados em relação a sua arte. Muito antes dos grandes canais descobrirem as novas tecnologias, elas já sabiam delas através de canais mais alternativos (e mais rápidos e vibrantes) como blogs, listas de discussão e fóruns. São essas pessoas que têm as idéias brilhantes, que escrevem as primeiras bibliotecas, que determinam o rumo das comunidades nascentes, enfim, que realmente fazem a diferença.

Claro que os grandes canais ajudam a dar visibilidade às tecnologias e tornam as coisas mais fáceis para os infelizes que precisam convencer doze níveis de gerência antes de usar qualquer novidade, mas a tecnologia em si não necessariamente evolui mais rápido por causa disso. As pessoas que fazem alguma diferença seriam atraídas pelos méritos da tecnologia de qualquer modo, sem precisar do catalisador da popularidade. A popularidade tem suas vantagens, mas é uma maldição disfarçada. Gente demais na maioria das vezes atrapalha ao invés de ajudar, obrigando os geeks do início a fazer malabarismos para encontrar o que ainda há de relevante e afastando os novos geeks que teriam boas idéias com todo o barulho.

É bastante comum ver organizações que costumam desenvolver software em cascata espernear quando chega a hora de implantar e colocar os sistemas em produção. Depois que tudo está instalado e funcionando a todo vapor elas acabam entrando em modo bombeiro e passam simplesmente a apagar um incêndio atrás do outro, sem saber muito o que fazer e como organizar seus esforços de manutenção.

Isto costuma acontecer porque a abordagem de desenvolvimento delas simplesmente não está adaptada à manutenção. Ela foi otimizada para um cenário (completamente fictício, diga-se de passagem) onde não há vida após a entrega do sistema, onde os clientes não mudam de idéia e onde não acontecem requisições de mudança depois que o software está pronto.

Não importa quanto alguém se dedique à tarefa. Ninguém consegue fazer a água da cascata cair para cima.

A abordagem oposta, obviamente, é otimizar para a manutenção, isto é, estar pronto para começar pequeno, mudar sempre que necessário, consertar o software aos poucos e torcer para que um dia ele não precise mais de conserto. A proposta Ágil começou com experiências neste sentido, tomando emprestado da filosofia release early, release often e preferindo usar o próprio software para comunicação entre os clientes e a equipe de desenvolvimento ao invés de documentos e diagramas. Num certo sentido, equipes ágeis tomam a manutenção como modo de operação normal no lugar do desenvolvimento puro. Preferem desenvolver uma solução completa e usável para um problema pequeno rapidamente para que possam dar as boas vindas à manutenção o mais cedo possível. Enquanto os clientes não tem uma peça real de sofware para usar e experimentar, suas sugestões são só um pouco melhor do que especulação.

Esta não é uma idéia tão louca no fim das contas. Pensando bem, da segunda linha de código para a frente tudo é manutenção.

Não é tão incomum sugerir algo novo para um programador “orientado a objetos” e escutar alguma variante da velha frase “mas isso não vai de encontro a todas as noções conhecidas de orientação a objetos?”. Pode acontecer ao mostrar linguagens dinâmicas que permitem redefinição de métodos em tempo de execução, ao demonstrar as vantagens das closures ou até ao introduzir interfaces fluentes. Você escolhe.

Não precisamos nem discutir o que diabos é orientação a objetos para notar que o termo está perdendo o sentido mais rápido do que um raio. Nenhum dos exemplos citados parecem ofender o meu conceito de orientação a objeto e também não vejo porque feririam o de ninguém. Para ser sincero, desde quando os objetos tornaram-se tão sagrados que não possam ser subvertidos um pouco de vez em quando? Apesar disso já vi este argumento ser usado em todos os três casos.

O ponto aqui não é que orientação a objetos não sirva para nada. Nem que o purismo deva ser evitado. Na verdade, o purismo pode ser bastante útil como ferramenta intelectual. Duvido, por exemplo, que muitos dos recursos interessantes introduzidos em Haskell surgissem se não houvesse um compromisso com a pureza da linguagem em termos de transparência referencial. O grande problema com a orientação a objeto não é o purismo.

É o sucesso.

Com a popularização na última década da orientação a objeto o termo se disseminou. Isso fez mal para ele porque quanto mais gente conhece um termo fracamente definido, maiores as chances de ser desvirtuado ou simplesmente usado sem sentido nenhum. Parece que orientação a objeto acabou virando argumento contra qualquer coisa e, como geralmente ninguém sabe a que definição o falante está se referindo, não sobram muitos contra-argumentos. Nas poucas vezes que uma discussão mais ou menos civilizada é possível, o resistente acaba não se convencendo de verdade. Seria melhor que as pessoas dissessem que não gostaram da idéia, mas “estou sendo apresentado a esta técnica agora, parece diferente de tudo que já vi, estou com medo e não quero avaliar melhor as alternativas” não parece tão profissional. Sobra para a velha e leal orientação a objetos.

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.

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.

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.

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.

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

Muito menos um programador C#, Delphi ou Visual Basic. Para falar a verdade, o que você quer não é nem mesmo um programador Python, Ruby ou Lua.

Este texto também não é um elogio aos programadores Haskell. Você também não vai querer um desses.

Se você tem um problema para ser resolvido com algum programa de computador, o que você precisa é de um programador. Simples assim.

Ninguém precisa da especialização em nenhuma linguagem ou plataforma específica para começo de conversa, mas para programar computadores com certeza você vai precisar de um programador. A verdade é que ele vai precisar de muitas outras habilidades além de proficiência com um compilador, mas se você contratar alguém que não sabe programar, terá uma bela enrascada em mãos. Não importa quantos analisadores de problemas e desenhadores de retângulos sua equipe tiver, se eles não puderem conseguir que um computador faça alguma coisa, seu projeto vai ser um fiasco na certa. A não ser — é claro — que os retângulos possam ser transformados de algum modo em instruções detalhadas executáveis por um computador.

Mas nesse caso você teria programadores. Só aconteceria deles programarem com retângulos, mas ainda assim seriam programadores.

Conhecer uma única linguagem de programação não é um empecilho somente porque muito provavelmente ela não vai mais ser a melhor ferramenta para o trabalho daqui a três ou quatro anos, mas porque mostra uma incapacidade (ou falta de vontade) para aprender. O que nenhum cliente deveria querer são programadores altamente especializados a ponto de conhecer uma única linguagem de programação. Ao invés de um programador especialista na plataforma da moda de hoje, o que você precisa é de um que seja capaz de aprender as de amanhã. O que um bom programador mais precisa, como qualquer bom profissional, não é apenas saber usar as ferramentas do presente, mas ter capacidade de aprender as do futuro.

Não se deixe enganar também por programadores de retângulos, mesmo que eles gostem de ser chamados de modeladores, arquitetos ou de qualquer outro nome que esteja na moda na época. Linguagens visuais também são apenas linguagens. São linguagens que, por serem gráficas, podem parecer independentes de linguagem, mas não deixam de ser linguagens. Não importa que o programador desenhe ao invés de escrever, se ele quis se limitar a desenhar, deve ser porque não quer nem se dar ao trabalho de aprender a escrever.

Especialização em excesso além de tudo cria ilhas muito concentradas de conhecimento. Por algum motivo inexplicável, muitos programadores especializados acham que jogam em times adversários, que estão em trincheiras diferentes e que tudo é uma grande guerra. Se quiser experimentar isso, tente publicar uma notícia que simplesmente cite Ruby (nem precisa ser o tema principal) em um fórum Java e observe o que acontece. O triste é que eles acabam isolando a si mesmos dentro de uma comunidade pequena e perdem de aprender o que as pessoas de fora poderiam ensinar.

Qual é a granularidade das modificações que você envia ao seu sistema de controle de versão? Você se limita a modificações pequenas (que mudam o nome de uma varíavel ou outra, por exemplo) ou gosta das mas volumosas (como as que mudam o nome de uma rotina, introduzem um parâmetro novo e ainda corrigem um defeito em um pedaço do código que a chamava)?

Não é uma pergunta retórica. Pode responder. O espaço para comentários ali embaixo serve exatamente para isso.

Quando envio patches para algum projeto, tento torná-los tão pequenos e localizados quanto possível. Eu sei que não é uma experiência muito agradável revisar modificações monstruosas que afetam toda a base de código e tento poupar disso os mantenedores dos projetos para os quais colaboro. Eles são programadores, mas também são gente.

Não é tão raro que uma parte das modificações em um patch sejam aceitas e outras não. Caso o patch enviado seja muito extenso, o mantenedor vai ter um bocado de trabalho para separar as partes boas das ruins. Se ele tiver muitas outras preocupações no dia (o que não é nada incomum), pode ser que ele simplesmente recuse todo o patch, apesar de haver mudanças úteis, só para poupar o trabalho de filtragem. Para quem está contribuindo, certamente é melhor que as modificações sejam aceitas e um conjunto de patches pequenos torna as chances disso acontecer muito maiores do que um único patch grande. Nem todo patch que enviamos é aceito e precisamos conviver com isso. Modificações pequenas e localizadas ajudam muito quando algumas delas precisa ser rejeitadas.

Patches pequenos costumam ser mais ortogonais e fazem muito sentido no contexto colaborativo de um projeto de código aberto, principalmente com sistemas de controle de versão distribuídos. Mas ainda existem sistemas centralizados e — pior — cuja única solução para edição concorrente é usar travas para tentar tornar o desenvolvimento serializado e impedir toda e qualquer tentativa de paralelismo. Como se este cenário não fosse suficientemente ruim, alguns sistemas não suportam commits com múltiplas modificações e obrigam todo mundo a registrar alterações arquivo por arquivo, mesmo que toquem em muitos pontos. Para terminar imagine que a única forma de interação da equipe com a ferramenta de controle de versão seja um cliente gráfico com interface do século passado e dificilmente automatizável.

É serio mesmo, essas coisas ainda existem.

E tem gente que precisa usá-las.

Quando o mundo conspira contra você com tanta intensidade, fica mais difícil resistir à tentação de fazer uma modificação monstruosa com um comentário altamente descritivo como “Modificações do código”. Porém, mesmo quando estou em algum ambiente parecido com este, ainda tento fazer modificações pequenas. Não faço alterações tão pequenas como quando estou usando Darcs e vez ou outra combino duas ou três modificações em uma, mas sempre evito registrar uma alteração que resolva mais de um defeito ou melhoria.

Parece haver um certo conflito entre commits localizados e implementação de recursos. A renomeação de uma rotina, por exemplo, pode ser um dos passos que leva à inclusão de uma nova funcionalidade, mas com certeza não vai resolver a bronca sozinha. As funcionalidades precisam de modificações maiores, mas modificações menores são mais fáceis de entender, revisar e reverter. Será que este conflito real ou apenas um produto da nossa imaginação?