Depois eu leio

Rails Summit 2009

Nos dias 13 e 14 de outubro estive no Rails Summit 2009. Numa das palestras do dia 13 (se não me engano do Ilya Grigorik), o palestrante perguntou: quem aqui é programador .NET? Levantei a mão sozinho no meio do auditório, e pelo que o palestrante apontou, devia ter apenas mais um ou dois nas cadeiras do fundo.

Passei o minuto seguinte contando quantas pessoas haviam no meu campo de visão – 60 – e outro minuto calculando o total do público naquela palestra – mais ou menos 220 pessoas. Enquanto isso, a pergunta seguinte foi “e quem aqui é programador Java?”. Metade do público levantou a mão.

Qual será o motivo dessa diferença? O preço do evento era bem acessível (R$199,00 mais barato que a compra antecipada do último TechEd, e R$399,00 do que a compra na última data), e o conteúdo, apesar do tema principal ser Ruby on Rails, contava com ícones do mundo do software falando sobre temas diversos. Rockstars, como brincou o Obie Fernandez no seu Keynote.

Meu palpite é que isso é reflexo do isolamento histórico que a comunidade .NET mantém com o resto do mundo. Por muito tempo, as únicas referências que os seus developers, developers, developers recebiam eram o incentivo ao drag-and-drop e a falsa impressão que a MS podia lhes dar tudo o que precisassem. Precisam de um ORM? Vamos fazer um novo ao invés de colaborar com o NHibernate. Querem usar ajax? Ok, toma aqui o nosso ajax toolkit e deixa a parte complicada com a gente.

A estratégia do drag-and-drop fazia muito sentido na era pré-internet, para o tipo de aplicações que linguagens como o VB, Delphi e Java se propunham a resolver. Qualquer coisa que exigisse um controle maior do código seria feito em C mesmo, então a bagunça que essa abstração criava embaixo do tapete não era lá muito problemática. Porém, quando as empresas deixaram de ser pequenas ilhas e começaram a provar que a internet podia ser melhor que o desktop para rodar aplicações, era hora de parar.

Mas não foi o que aconteceu. Quando a plataforma .NET foi lançada, havia uma legião de desenvolvedores viciados na facilidade de criar aplicações Windows arrastando buttons, labels e textbox no Visual Basic. Eles não podiam perder essa base de programadores, e como sua próxima meta era o desenvolvimento web, fazer a construção de sites ser parecida com o desenvolvimento windows era a melhor forma de incluir os programadores da geração anterior. Daí o famigerado ASP.NET, com seus viewstates, web controls, page life cycle e tudo mais dos infernos.

Apenas recentemente eles vêm deixando essa postura de lado, com iniciativas open-source, parcerias em soluções já consolidadas e dando mais autonomia para o desenvolvimento de código decente - que o digam o MVC.NET + JQuery. Sem falar que estão cada vez menos tímidos em revelar o quanto já abraçaram internamente a parceria Scrum + XP.

O fato é que enquanto os desenvolvedores .NET eram mimados com ferramentas, o resto ralava tendo que codificar interface na unha ou usando/desenvolvendo ferramentas Open Source. O que era pra ser a maldição destes "rebeldes" virou uma benção, pois, não ter uma empresa ditando como fazer nem o que usar fez essa turma adquirir mais o hábito de trocar informações, dividir código e boas práticas em geral. Surgem frameworks como o Hibernate e o Spring, IDEs diversas, e principalmente, uma grande base de desenvolvedores que sabem o que estão fazendo.

Outro problema pode ser relacionado a cultura das empresas que utilizam a plataforma. Tomara que eu esteja enganado e o que eu vi ao longo da carreira não seja a regra, mas normalmente empresas que adotam integramente um plano de soluções corporativas só estão preocupadas em ter alguém pra processar se fizerem burrada. Nesse tipo de lugar normalmente quem compra não é quem usa, as pessoas são recursos alocados e os processos têm níveis de maturidade. É a entropia fazendo a festa rumo ao colapso, e não existe a menor chance de alguém ser incentivado a olhar pro mundo lá fora quando sua experiência é baseada em lugares assim.

Alguém que não se importa de ser chamado de recurso alocado é incapaz de perceber o valor que existe nestes eventos. Não só nestes encontros, mas nas práticas ligadas a cultura de software em geral. As ferramentas e os processos tradicionais acabam dando a falsa impressão de que está tudo bem, e se o profissional não ficar atento acaba preso num ShouldWorkToLive(Person resource) recursivo.

