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!
I'm a passionate software developer interested in ways of using technology to improve people lives. I'm an idrealist working on turning ideals into actions.
#1 por andre fonseca - 28 de dezembro de 2009 em 09:13
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.
#2 por Rafael Lima - 28 de dezembro de 2009 em 11:53
Maneiríssimo o post! Valeu pelo complemento.
Abraço
#3 por Alessandro - 29 de dezembro de 2009 em 17:09
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!
#4 por Marcos Sousa - 30 de dezembro de 2009 em 14:38
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.
#5 por Henrique Bastos - 30 de dezembro de 2009 em 18:29
@Alessandro precisamente!
@Marcos o grande desafio é encontrar um bom meio de comunicar isso, que para nós, é óbvio.
#6 por caike - 1 de janeiro de 2010 em 14:23
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çø!
#7 por dimitrikx - 3 de julho de 2010 em 13:04
Penso exatamente o mesmo.
Já tinha chegado a estes conclusões, para mim é importante saber que existe pessoas pensado parecidas.