É algo muito bom que cada desenvolvedor possua sua “stack” preferida de ferramentas. O apreço por esse conjunto leva à dedicação e ao domínio do mesmo.

Entre nós, que orgulhosamente nos categorizamos como “trabalhadores do conhecimento”, creio que, apesar desse apreço à priori não causar prejuízo, trocar de conjunto de ferramentas deveria ser muito fácil (e uma habilidade desejável) já que o que importa é a transformação do conhecimento da forma bruta (dados) à forma desejada (informação), independente do que foi utilizado para isso. É claro que há sempre a curva de aprendizado numa troca dessas: uma nova linguagem, nova DSL/API etc, mas os fundamentos e princípios se mantém.

Nerds, assim como toda pessoa imersa numa sociedade consumista, se definem pelo que consomem e utilizam. Isso é algo bem comum atualmente e vai desde roupas até computadores, editores de texto, smartphones e, pasmem, à p**** da biblioteca que o cara usa pra fazer parsing de XML. Algo que tornou-se muito comum, principalmente com a facilidade que existe para que cada um publique seus pensamentos (blogs, Twitter e afins), é que ocorram “guerras” sobre esse tipo de coisa, já que, em nossa mente, criticar uma coisa que consumo é praticamente criticar a mim e meu modo de viver.

Entre desenvolvedores isso é bem visível. Além das guerrinhas entre comunidades (.NET x Java, Ruby x Python etc) há também as guerras intra-comunidade, em que escolhas de ferramentas são motivo para disputas de ego intermináveis. O cenário, em geral, mostra uma galera que gosta da ferramenta X e acha que, por isso, a ferramenta Y é uma merda inútil e o pessoal que gosta da ferramenta Y achando o mesmo da ferramenta X.

Passemos a um exemplo num contexto diferente para que pré-disposições não afetem nossas conclusões. Imagine que Gordon Ramsay irá a sua casa para fazer o jantar. Ele não vai levar as facas, panelas e demais utensílios que usa em seu dia-a-dia. Vai utilizar apenas o que tem em sua casa. Dias depois você irá a casa dele e utilizará todos os utensílios profissionais à disposição. Bom, a não ser que você seja um anônimo chef de primeira categoria, sabemos quem irá preparar o melhor jantar, não? (sem piadinhas hein! )

Mais um. Quem será que toca melhor: Steve Vai com uma guitarra Giannini de 500 reais ou você com as guitarras ultra-caras dele?

Onde está o conhecimento? Na ferramenta ou no profissional?

Algo bizarro que acontece é ver pessoas que deveriam ter bons conhecimentos sobre lógica confundindo argumento com preferência. Dizer que você prefere X porque acha mais bonito ou mais legal é só sua preferência, não é um argumento para diminuir as alternativas. Chega de “RSpec é mais bonito e moderno, então Test::Unit sucks!” e vice-versa (exemplo aleatório, sem flames por favor).

BREAKING NEWS: se você não sabe patavinas sobre design de código orientado a objeto e uma meia dúzia de princípios básicos, escrever testes em RSpec não vai fazer com que você escreva código melhor do que escrevendo com Test::Unit. Aliás, é bem capaz de piorar as coisas, mas isso é conversa pra outro post.

Em linhas mais práticas, pouco importa para o interessado na informação se ela é processada em PHP ou Ruby, se é formatada em ERB ou HAML ou se está armazenada em MySQL ou PostgreSQL. A ferramenta “certa” é a que faz o trabalho. Sempre há muita discussão sobre isso de “ferramenta certa” e, a não ser que seja algo obviamente errado como usar o Rails pra fazer uma aplicação desktop com controles nativos, o que sempre acaba entrando em jogo é preferência, gosto, estética e etc. Novamente, isso simplesmente não serve como evidência de que algo é superior ou inferior.

“Mas eu sou mais produtivo com X do que com Y!”
“Olha só como meu código fica mais limpo com Z do que com N!”

É, amiguinho. Pra você. Assim como tem muita gente que acredita em divindades criadoras e muita gente que não. Muita gente que acha carros da Porsche bonitos e muita gente que os acha toscos e que os carros da Toyota sim são lindos. Daí a dizer que algum é melhor ou pior é um longo caminho (e, na minha visão, um caminho inexistente).

