Passar na prova ou realmente aprender?
A “cultura” da certificação é uma das “pragas” que infectam o mundo do desenvolvimento de software e da TI em geral.
Instituições e pessoas sem qualquer experiência real criam processos e avaliam empresas e profissionais com base em critérios duvidosos e, muitas vezes, obscuros.
Hoje existe uma série de metodologias e processos desenvolvidos por acadêmicos, que passam a maior parte do tempo estudando a teoria e criando software científico experimental. Essas pessoas podem ter boa vontade, mas não estão acostumadas com o dia-a-dia do desenvolvimento para clientes “reais”: empresas que esperam que o software seja a solução milagrosa para todos os seus problemas e investem muito nisso.
Baseadas nessa experiência acadêmica, essas pessoas criam processos que não condizem com a realidade do mercado comercial e emitem certificações de acordo com critérios igualmente irreais. Resumindo: certificam que você está usando um processo que não serve para o seu negócio (pode até servir para criar software que controla foguetes, mas não para o que a grande maioria das software houses cria).
Além das certificações para empresas, há também a delicada questão das certificações para os desenvolvedores (MCP, SCJP, Scrum Master etc). Fico me perguntando o que é que essas certificações garantem? Que alguém decorou centenas de linhas de código e esqueceu dias depois?
Bons desenvolvedores não precisam de certificação. Eles são bons em qualquer plataforma e ponto. Isso não significa que não existam bons desenvolvedores certificados, mas que uma grande massa de desenvolvedores medíocres utiliza das certificações para se “pendurar” em algum emprego que paga bem e ficar lá enganando. Em geral, essas certificações avaliam o “domínio” de técnicas em determinada linguagem ou plataforma, sequer chegando perto de avaliar se uma pessoa sabe ou não sabe desenvolver bom software.
Certificações também são utilizadas por selecionadores de mão de obra que são leigos em tecnologia. Como não sabem como avaliar um desenvolvedor de software, ordenam os currículos por número de certificações e, bingo, acreditam ter selecionado os melhores.
Assim como o Vinícius Teles em seus podcasts, acredito que nesses casos o que acontece é bem semelhante a uma prova escolar: os alunos decoram toda a matéria, fazem a prova e, pouco tempo depois, já não se lembram de mais nada. O conteúdo realmente absorvido é muito pouco.
Jamis Buck escreveu um excelente post sobre o assunto. Aqui vão alguns destaques:
Como regra geral, acredito que certificações são uma piada. Pura e simplesmente. (…) A simples idéia de que um teste pode, de qualquer maneira, implicar em competência é de se gargalhar.
Certificação pode produzir programadores competentes? Eu digo “não”. Se você é certificado e competente, então você era competente antes de ser certificado.
Certificações são usadas principalmente por tomadores de decisão ignorantes como um discriminador. Logo, se alguém quer ser notado por um tomador de decisão, precisa passar no teste. É a certificação pela certificação. Isto encoraja qualquer coisa, menos o aprendizado. Encoraja mediocridade em larga escala, causada por pessoas memorizando exatamente o que o teste exige e nada mais. Encoraja aprender fora de contexto. Encoraja a cópia no lugar de pensamento criativo.
Qual é a opinião da sua empresa?
Não é segredo para ninguém: as empresas que mais crescem atualmente são as empresas com opinião.
As empresas com opinião não são conduzidas, conduzem. Sabem dizer não e criar tendências. Exemplos? Apple, 37signals e brasileiras como a Visie e a ImproveIT.
Empresas “cinzas”, isto é, que querem ser tudo para todos (”vanilla”, para os norte-americanos), perdem espaço cada vez mais rapidamente.
A Microsoft passou a correr desesperadamente atrás de empresas como Google e Apple pois simplesmente não consegue inovar. O motivo? Falta de opinião. A empresa está presa ao “mercado”. Ao tentar ser tudo para todos, ela criou amarras das quais não consegue se livrar.
Burocracia, legado e a própria filosofia e política da empresa a tornam lenta demais, inapta para responder ao dinamismo de uma “nova” era, onde a internet é a plataforma principal, demandando mudanças muito mais rápidas do que o vagaroso ciclo de releases do software “tradicional”.
Não sou um xiita, mas tenho minhas opiniões. Acredito que a Microsoft ainda cria bons produtos (principalmente hardware), mas ela deixou de ser líder já há um bom tempo.
Além de qualidade e bons preços, as pessoas buscam cada vez mais identificação com as empresas das quais consomem produtos ou serviços. É muito raro encontrar alguém realmente identificado com empresas como a Microsoft (e muitas outras), mas é fácil encontrar pessoas que seguem “culturas” como Apple e 37signals, empresas que se esforçam para criar e manter toda uma filosofia baseada em fortes opiniões. Para mim, esta é a maior vantagem competitiva que uma empresa pode ter hoje.
Qual a sua opinião? Qual é a opinião da sua empresa?
Veja também:
Entrevista de Jason Fried com Walt Mossberg.
Expressividade no código ou “Porque testes, código bem escrito e refactoring são melhores que qualquer documentação”
Interessantíssimo o artigo do Phillip Calçado, “Expressividade no código“. Nele, Phillip fala o que todo programador já está cansado de saber mas que a maioria finge não saber ou, simplesmente, acha “trabalhoso” demais. Afinal, desenvolvimento “Quick and Dirty” dá muito menos trabalho, não é?
Pior ainda é conseguir convencer gerentes disso. Gerentes são burocratas por natureza, possuem uma paixão inexplicável por papelada e documentação (que nem eles mesmo utilizam), adoram andar com livros grossos pregando a última “revolução” no mundo dos processos, caçando certificações como Cobit e PMI e, principalmente, não enxergando um palmo à frente do nariz. Não é por acaso que, hoje, a inovação vêm das startups e pequenos grupos de desenvolvedores pragmáticos que focam no que realmente importa: software simples, elegante e que resolve problemas.
Voltando ao artigo, a leitura é altamente recomendada. Com um exemplo simples e direto, Phillip constrói seu argumento com rara habilidade. Habilidade que só a experiência com desenvolvimento real é capaz de trazer.
Tradução de artigo - Aquecimento Ruby, parte 2: Métodos ausentes, móveis e manufaturados
Finalizando a série, Russ Olsen mostra técnicas mais exóticas para definição de métodos em Ruby.
Russ, obrigado novamente por autorizar a tradução de seus artigos. Boa sorte com o livro.
(Russ, thank you again for authorizing the translation of your articles. Good luck with the book.)
Tradução de artigo - Aquecimento Ruby: “De onde veio esse método?”
Russ Olsen iniciou uma série de artigos sobre Ruby em seu blog Technology As If People Mattered. Russ é o autor do livro Design Patterns in Ruby, já em pré-venda, à ser lançado em breve pela Addison-Wesley.
Conversei com Russ e pedi autorização para traduzir seus artigos, pois acredito que o conteúdo é muito bom e merece ser compartilhado no comunidade brasileira. Ele foi muito receptivo e autorizou sem problemas. Então, vamos ao artigo…
O que há de errado com o software “corporativo”
Começando pelo final: o software “corporativo” é feito para quem o compra, não para quem o utiliza.
Atualmente, até mesmo nas pequenas empresas brasileiras, permeia um pensamento bizarro: quanto mais processos, documentos, burocracia, horas extras e falta de transparência, melhor. É o chamado comportamento corporativo.
Em algum momento da história, sabe-se lá por qual motivo, as pessoas passaram a acreditar que todas as empresas devem copiar fielmente o modelo de trabalho das grandes corporações. Isso é compreensível até certo ponto, afinal, essas corporações “deram certo”. No entanto, é muito esquisito ver pequenas empresas, que deveriam se aproveitar dessa característica, se prejudicarem por adotar esse modelo.
Princípios do Rails
Rails é baseado em uma série de princípios, práticas e filosofias. A maioria já existia, mas foi a partir da popularização do Rails que esses conceitos foram alavancados e passaram a ser conhecidos também em outras comunidades de desenvolvedores.
Isso nos leva à conclusão de que, perdurando ou não, Rails cumpriu seu papel: quebrar paradigmas, contribuir para uma geração de desenvolvedores mais competentes e valorizar o pragmatismo ao invés da burocracia e lentidão do mundo corporativo.
Conheça abaixo alguns princípios do Rails e do desenvolvimento ágil em geral:

