Rafael Noronha

Este texto está disponível apenas em Inglês.

Há alguns dias atrás Joel Spolsky blogou a respeito de um perfil de desenvolvedor de software que ele vê com bons olhos.
Na minha interpretação, este perfil representa “o cara que entrega”.

Ainda sob a minha ótica, o cara que entrega é aquele que:

1. Está mais preocupado com o projeto do que com a tecnologias empregadas.
2. Não deixa de cumprir um prazo porque o código não está tão bom quanto poderia estar.
3. Faz um trabalho simples.
4. Não está preocupado em aplicar em seu código Strategy, Facade, ou qualquer coisa do tipo.
5. Não considera prática criminosa deixar de escrever testes.

Existem problemas com o perfil deste desenvolvedor?
Talvez.

Você não precisa fazer parte do 8 ou do 80.
Você pode ficar entre eles.

Do lado do 8 está  o cara que entrega.

E do lado do 80, aqueles que abominam a figura do cara que entrega.

O que estes esquecem é que:

1. Preocupar-se mais com a tecnologia e menos com o projeto é ruim.
2. Entregar um código que poderia estar melhor não significa entregar um código necessariamente ruim.
3. Fazer um trabalho simples não significa fazer um trabalho ruim.
4. Preocupar-se com o design pattern que você utilizou ou vai utilizar para resolver um problema pode ser extremamente irrelevante.
5. A não escrita de testes nem sempre deve ser julgada como crime hediondo.

O melhor a se fazer é reconhecer os méritos existentes no cara que entrega.

Porque construir o melhor código do mundo mas entregá-lo tarde demais é ruim.
Porque gastar tempo demais escrevendo testes pode ser ruim.
Porque você não precisa conhecer design patterns para ser um bom desenvolvedor.

Extremos  são ruins

Neglicenciar a importância de se escrever código expressivo é ruim.
Superestimar esta importância também é ruim.

Desconhecer os benefícios de escrever testes de software é ruim.
Escrevê-los sem dominar a prática, ou sem levar em consideração o custo da prática também é ruim.

É este tipo de armadilha que requer de um desenvolvedor de software pragmatismo.
Não existem verdades absolutas.

Existem dezenas de técnicas que quando utilizadas oportunamente podem ser extremamente valiosas.

No entanto, grande parte destas técnicas traz algum tipo de custo.
Utilizar a técnica XYZ mas deixar de considerar o seu custo pode ser pior do que deixar de utilizá-la.

Isto para não falar em utilizar a técnica XYZ sem entender o que de fato ganha-se com esta utilização.

Para quem criticou o texto do Spolsky, talvez o seguinte parágrafo tenha passado desapercebido:

Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

Portanto o “cara que entrega”, agora na visão do Spolsky, é um desenvolvedor inteligente o suficiente para se dar o luxo de não escrever testes, sem necessariamente colocar tudo a perder.

Se você é o cara que entrega nestas condições, é uma honra estar escrevendo para você.

Mas se você é o cara que entrega, mas não sabe do que está abrindo mão, é provável que você seja o cara que entrega lixo.

Aquele, que a turma do lado do 80 tanto ama.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.