Reflexões sobre o Programador Lento

10

Estava lendo o excelente post do meu amigo Rafael Lima sobre Programadores Lentos, onde o Lucas Arruda comentou:

Só um comentário: na verdade, todo software sempre terá bugs. Sendo ele desenvolvido lentamente, testado, etc. Isso é um conceito que deve estar bem claro no desenvolvimento de software.
A vantagem de se desenvolver “lentamente” é reduzi-los em grande número.

O Lucas tem razão, mas seu comentário reavivou uma antiga questão dos #Horaextras: há muito mais em programação do que a codificação.

É fato que bugs são inerentes ao processo de desenvolvimento. São desvios naturais. E é exatamente por isso que existem as contramedidas. Técnicas e ferramentas que reduzem a ocorrência destes desvios, ou os corrigem prontamente, são fundamentais para desenvolver softwares de qualidade; leia-se Test Driven Development, Pair Programming, Integração Contínua, etc.

No entanto, essa análise sobre bugs está focada em código, quando o ponto chave é o desenvolvedor. O software depende do conhecimento que o desenvolvedor possui. Conhecimento sobre as técnicas, as linguagens, as plataformas, as ferramentas, sobre o domínio do problema, etc. A qualidade e o tempo de desenvolvimento do software dependem diretamente disso.

Quer dizer que um programador lento, como descrito pelo Rafael Lima, é um programador inexperiente? Não. Dentre os programadores inexperientes, é possível encontrar os programadores lentos e os outros. A mesma separação pode ser feita em um grupo de programadores experiêntes.

A característica marcante de um programador lento é sua atitude. Independente da experiência, ele se sente responsável pelo software que cria. Ele investiga o problema entendendo os cenários até se sentir confortável, e não apenas se preocupa em se livrar da tarefa cuspindo código. Torna-se capaz de analisá-lo sob diversos ângulos e naturalmente descobre corner cases. Ele levantará tantas questões quanto necessárias, sempre de maneira positiva, sem virar um firewall dropando pacotes. E em muitos casos, essa atitude fará com que a equipe detecte problemas mal definidos, evitando desperdícios.

Infelizmente, a visão imediatista que predomina no mercado parece subvalorizar a atitude em prol da habilidade e do conhecimento. Eu pessoalmente, penso que habilidade e conhecimento são importantes sim, mas atitude é fundamental. Digo isso, pois já vi pessoas com pouca habilidade e conhecimento, mas com a atitude certa, se aprimorarem atingindo resultados incríveis. Mas nunca tive a satisfação de observar alguém hábil e com muito conhecimento mudar uma péssima atitude.

Vida longa os programadores lentos!

[]’s!

você pode gostar também
10 comentários
  1. Como agradar seu Chefe (ou como dormir bem e nao fazer hora extra) « O espelho não nos conta outras histórias.

    […] E se ainda resta duvida quanto a velocidade, leia esse post do Henrique Bastos: Reflexões sobre o programador lento […]

  2. dimitrikx Diz

    Penso exatamente o mesmo.
    Já tinha chegado a estes conclusões, para mim é importante saber que existe pessoas pensado parecidas.

  3. Produtividade e a cultura do test-first | Francisco Souza

    […] desenvolvedor rápido, com a incrível capacidade de produzir 5 linhas de código por segundo, realmente é um […]

  4. […] E se ainda resta duvida quanto a velocidade, leia esse post do Henrique Bastos: Reflexões sobre o programador lento […]

  5. caike Diz

    Muito boa reflexão!

    Uma frase que escutei de um professor na faculdade com relação a fazer as coisas da forma mais rápida possível: “Achamos nunca ter temo tempo de fazer as coisas da forma certa. Quando dá merda, sempre achamos tempo para consertar.”

    O programador lento é o programador ‘passionate’. É o artesão.

    Abraçø!

  6. Henrique Bastos Diz

    @Alessandro precisamente!

    @Marcos o grande desafio é encontrar um bom meio de comunicar isso, que para nós, é óbvio.

  7. Marcos Sousa Diz

    Cuspir código é algo que eu costumo aconselhar que ninguém o faça. Pela pressão que geralmente gerentes aka “e-mail spammers” fazem, uma boa parcela das pessoas tendem a sair codificando sem possuir um entendimento real do problema.

    Fico sempre me policiando quando a isto e sempre falo para todos que trabalham comigo para só começar a desenvolver depois que tiver compreendido o problema. E como você mesmo disse, a qualidade é nítida. Técnicas como TDD é uma boa saída para por em prática o que entendeu antes de sair codificando.

  8. Alessandro Diz

    Caro Henrique, foi direto ao ponto. Como sabe, gosto sempre de filosofar sobre temas que circundam nossa área. Independente de quesitos religiosos, sua reflexão fez-me lembrar de uma máxima: a fé sem ações é uma fé morta.
    Digo isto porque ATITUDE é fundamental!

  9. Rafael Lima Diz

    Maneiríssimo o post! Valeu pelo complemento.

    Abraço

  10. andre fonseca Diz

    Que tapa na cara. Estou sentindo o peso de cada palavra até agora. Concordo com vocês pois me vejo querendo ser ultra rápido e por mais experiente que seja nunca sai um bom código e erros “bobos” acabam passando e até o cliente. Sendo que se fizermos as coisas com mais calma muita coisa seria evitada. problema que hoje é mais valorizado o apressado do que o cuidadoso.

Deixe uma resposta

Seu endereço de email não será publicado.