Recentemente li um artigo sobre a diferença entre um desenvolvedor e um programador. Não se trata de um jogo de palavras ou mera ênfase em nomenclaturas. Trata-se de uma constatação do que ocorre no dia-a-dia de muitas equipes e empresas que trabalham com software. Particularmente, creio que há um déficit significativo no tocante a conceitos em boa parte das pessoas. Normalmente, o que é aprendido, muitas vezes de forma mecânica e passiva, é passado adiante sem a menor preocupação em processar informações em busca do conhecimento a respeito de algo. Portanto, considero extremamente válida qualquer iniciativa de promoção de discussões sobre conceitos e abordagens de elementos comuns ou extraordinários.

Em todo e qualquer contexto da sociedade, seja ele familiar, acadêmico ou mercadológico, é possível perceber os diversos níveis nos quais estão inseridas as pessoas. Algumas pessoas vivem às margens daquilo que é considerado um padrão, ficando assim abaixo da média. Outras, contentam-se em atingir a média. Porém há sempre aqueles que fazem questão de estarem acima da média, atingindo níveis cada vez mais altos pelo simples fato de estar em constante busca pela excelência.

Creio que essa é a base da exposição sobre o que difere um desenvolvedor de um programador.

O texto a seguir é uma tradução livre que fiz do artigo, preservando ao máximo a integridade literal do mesmo.

O artigo original, em inglês, foi escrito por Vicente Mundim e pode ser visto no seguinte endereço:

http://blog.rugui.org/2009/07/be-a-developer-not-a-programmer/

A seguir, o texto em português. Boa leitura.


Nos últimos dias eu tenho pensado nessas duas palavras: desenvolvedor e programador. Wikipedia diz que um programador é alguém que escreve software para computadores, enquanto um desenvolvedor é alguém preocupado com o processo de desenvolvimento, alguém que arquiteta o software em um nível mais alto.

Bom, para mim, a diferença é mais simples. Afinal, o que é um programa? É uma sequência de passos que precisam ser seguidos para atingir um objetivo pré-definido ou resolver um problema específico. Quando você executar um programa, ele terá sempre o mesmo comportamento, em outras palavras, ele vai fazer sempre a mesma coisa, e mais uma vez e assim por diante. E o que dizer sobre Desenvolvimento? Desenvolvimento é o processo de obter uma idéia incial e elaborá-la, evoluí-la, até que o objetivo seja alcançado, em outras palavras, até que o problema seja resolvido.

Um programador é alguém que escreve programas. O desenvolvedor é alguém que desenvolve uma idéia, ou uma solução. Isto é um processo iterativo. Primeiro, existe uma idéia (ou solução), então você a melhora e pergunta: “Está bom o suficiente?”. A resposta: “Não”. Então, você a melhora novamente, e repete a questão quantas vezes for necessário até que você esteja satisfeito.

“Quando você é um martelo, tudo se parece com um prego”. Um ditado bastante conhecido. Mas o que isso tem a ver com a questão Devesenolvedor x Programador? Bom, quando tudo o que você vê são problemas, você tende a olhar (e consertar) problemas. Da mesma forma, quando tudo o que você são soluções, você tende a olhar (e pensar) para soluções.

Um desenvolvedor deveria sempre pensar a respeito de soluções. O problema existe, ele entende isso, ele sabe disso. Não existe nada que ele possa fazer para mudar o problema. Mas ele pode, e irá, encontrar a solução para aquele problema. Focando em encontrar a solução, ele vai sempre perguntar a si mesmo: “Esta é uma boa solução? Posso melhorá-la? Deveria eu passar mais tempo envolvido com ela?”. Programadores, por outro lado, são fáceis de serem agradados. Se eles podem solucionar um problema com 10 linhas de código ruim, por que eles deveriam se preocupar se existe uma solução que resolve o problema utilizando 5 linhas de código bom, limpo e mais simples? Se eles podem escrever um único e enorme método, por que eles deveriam dividí-lo? Só porque alguém pode querer usar algumas daquelas funcionalidades depois? Bah…

Isso parece estar bom? Definitivamente NÃO!

Não é que todo código que você escreve é ruim, mas se você, exatamente a pessoa que o escreveu, não tiver o nervo para julgá-lo, quem irá? Talvez você poderia refatorar algum método, ou mudar a ordem na qual você checa as condições em um if. Talvez você até irá terminar gostando do código da forma como está e não irá mudar nada. Entretanto, você precisa julgar o seu código. Se não estiver bom pra você, então não estará bom de forma alguma.

Uma das coisas mais importantes sobre Ruby é sua filosofia. Diferente de outras linguagens, Ruby não obriga você a resolver um problema de uma única forma. Por exemplo, como você pode obter o tamanho de um array?

[].size

Mas você também pode obter seu comprimento

[].length

ou contar quantos itens com

[].count

(usando Ruby > 1.8.7).

Para cada contexto existe uma solução que pode ser melhor do que outra. Não existe apenas uma maneira de fazer as coisas. Existe a maneira que é melhor para você. Exatamente a que você gosta mais. E isto pode ser aplicado à qualquer linguagem, e não somente ao Ruby. Ruby apenas torna isto mais fácil pois oferece essas opções em seu núcleo.

A coisa mais importante para aprender aqui é que o código é menos escrito do que é lido. Você ira escrever seu código uma vez, mas ele será lido muitas vezes, por muitas pessoas. Assim, quando você escreve algum código você deveria sempre se colocar na posição daqueles que o irão ler mais tarde. Se o código não está claro então você deveria torná-lo claro. Não adicione simplesmente uma documentação maluca tentando explicar a bagunça que você acabou de fazer. Tente melhorar o código, refatorá-lo, dividí-lo em múltiplos métodos menores, dar um melhor nome para um método ou variável. Você terá um código bom, limpo, fácil de ler, executável, e, quem sabe, você poderá reutilizar algum daqueles métodos menores depois.

Pensando nisso, você quer ser um programador, alguém que apenas repete tarefas, cria código que ninguém entende, resolve bugs que já foram resolvidos, copia e cola códigos em todos os lugares tentando fazê-los funcionar? Ou você quer fazer código que irá durar, não porque é um mito, mas porque é bom? Você quer pegar uma lista das tarefas que você deve fazer e simplesmente fazer, como uma máquina? Não deveria você discutir a respeito, compartilhar suas idéias e melhorar a solução?

Seja um desenvolvedor, não um programador!