O modelo Dreyfus e a fuga de cérebros

Muitas empresas sofrem com o que se chama “fuga de cérebros”: os melhores profissionais da empresa estão sempre saindo para outros empregos. Isso pode ter vários motivos, como problemas de relacionamento pessoal, baixos salários, mudança de foco profissional, insatisfação com a estratégia ou foco da empresa e vários outros. Mas há um fator muito importante que geralmente é ignorado: a falta de confiança na intuição do profissional especialista (expert).

Pausa para explicação.

O modelo Dreyfus de aquisição de habilidades divide os profissionais em cinco níveis de conhecimento para uma dada habilidade (isto é, você pode estar no nível 1 em culinária e no nível 5 em jardinagem, ninguém “é” um nível 5 e pronto). Bem resumidamente, são eles:

  1. Novato: o novato precisa de regras claras e independentes de contexto (”receita de bolo”) para guiar seu trabalho, e não sabe lidar com problemas pois não tem experiência para tomar decisões sozinho. Também não toma responsabilidade pelas regras que segue - “Eu estava apenas seguindo ordens!”.
  2. Iniciante avançado: começa a tomar decisões mais básicas pois já possui alguma experiência e percebe que pode adaptar algumas regras a certos contextos. Ainda não toma decisões contrárias às regras, não sabe lidar com problemas inesperados e não experimenta a sensação de responsabilidade pessoal. A maioria das pessoas está nesse nível.
  3. Competente: questiona as regras de acordo com sua experiência e percebe consequências a longo prazo. Começa a tomar decisões de acordo com o contexto, resolver problemas inesperados e a tomar a responsabilidade sobre seus atos.
  4. Proficiente: se utiliza de pouquíssimas regras, começa a valorizar mais sua intuição e sempre analisa o contexto em que está inserido de acordo com o que já experimentou. Sente-se completamente responsável por suas decisões e respectivas consequências.
  5. Especialista: o especialista usa a intuição que adquiriu com a experiência e faz tudo parecer muito fácil. Toma decisões e resolve problemas sem esforço, pois reconhece padrões muito rapidamente. É o pior professor para um novato, pois não segue qualquer receita, apenas sabe o que fazer.

Um ponto interessante é que pessoas nos níveis mais baixos costumam se sobreavaliar, enquanto as pessoas nos níveis mais altos são bem mais críticos em relação ao seu trabalho e nível de conhecimento.

Leia o artigo completo

Links interessantes

Pessoas ou máquinas?

Você trabalha com o quê?

Máquinas? Ok, então você desenvolve softwares que são utilizados por máquinas, certo?

Errado. Desenvolvedores trabalham com pessoas. Com clientes, gerentes, vendedores e outros desenvolvedores.

Médicos não trabalham com estetoscópios ou bisturis. Essas são ferramentas. Aprenda a utilizá-las bem, mas não esqueça do foco: pessoas, anseios, desejos, expectativas. Não importa se você domina Python ou 32 frameworks Java: se você não souber satisfazer aos anseios de pessoas, será um fracasso.

Ferramentas vem e vão, se aperfeiçoam, mudam, inovam e são deixadas para trás, ainda mais em nossa profissão. Um pedreiro não usa um martelo para tudo que faz. Um médico não depende de um esfigmômetro para fazer seu trabalho. Ferramentas são facilitadoras, não substituem a competência.

Não se prenda à ferramentas. Não dê atenção apenas aos aspectos técnicos. Uma solução que usa uma tecnologia simples ou “velha” (em TI, 6 meses bastam) que supra as expectativas do cliente é muito (muito mesmo) melhor do que uma solução que usa todos os últimos frameworks e deixa o cliente insatisfeito.

Jason Fried: Questione seu trabalho

Em sua apresentação na conferência South by Southwest, Jason Fried novamente enfatizou a importância do sofware simples e de atitudes como dividir grandes decisões em várias pequenas decisões e de questionar seu trabalho.

slide_JF

Essas perguntas são sempre muito importante ao analisarmos as vantagens de se fazer algo. Realmente vale a pena? Poderíamos fazer mais simples? Poderíamos fazer outra coisa que agregue mais valor?

Outros pontos de destaque da apresentação:

Confira o post de Jason e também o resumo de sua apresentação, feito por Tim Walker.

“Rápido e Sujo” ou “Lento e Limpo”. Porque não “Rápido e Limpo”?

Há algum tempo atrás assisti ao vídeo da apresentação de Martin Fowler na RailsConf 2006. Nessa apresentação ele fala sobre o que o faz gostar do Rails (e do Ruby) como plataforma para desenvolvimento de software comercial.

Um dos pontos mais interessantes mencionados por ele é o seguinte: com Rails, conseguimos software limpo entregue rapidamente. Antes disso, você tinha duas frentes: a do “Rápido e Sujo”, geralmente representada por PHP e VB (até a versão 6) e a do “Lento e Limpo”, com Java e .NET.

O grupo do “Rápido e Sujo” promete entregar o software em menos tempo mas, geralmente, o código é uma bagunça e qualquer correção, alteração ou melhoria torna-se um pesadelo.

Já o grupo do “Lento e Limpo” lhe promete entregar uma maravilha da engenharia de software, utilizando cada design pattern já visto nesse mundo (o que é algo bem prejudicial mas, ainda assim, comum), interfaces e IoC por todos os lados, enfim, um código com alta manutenabilidade e extensibilidade (ê palavrinhas…), o que demora uma eternidade e nem sempre é atingido.