Pois bem. Por isso creio que, como comunidade, devemos mudar um pouco nosso foco. Tudo bem falar sobre ferramentas, é algo saudável desde que feito com bom senso. Com argumentos, fatos, contexto e harmonia. Não com guerrinhas bobas sobre gosto pessoal e como seu pau é maior que o dos outros sua gem preferida é a mais fodolenta do OMNIverso. É bom para conhecermos alternativas e evoluirmos. Se todo mundo se prendesse ao atual e rejeitasse as novidades, ainda estaríamos perfurando cartões. Enfim, é preciso foco em coisas que realmente fazem a diferença na qualidade. Foco em fundamentos e princípios.

Estatísticas do DataLucas mostram que, a cada dois dias, surgem dezenas de posts falando sobre alguma gem que é a coisa mais maravilhosa já inventada desde o carro voador Toddynho (e que prova que todo o resto é uma merda!), sobre uma miríade de workflows para o VCS da moda, sobre porque a minha biblioteca é mais foda que a sua, sobre como o Agile morreu e, claro, como ele ainda está vivo e funciona muito bem sim senhor!

Legal, todo mundo tem uma opinião sobre o que prefere e sobre o que não gosta. Muito bom, ótimo, sensacional. Mas e o que é imutável? Aquilo que determina qualidade independente do meio utilizado? Já postei bastante essa frase, mas sempre gosto de relembrar:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Ainda não achei frase que se encaixe mais com meu pensamento sobre desenvolvimento de software. Seja no nível gerencial ou técnico, dominar métodos (ferramentas) ignorando princípios com certeza leva à problema. Manjar de todas as cerimônias e artefatos das metodologias ágeis não vai produzir software de qualidade magicamente. Entender seus princípios, mesmo que você não aplique toda a parafernalha cerimonial, com certeza trará efeitos positivos.

Então fica a pergunta: onde estão os posts e talks sobre princípios? Vamos falar sobre coisas como SOLID (não, não é um besteirol acadêmico), acoplamento, coesão, testes que realmente especificam comportamento, trade-offs arquiteturais e outras questões importantes?

Tentarei fazer a minha parte nisso. Ano passado na RubyConf parte da minha apresentação falou sobre princípios (e outra sobre ferramentas ) e penso em continuar com essa temática tanto no blog quanto em futuras apresentações. Gostaria muito que a comunidade valorizasse mais esse tipo de discussão (wishful thinking…).

Já fiz muito dessas guerrinhas, não sou inocente, mas aprendi a valorizar a base, principalmente abrindo a mente (olha a piadinha!) e dando chances à ferramentas diferentes e, com isso, percebendo que em nossa profissão, felizmente, há vários meios eficientes para atingir os resultados desejados.

And… here comes the flames?

PS: se você é do contra e vai bater o pézinho dizendo que preferência e estética são evidências qualitativas, pode desistir e vaza.

Leitura recomendada: “A Little Knowledge is a Dangerous Thing“

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Substitua “método” por “linguagem” e isso resume muito bem o meu pensamento.

Vejo algumas concepções falaciosas em nossa comunidade que há muito já foram superadas em outras profissões. Uma delas é que dominar mais ferramentas torna o profissional melhor. Será mesmo?

Estudamos tanto lógica para aprender a programar e nos esquecemos de uma armadilha lógica básica: confundir causa e efeito com correlação. Ou, pior, caímos na falácia do Efeito pela Causa e acabamos invertendo as coisas. O fato é que quanto melhor o profissional, mais ferramentas ele vai querer explorar.

Explico: um bom desenvolvedor vai querer aprender mais linguagens para aumentar seu repertório de soluções. Um péssimo desenvolvedor pode aprender 20247232 linguagens e o máximo que conseguirá é ser um péssimo desenvolvedor em 20247232 linguagens. Causas: dedicação e proficiência. Efeito (um deles): desejo de expandir o conhecimento. E, assim, temos um ciclo virtuoso.

