O que o sistema de educação da Finlândia pode nos ensinar?

Li esta semana um artigo no mínimo intrigante que tenta demonstrar as diferenças entre o sistema educacional americano e o sistema educacional finlandês. Vou listar alguns pontos pois vale a pena a reflexão:

• O sistema americano é baseado na "excelência", na competência; o finlandês, na equidade entre os indivíduos.
• As melhores escolas americanas são particulares e pagas; todas as escolas finlandesas são públicas e gratuitas (da creche ao doutorado).
• O sistema americano é falido, seus alunos obtém resultados no máximo medianos; os finlandeses estão há anos entre os melhores (senão o melhor).
• Para os americanos, a competição entre as escolas torna-as melhores; para os finlandeses, o acesso e condições iguais a todos, independente de posição social, financeira ou geográfica, torna a educação melhor.

Todos os tópicos acima podem levar a conclusões diferentes, mas o item que mais me chama a atenção no texto é: os professores e diretores finlandeses são bem pagos, respeitados, prestigiados e lhes são delegadas responsabilidades.

Ultimamente vemos alunos que não podem ser reprovados, e a educação desmoronando no Brasil. Sinceramente creio que o fator que mais influencia o aprendizado dos alunos é a qualidade do professor. Coloque professores excelentes e bem preparados nas salas de aula, e teremos um salto na nossa qualidade de educação.

Veja a decadência no ensino básico brasileiro nas últimas décadas. Não é culpa do feminismo, mas é uma consequência. Há 40, 50 anos, a única profissão que uma mulher inteligente e bem sucedida poderia exercer na sociedade machista era a de professora. Ou isso ou dona-de-casa. Resultado: aquelas eficazes na tentativa de sair do trabalho doméstico representavam em sua boa parte as melhores mentes femininas disponíveis. Professoras de qualidade. Graças a isso tínhamos alunos com um desempenho satisfatório.

Comparemos com a situação atual. Sou professor também, mas perdoem-me os meus colegas atuais: ser professor costuma ser a última opção dos alunos que se formam nas faculdades. Aliás, eu garanto que os melhores alunos não se dedicam à docência. Há uma verdade escondida no rumor "não sabe fazer nada direito, vira professor". O resultado vemos nos jovens que formam-se por aí. E por que isto acontece? Muito trabalho, pouco dinheiro e nada de respeito.

Uma revolução na educação passa pela valorização dos professores. Pensem nisso e ajam.

Software é artesanal, exige criatividade e precisa de tempo!

Já tiveram a impressão que todo software que você avalia sempre é mais do mesmo? Frequentemente recebo alguns e-mails divulgando empresas de software da região. Sempre levado pela curiosidade, tento descobrir qual é o segmento em que a empresa atua e como é o software por ela ofertado. Fico pasmo em constatar que são todos iguais. Você olha e imediatamente se decepciona.

Software não é linha de produção. Software não é barraca de pastel, nem carrinho de cachorro-quente. Software exige criatividade. O vídeo acima demonstra de um modo absolutamente ilustrativo o que a pressão do tempo faz com a nossa capacidade criativa. Não me admira que todo software por aí seja igual. Todos são "produzidos" pelo mesmo "processo": cospe qualquer coisa aí que é pra ontem!

Este é um dos argumentos pelos quais as "fábricas de software" são uma falácia. Uma mentira criada por uma indústria. Mas este é assunto para outro post.

Quer um "oceano azul"? Quer um diferencial competitivo? Passemos a trabalhar mais com o cérebro do que com os músculos dos dedos. Comecemos por aí...

Software é muito mais que código

Atualmente os clientes e usuários não julgam o software que produzimos baseados em sua qualidade técnica. Realizar adequadamente atividades como levantamento de requisitos, escolha de ferramentas, codificação, gestão de projeto e obtenção de certificações são quesitos absolutamente indiferentes. Até porque na minha percepção isso é commodity.

Os clientes agora baseiam-se na experiência de uso que tinham antes, durante e depois de utilizar o nosso software. Devemos agradecer ou amaldiçoar a Apple pela experiência digital que ela trouxe às nossas vidas, e com ela, a tão comentada consumerização. Fato é que estamos muitíssimo exigentes com o software e os equipamentos que utilizamos. A expressão correta é "raising the bar".

Nós, programadores profissionais, devemos criar aplicações e prestar serviços que os clientes amem. Bem o oposto daquilo que é feito por aí que os clientes xingam. Para atender a este novo cenário temos que nos adequar e encarar que:

1. Software não é código; ele cria experiência de uso.
2. Equipes de desenvolvimento não são programadores; são criadores de experiências.
3. O talento técnico é o alicerce de tudo; mas grandes desenvolvedores devem ser experts em design e no negócio.
4. Processo não vale nada sem design; você só obtém pelo processo o que você concebeu, então é melhor fazer o design direito.
5. Software é uma jornada criativa, não um processo industrial como uma linha de produção. Sua metodologia deve maximizar o seu potencial criativo.

E eu não inventei nada disso. Quem percebeu esta realidade foi a Forrester Research.

Manifesto pelo Artesanato de Software

"Como aspirantes a Artesãos de Software elevamos o nível do desenvolvimento de software profissional ao praticar e auxiliar outros a aprender o ofício. Através deste trabalho passamos a valorizar:

Não somente software funcionando, mas também software bem feito.
Não somente responder a mudanças, mas também continuamente adicionar valor.
Não somente indivíduos e interações, mas também uma comunidade de profissionais.
Não somente colaboração com o cliente, mas também parcerias produtivas.

Ou seja, na busca pelos itens à esquerda descobrimos que os itens à direita são indispensáveis."