Rails estimula uma visão diferente: “Rápido e Limpo”. O framework deve fazer todo o “trabalho sujo” por você, permitindo que você foque apenas no domínio do problema, eliminando muita complexidade acidental e permitindo menores tempos de entrega. Rails atinge isso através do extensivo uso de DSLs e convenções, entre outros conceitos. Além disso, está estimulando essa visão em outras plataformas, o que é muito bom.

Equilíbrio sempre é importante: você quer sim entregar software rapidamente (assim consegue vender mais), mas não quer ficar com uma bizarrice nas mãos para dar manutenção. Por outro lado, não precisa do código mais perfeito do universo, principalmente se isso significa demora excessiva. Pragmatismo é a chave. Faça o que funciona pra você.

Duas observações importantes:

1. Estou generalizando um pouco quanto à PHP, VB, Java e .NET. A qualidade do código depende muito do desenvolvedor, mas algumas linguagens/plataformas estimulam estilos de programação diferentes. Não se sinta ofendido ou menosprezado. :)

2. Por favor, não faça como muita gente e saia alardeando que Rails permite desenvolvimento rápido e ponto. Muita gente está fazendo todo tipo de atrocidade com o framework em nome da rapidez, isto é, prazos reduzidos. O foco da comunidade é na qualidade, por isso falamos tanto sobre TDD, beleza no código, DRY, KISS e outros conceitos. Os prazos menores são consequências, não são objetivos.

Web: a terra do grátis

Acabo de ler mais um ótimo artigo de Chris Anderson (autor de The Long Tail) e recomendo a leitura a todos: Free! Why $0.00 Is the Future of Business.

Neste artigo, Chris discute os modelos de negócio utilizados na Web e argumenta que, como poder de computação, largura de banda e armazenamento ficaram tão baratos à ponto de poder ser “desperdiçados”, praticamente tudo que vai para a web tende a tornar-se gratuito (pelo menos aos usuários finais).

Boa leitura!

Developer 101: Codificação de caracteres

De tempos em tempos gosto de fazer uma “revisão geral” sobre conceitos que considero fundamentais para todo desenvolvedor de software. É natural que algumas coisas que estudamos acabem caindo no “limbo da memória” pela falta de uso, mas é sempre bom dar uma atualizada nesses conceitos, pois nunca se sabe quando eles serão necessário.

Resolvi, então, iniciar a série “Developer 101″ onde, à medida que faço minhas revisões, vou publicar um pouco sobre o assunto e listar links para mais recursos.

No primeiro artigo da série, falarei um pouco sobre algo fundamental e, geralmente, negligenciado por escolas e profissionais: a codificação de caracteres. Não é algo muito fácil de entender e muito dessa dificuldade deve-se às confusões e ambigüidades criadas pelas próprias empresas e entidades de padronização.

Leia o artigo completo

Se você escreve mal, programa mal

E ponto final.

É impressionante a quantidade de pessoas com curso superior na área de informática (o que sugere que a pessoa deveria ter mais conhecimento do que uma sem curso superior…) que não sabe escrever um texto minimamente coeso, muito menos manter uma linha de argumentação consistente em uma conversa.

Não estou dizendo que sou um professor Pasquale, muito menos um mestre na arte da argumentação, mas sempre gostei das ciências humanas e me esforço para melhorar na comunicação. Por quê? Bom, desenvolvimento de software é 90% comunicação. Comunicação com clientes, com membros da equipe, com parceiros, comunicação do seu pensamento em forma de código.

A “era da internet”, de Orkuts, Messengers e afins, tornou o cenário ainda pior: além da deficiência lógica, a total falta de conhecimento gramatical e ortográfica se tornou uma epidemia. A “preguiça” de escrever corretamente, em nome da agilidade na comunicação virtual, tornou-se hábito e “emburreceu” as pessoas.

Programar é uma atividade criativa, envolvendo muito raciocínio e lógica. O mesmo ocorre com a argumentação. Existem técnicas bem definidas para ambas, mas a qualidade do produto final depende das habilidades do executor.

Como discuti anteriormente, o programador apenas programa, traduz, codifica como uma máquina. O desenvolvedor de software, que tem na programação uma de suas principais atividades, busca mais conhecimento, se aprimora, sabe se comunicar.

Então, como alguém espera (ou afirma) ser um bom desenvolvedor de software quando não consegue escrever uma simples frase sem cometer seguidos erros ortográficos e lógicos?

Programador ou Desenvolvedor?

A diferença entre um programador e um desenvolvedor de software é muito grande, mas quase sempre ignorada.

Presa à um paradigma completamente equivocado, a “indústria” do software busca imitar a indústria “convencional”, baseada no trabalho manual, seguindo muitas das idéias de Taylor e Adam Smith.

Essas idéias e princípios funcionam muito bem no chamado trabalho manual, que, em geral, atinge sua máxima eficiência quando organizado na forma de linha de montagem, com alta especialização e divisão de tarefas. Mais uma vez: desenvolvimento de software não funciona como linha de montagem.

Leia o artigo completo

Tradução - Produtividade do desenvolvedor: Média vs. Mediana

Neal Ford, da ThoughtWorks, foi muito gentil ao permitir que eu traduzisse seu artigo “Developer Productivity Mean vs. Median“.

O artigo fala sobre algumas falsas crenças da “indústria” do software: linguagens restritivas, economia na forma de contratação de desenvolvedores medíocres e tentativa de encurtamento de prazos de entrega através da adição de mais pessoas aos projetos, entre outras.

Boa leitura!

Veja o artigo completo…

Next Page →