Sobre o evento em si nem pretendo falar muito, há diversos relatos internet afora e os vídeos podem ser encontrados no Vimeo. Para mim, superou as expectativas a ponto de motivar este recado aos que não costumam trocar figurinha com turmas de outras ruas: saiam da toca e participem dos encontros por aí, têm pra todos os perfis. Testes, agilidade, gestão, frameworks... Veja pelo menos uns dois ou três por ano, vai dar uma grande ajuda pra aprimorar sua visão profissional no período.

No comments

Visão panorâmica

O aumento da maturidade nos processos e tecnologias para desenvolvimento de software, têm refletido no mercado com viradas radicais nos critérios que definem um bom desenvolvedor.

Até há algum tempo, quanto maior a sequência de certificações na plataforma X no currículo, mais chances para o candidato. Havia, e ainda existe na cabeça de alguns gerentes, o mito de que quanto mais especializado e maior o tempo desenvolvendo na tecnologia X, mais “sênior” é o desenvolvedor. Na prática, existem muitos com alguma certificação e que mal sabem OO.

Hoje em dia, nas empresas em que vale a pena ficar antenado, dificilmente isso conta como um grande diferencial. O motivo é simples: elas sabem que bons desenvolvedores investem em princípios, não em frameworks.

Bons desenvolvedores são curiosos demais pra manter fidelidade a uma plataforma. Eles querem saber de tudo, Java/C#, Ruby, Lisp, F#, Erlang, Python, Rest, bancos de dados orientados a documentos… Eles sabem que não dá pra expadir a mente o suficiente só estudando patterns da GoF e modelando tabelinhas normais, muito menos decorando peculiaridades específicas de uma plataforma.

Isso é a média. O cara fora da curva não restringe seu campo de atuação a uma plataforma, ele adora programar, adora participar de projetos com pessoas brilhantes, e principalmente, vivenciar desafios legítimos. Java + Oracle, C# + SQL, SOAP… Boooring. Isso é o que o Paul Graham chama de “daily work”. A gente faz isso durante o dia, mas a paixão mesmo, está no fim do expediente quando o músico vai tocar no bar. Ou quando o nerd vai programar em Lua, por exemplo.

Restringir-se a uma tecnologia limita a carreira. Ao invés de decorar as receitas de bolo de uma marca e enfiar seus frameworks goela abaixo em tudo que é projeto, vale mais a pena entender a fundo os tipos de problemas que eles se propõem a resolver, porque e como eles acontecem, e quais as possíveis formas de resolvê-los de pontos de vista distintos.

Ao sair do mundo corporativo padrão, vêm a liberdade de comparar soluções open source  com empresas comerciais, linguagens de paradigmas opostos, técnicas de integração completamente diferentes, e principalmente, pensar como resolver os problemas utilizando a melhor ferramenta para cada caso. Saber “como fazer”, sem antes entender “porquê fazer” é puramente mecânico, é a média do mercado. Qualquer um estuda algumas horas e passa numa prova. Mas saber os porquês traz um ganho muito maior: enriquece a “cultura de software”.

Não abro mão de ter uma “linguagem oficial”, lógico que é necessário ser ninja de verdade em uma coisa pelo menos. Mas as pessoas com as quais convivo atualmente, me demonstram na prática que cultura de software e comunicação eficaz, são as maiores riquezas que você pode encontrar num desenvolvedor. Qualquer um no APInfo pode quebrar o galho num projeto convencional, mas se você realmente quer fazer um sistema direito, procure um nerd de verdade.

Aquele que responde no StackOverflow sobre DDD num dia, e no outro resume 700 linhas de código OO em 70 com um algoritmo maluco em liguagem funcional (porque era para tornar o processamento paralelo), que questiona se o design pattern escolhido não é um sinal da equipe não ter entendido direito a regra de negócio, que aprende sobre DSL programando extensões para o WoW, que sabe que Atores não são apenas pessoas que interpretam no teatro, etc. E isso ainda nem é cultura de software, talvez eu fale sobre isso num outro momento.

O ponto é que a visão de um especialista muito especializado, tem horizontes muito curtos para ajudar a escolher os caminhos num nível mais abrangente. Esse cara pode te entregar no prazo, pode entregar o que você quer, mas não vai ser o que você ou o seu cliente realmente precisava.

É possível encontrar profissionais que seguiram a fundo no “daily work”, com carreira de certificação, e ainda assim são verdadeiros nerds. Até tive o prazer de conhecer alguns. O problema é que existem poucos por aí, e dos casos que conheço, eles nem ligam pros certificados e muito menos ficam presos as soluções da plataforma em questão. Exceto um que é PMP, esse tem vergonha mesmo e prefere quem nem comentem.

Edit

Dois posts que complementam esse blablabla com alguma coisa mais concreta:

http://www.techfounder.net/2009/07/22/what-makes-a-good-programmer/
http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

No comments