O manifesto original pode ser encontrado aqui: Manifest for Software Craftsmanship.

Não tenho palavras melhores para traduzir o meu sentimento e a minha motivação do que este manifesto. Depois de um período bastante desanimado, lembrei-me dele e me apeguei às suas ideias para renovar meu entusiasmo pela minha profissão: programador e consultor. Hoje sei que sou um defensor do código bem feito.

Vamos utilizar este manifesto para acabar com esta praga de "programadorezinhos" e "consultorezinhos" (sim, no diminutivo - pois são de uma pequenez tremenda) que se multiplicam por aí. Todos podemos ser profissionais. Ou como já disse Napoleão Bonaparte:

"Onde há uma vontade, há um meio".

Configuração do QueryDSL no m2e do eclipse

Esta dica é para os adeptos do QueryDSL, uma ferramenta fantástica para a criação de queries type-safe em Java para Hibernate, JPA, SQL, MongoDB etc.

A configuração do QueryDSL no eclipse funcionava sem problemas com a utilização do plugin m2eclipse, que era a integração do eclipse com o maven. Entretanto, com a liberação do m2e, que a partir de agora é o plugin oficial do maven para o Eclipse, o QueryDSL deixou de funcionar apropriadamente. O erro em questão é que o "target/generated-sources/java" que o plugin do QueryDSL gera deixou de ser adicionado aos "Source Folders" do Eclipse.

A solução é mais simples do que aparenta. Basta instalar este plugin que está disponível no github: https://github.com/ilx/m2e-querydsl

Ele configura o m2e para utilizar o QueryDSL corretamente.

Atualização: já há algumas boas versões os jars do QueryDSL já trazem as configurações necessárias para que o Eclipse trabalhe corretamente sem que haja a necessidade do plugin m2e-querydsl. Mas foi bem útil enquanto necessário.

Eliminar a dívida técnica é uma obrigação, não uma opção

Durante a palestra do Klaus no Agile Tour 2011 em Maringá/PR, houve uma pergunta sobre "O que fazer quando o 'chefe' não permite que você 'gaste' um tempo do sprint para fazer a limpeza do código?" Discutiu-se um pouco sobre o assunto no evento, mas o próprio Klaus acabou reconhecendo no final que a conclusão foi uma "não-resposta".

Minha primeira reação à pergunta foi direta: minta. Ainda bem que não faço as coisas por impulso. Mentir quebraria um dos meus princípios fundamentais que é o da "verdade, doa a quem doer" e também o princípio prático do "mentir dá muito trabalho: dizer a verdade é infinitamente mais fácil". Desnecessário dizer que já angariei muita antipatia por causa destas atitudes, porém ninguém poderá jamais me acusar de ser falso.

Fazer "limpeza do código", também conhecido como eliminar o débito técnico a dívida técnica não é uma opção. É uma obrigação de todo profissional. Não acredito que o "chefe" deve permitir que você faça ou não. Programadores devem faze-lo, doa a quem doer. Lembram do juramento de Hipócrates? "Não fazer o mal". Um médico não permitiria que um paciente tomasse uma dose de remédio que pudesse mata-lo. Programadores não permitem que a dívida técnica aumente para não matar o software.

Se você é um programador, você (e não o seu "chefe") sabe o que é o melhor para o código. Use esse poder.

Se o seu "chefe" é adepto do micro-gerenciamento, provavelmente ele deve ficar olhando o gráfico de burn-down ou calculando a velocidade do sprint para medir a "produtividade" da equipe. O erro fundamental aqui trata-se da visibilidade dos números. Estimativas, velocidade e burn-down são informações da equipe e para a equipe. O "chefe" não deve ficar sabendo destes números. Mas se o seu "chefe" insistir em ficar acompanhando isso e você precisa eliminar o débito técnico, há uma solução simples. No próximo planning poker, dobre o número das cartas. Em cada tarefa, coloque o adicional de 100% para realizar a limpeza necessária. Você não estará mentindo, a velocidade não vai diminuir, o gráfico de burn-down vai continuar bonitinho, o seu "chefe" vai continuar indiferente, e o mais importante, você ficará feliz e satisfeito e o seu código, limpo.

Minha apresentação no Agile Tour 2011: Tirando o código a limpo

O Agile Tour provavelmente é a maior conferência sobre o tema "agilidade" em todas as suas edições no planeta. Aproveitando o sucesso, neste ano tivemos a primeira edição do evento em Maringá.

Confesso que superou as minhas expectativas. O nível técnico do evento foi muito bom. O público era bastante interessado (e com muitos conhecidos na platéia). Fiquei meio triste com a comunidade de desenvolvedores de Maringá, pois esperava o auditório lotado. Tanta gente reclama que não temos bons eventos na cidade, mas quando temos, não comparecem. Mas eu também sei que a época do ano não foi propícia para grandes públicos. Quem estuda, estava preocupado com as provas. E mesmo quem só trabalha já estava em ritmo de fim de ano: torrando o 13.o salário.

Parabéns ao Alexandre Nodari, Heitor Roriz, Objective (Ramon & CIA) e Klaus Wuestefeld pelas apresentações. Eu também tentei dar a minha humilde contribuição.

Espero que alguém tenha ou possa tirar proveito do código de conduta que eu apresentei. Desculpem-me se me exaltei ou se alguém não gostou de alguns palavrões (mas eu pedi permissão antes). Quem me conhece sabe que eu não sou tão intransigente assim, mas acho que pra dar palestra e transmitir uma mensagem às vezes temos que incorporar alguns personagens.

Mas e aí? Vocês podem se considerar programadores profissionais? Valendo o toba?