Não me entenda mal: eu acredito que conhecer várias linguagens é algo muito positivo. Mas também vejo acontecer um tipo de “pressão social” por isso, como se não pudessem haver preferências e predileções. É o mesmo tipo de pressão social que rola se você falar que não gosta de “The Beatles”. As pessoas vão te olhar feio, pode ter certeza (os caras foram – ou ainda são – muito fodas e mudaram muita coisa, só não fazem o meu estilo, então por favor não arranquem meu couro – e olha eu com medo da pressão).

Em geral, quando eu digo que acho legal conhecer e brincar com várias linguagens mas que prefiro, de longe, desenvolver com Ruby, muita gente já “olha torto”. Veja bem, eu não quero dizer que vou escolher Ruby pra tudo for desenvolver – isso é ser cego. O que eu quero dizer é: se eu estiver num “empate técnico” durante a escolha de linguagem, vou preferir Ruby sempre (hoje, pois o futuro não se sabe, não é?). Além disso, quase sempre que eu for programar algo por diversão, vai ser nessa linguagem.

Acredito que há ótimos desenvolvedores monoglotas (que logo sentem a necessidade de expandir seu vocabulário) e péssimos desenvolvedores poliglotas. E vice-versa. Não é um requisito, é uma opção. Como diz aquela famosa frase: “Você pode escrever Fortran em qualquer linguagem”.

Escrevi um pouco sobre isso aqui: Oceano Azul vs Oceano Vermelho: Android vs iOS (meu Tumblr, onde passarei a concentar os textos não relacionados à programação)

Vejo dois comportamentos profissionais comuns que podem prejudicar muito isso:

• Quero ser promovido: aquela pessoa que acredita que deve se dedicar 100% à agradar aos seus superiores. Dessa forma ela conseguirá “evoluir” profissionalmente até chegar à tão sonhada liberdade profissional/financeira.
• Eu não ligo: para esta pessoa, “é apenas um trabalho”. Ela não vai se aprimorar, simplesmente porque não vê necessidade. Em geral, não constrói nada, pois não acredita estar fazendo algo em benefício próprio.

No primeiro caso, a dita “liberdade” nunca será alcançada pois, na verdade, ela não existe. Pouquíssimas pessoas (se existir alguma) possuem a “verdadeira” liberdade: estar completamente livre de qualquer restrição de tempo, espaço e recursos. Isto é: dinheiro infinito e possibilidade de tempo e localização para estar onde quiser no momento que quiser, independente de qualquer fator externo. Isto é utópico.

A liberdade está em cada um – basta se sentir livre para ser livre – e é bem possível atingir isso nessa sociedade louca movida à sacrifícios em nome da tal “vida profissional”: basta não participar da loucura.

No segundo comportamento, vai ficar sempre um vazio pois, independente de ser por trabalho ou por diversão, temos essa necessidade intrínseca de construir: daí o fato de pessoa nenhuma, mesmo com riqueza “infinita”, conseguir ficar absolutamente sem fazer nada por muito tempo. A maioria de nós precisa trabalhar pra se sustentar, então temos de encontrar meios para conciliar isso com a satisfação por criar.

No final das contas, é sim “apenas” um trabalho: o seu trabalho, a sua criação (seja em troca de dinheiro ou não). Evite errar pelo excesso ou pela falta. Deve ser algo a se construir e se orgulhar, não um empecilho para seu bem estar. Se esse for o caso, hora de se movimentar para mudar: o que você está construindo?

Isso costuma ser trazido muito à tona em conversas com amigos e conhecidos pois prefiro trabalhar em startups em oposição à empresas grandes e tradicionais. De alguma forma, startups estão ligadas a profissionais mais comprometidos, o que nem sempre é verdade, e muitas usam esse “status” para exigir longas e estafantes jornadas de trabalho. Ninguém deve se comprometer com esse tipo de vida, seja a empresa uma startup ou não.

Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo. E isso não é exclusivo à startups: esse tipo de atitude é necessária esteja você trabalhando em uma startup com mais três pessoas, em uma corporação gigantesca ou no seu próprio negócio.

Você iniciaria uma empresa para fazer algo em que não acredita? Penso que não. Então por que em um emprego “normal” isso seria diferente? Fazendo uma conta bem básica, são cento e sessenta horas por mês, durante trezentos e sessenta meses (equivalente a trinta anos), o que dá seis anos e meio continuamente fazendo algo que você não dá a mínima.

Enquanto você não inicia seu próprio empreendimento (talvez nunca), a solução é encarar o “trabalho para os outros” como seu empreendimento. Afinal, é isso mesmo o que ele é. O lucro (ou prejuízo) final pode não ficar na sua mão, mas o trabalho que você realizou e a sua satisfação com ele não dependem disso.

Se você não consegue enxergar isso como possível, é um ótimo sinal de que você deve parar de se lamentar e iniciar seu empreendimento. Comprometa-se consigo mesmo, independente do fato de, no momento, você ter um chefe ou ser o chefe.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

A explicação é simples: no sistema de promoção por mérito, pessoas muito boas em dada especialidade são promovidas para outras áreas, para as quais podem ser menos aptas (claro, isso só ocorre quando a promoção leva o profissional a uma área em que suas habilidades atuais não são fundamentais). Dessa forma, cair nas garras do Princípio de Peter torna-se inevitável, levando a empresa a uma perda geral de eficiência ao longo do tempo.

A solução, segundo os cientistas, é reservar 50% das promoções para os piores profissionais da empresa – a chance de que eles “se encontrem” nos cargos aos quais são promovidos é muito maior.

Que desenvolvedor de software nunca topou com esse tipo de problema? Aquele cara, ótimo desenvolvedor, acaba sendo promovido à gerente (e aceita, seja pela grana, pelo status ou por falta de opção) e é simplesmente um zero à esquerda na função. É claro que isso acontece em qualquer área, mas é nesta em que eu tenho experiência.

Podemos tirar duas lições disso:

• Se, por ser um ótimo desenvolvedor, você for agraciado com uma promoção para outra área, pense duas vezes antes de aceitar – isso pode significar o fim da sua carreira como profissional competente. Se a empresa não lhe der opção (é bem comum que só se consiga um aumento aceitando uma promoção-bomba dessas), procure outro lugar – quando você realmente é competente, escolhas não faltam.
• Se você se tornar um empreendedor, primeiro busque ajuda especializada caso não se sinta à vontade com as tarefas necessárias nesse seu “novo cargo”. Você pode ser um ótimo designer com uma ótima ideia, mas isso não quer dizer que será um bom empresário. Além disso, pense bem na política de promoção que vai utilizar se a empresa for bem sucedida. Um exemplo: pode ser muito mais satisfatório recompensar os bons funcionários com melhorias salariais do que promovê-los a cargos para os quais eles não possuem aptidão.

No entanto, é preciso ter bastante cuidado. Métricas são como muletas: muito úteis quando você não consegue andar sem a ajuda delas mas, se você utilizá-las sem necessidade, vai enfraquecer suas pernas.

Um bom exemplo disso é uma métrica muito utilizada por quem escreve testes: a cobertura de código. É uma ferramenta muito útil quando é preciso “correr atrás” do prejuízo, isto é, adicionar testes a código sem cobertura. Nesse caso, é prática comum estabelecer uma porcentagem de cobertura a ser atingida dentro de um prazo limitado. Mas, se você pratica BDD/TDD consistentemente e não deixa código importante sem cobertura, é realmente necessário confirmar isso com um gráfico ou uma porcentagem?

O uso e confiança cega em métricas mesmo sem necessidade de um amparo como esse pode levar à má aplicação da técnica do desenvolvimento guiado por testes, já que ela passa a ser baseada em um número artificial – é muito fácil ter 100% de cobertura de código com uma suíte de testes ruim. Antes uma suite boa mas que, conscientemente, não passa por cada linha de código do que uma suite que execute cada linha, mas seja um lixo como especificação e ferramenta de refactoring.

Mais um exemplo de fragilidade fica claro no famoso e cantado aos quatro ventos code to test ratio: ao utilizar um framework de testes verboso, é fácil obter uma razão de linhas de teste por linhas de código muito maior do que utilizando um framework mais compacto ou macros. Me desculpe quem utiliza e divulga esse número como algum indicativo de qualidade, mas essa medida é simplesmente ridícula, além de totalmente ilusória.

Não, ainda não sou uma pessoa super-mega-produtiva, mas aqui está como consegui aumentar minha produtividade usando alguns truques (e o incrível sistema operacional que é o Mac OS X em conjunto com ótimas aplicações):

• Não verifique seu e-mail mais de quatro vezes ao dia: se você está esperando algum e-mail importante, peça para quem for enviá-lo que te avise quando isso acontecer, usando, por exemplo, uma SMS;
• Não verifique seu e-mail se você sabe que não estará apto a agir sobre alguma mensagem imediatamente: por exemplo, verificar seu e-mail de trabalho no final da tarde de Sexta – deixe para fazer isso na Segunda;
• Livre-se dos feeds que você assina: você não vai realmente sentir falta deles sem ficar um tempo longe. Se, após alguns dias, você sentir muita falta de ler um deles, assine-o novamente, mas não verifique seus feeds mais do que uma vez ao dia. Essa é uma excelente técnica para descobrir o que é realmente importante dentre tudo que você consome;
• Deixe que as pessoas sejam seu filtro: acredite em mim, se algo é realmente importante (ou banal, mas “quente”), vai chegar a você. Você não precisa ficar garimpando. O recurso de “shared items” do Google Reader é excelente nesse ponto – estou à caminho de usar apenas ele, me livrando de todos os feeds que assino (são por volta de oito hoje). Quando realmente precisar encontrar algo, o Google é seu amigo;
• Desabilite notificações desnecessárias: como muitas do Growl ou os “contadores vermelhos” nos ícones de aplicações na Dock do OS X – mantenha apenas as que você realmente precisa (por exemplo, eu mantenho as notificações do Propane, já que é importante saber o que meus colegas de trabalho dizem no Campfire);
• Não use um monitor muito grande: isso pode parecer estranho, mas pesquisas mostram que, após aproximadamente 26 polegadas, o tamanho do monitor diminui a produtividade. É óbvio: muitas coisas no seu campo visual vão lhe distrair. Use o Spaces e divida as telas de acordo com a tarefa (uma para programação, uma para navegação na internet etc);
• Aumente o espaço livre na sua tela eliminando itens do seu Desktop: configura o Finder para não exibir discos rígidos (eu deixo apenas discos ópticos e dispositivos removíveis). Elimine da Dock as aplicações que você não usa muito frequentemente. Use o QuickSilver ou algo similar para acessar as aplicações e arquivos que você não usa frequentemente, apenas não deixe que eles se empilhem na Dock e no Desktop;
• Elimine da Menu Bar os itens que você não precisa, como o ícone de status do Bluetooth, o indicador AM/PM se você usa o formato americano (é fácil saber isso olhando pela janela), o ícone do Time Machine etc;
• Use o Adium e configure-o para que fique oculto a menos que seja a aplicação ativa (veja aqui: ativo, inativo, configurações 1, configurações 2);
• Use o Fluid para criar SSBs para as aplicações web que você precisa para trabalhar: o motivo para isso é evitar ter um browser repleto de abas abertas te distraindo enquanto você usa uma aplicação para trabalhar. Com as aplicações Fluid você pode focar apenas na tarefa à mão;
• Use o Tags para facilitar o processo de organização e busca de arquivos.

É difícil tomar algumas dessas ações, como se livrar dos feeds que você assina – especialmente porque o número de feeds assinados geralmente é motivo de “disputazinhas” entre nerds/geeks. É estupidez pura, como competir para ver quem dorme menos e fica acordado programando por mais tempo.

De qualquer modo, dê uma chance. Após algum tempo (eu recomendo tentar por, pelo menos, dez dias), você vai sentir falta das coisas que realmente precisa e pode tê-las novamente assim que quiser.

Update: Como bem notado pelo ArthurGeek, a imagem de configuração do Adium para que a lista de contatos se esconda automaticamente estava errada (a que eu chamei de “configuração 2″). Arrumei o link e deixo aqui também: http://yfrog.com/avpicture12xp.

–

Também em inglês.