Essa é a tradução (com algumas adaptações) do artigo “Top 10 Things That Annoy Programmers” de Kevin William Pang disponível em www.kevinwilliampang.com.

Todos os desenvolvedores tem suas irritações. Seja o aumento do escopo, notação húngara ou colegas de trabalho chatos. Temos que aceitar que existem certas irritações que acompanham nosso dia-a-dia no trabalho. A seguir uma lista das 10 coisas que mais nos irritam:

10. Comentários que explicam o “como” e não o “porquê”

Nos cursos de programação para iniciantes ensinam os alunos a comentar frequentemente seus códigos. A ideia é que quanto mais comentários tiver, é melhor. Infelizmente muitos desenvolvedores parecem ter como um desafio pessoal comentar cada linha de código. E é por isso que muitas vezes veremos algo como isso:

$r = $n / 2; // Atribuindo $n dividido por 2 em $r
// Loop while $r - ($n/$r) enquanto for maior que $t
while ( abs( $r - ($n/$r) ) > $t ) {
   $r = 0.5 * ( $r + ($n/$r) ); // Atribuindo a metade de $r + ($n/$r) em $r
}

Você tem alguma ideia do que o código acima faz? Nem eu. O problema é que enquanto há comentários explicando o que está fazendo ao invéz de explicar o porquê.

Agora considere o mesmo código com uma metodologia diferente de comentário:

// Raiz quadrada de $n com aproximação de Newton-Raphson
$r = $n / 2;
while ( abs( $r - ($n/$r) ) > $t ) {
   $r = 0.5 * ( $r + ($n/$r) );
}

Muito melhor! Nós ainda não conseguimos entender exatamente o que está acontecendo mas pelo menos nós temos um ponto de partida.
Comentários são para ajudar os outros desenvolvedores a entender seu código, não a sintaxe. Nós temos que assumir que o outro desenvolvedor entende o básico de como um loop funciona; não adianta colocar comentários como “// Iterando em uma lista de clientes”. O que o outro desenvolvedor quer saber é porque seu código funciona e porque você escolheu ir por esse caminho.

9. Interrupções

Poucos desenvolvedores conseguem começar um código do zero e terminar logo em seguida. Em geral, tendemos a ser mais semelhantes a locomotivas do que Ferraris; pode nos levar algum tempo para começar, mas uma vez que nós engatilhamos, podemos ter uma quantidade impressionante de trabalho.

Infelizmente, é muito difícil entrar em sintonia com seu código se seu “trem” de pensamentos está constantemente sendo desviado por clientes, gerentes e colegas.

Há simplesmente muita informação, precisamos ter em mente enquanto estamos trabalhando em uma tarefa para ser capaz de finalizar o trabalho, lidar com outra questão, em seguida, pegar a tarefa sem perder um passo. Interrupções acabam com nossa linha de pensamento e coloca-o de volta muitas vezes um repensamento, frustrante, e o pior de todo o processo, sujeito a erros.

8. Crescimento de escopo

Crescimento de escopo torna relativamente um simples pedido em um “monstro”, tornando-os em aplicações complexas.

• Versão 1: Mostrar um mapa da localização
• Versão 2: Mostrar um mapa 3D da localização
• Versão 3: Mostrar um mapa 3D da localização  e permitir que o usuário navegue por ele

Argh! O que normalmente levaria 30 minutos para ser desenvolvido agora passou para um sistema complexo que levaria milhares de horas. Pior que isso, maior parte do desenvolvimento do escopo adicional será de reescrita de código e muitas vezes a inutilização de códigos escritos dias antes.

7. Gerentes sem conhecimentos técnicos

Gerenciar não é uma tarefa fácil. As pessoas são difíceis de lidar. Somos frágeis, volúveis e brigamos por tudo para ser o primeiro. Manter um time de desenvolvedores é uma tarefa árdua. No entanto isso não significa que os gestores devem ser capazes de ter alguma compreensão básica do que fazemos. Quando a gerência não consegue entender os conceitos básicos de nosso trabalho, vamos acabar com escopo mal entendido, prazos irrealistas e a frustação geral de ambos os lados. Esta é uma queixa muito comum entre os desenvolvedores e fonte de muita angústia.

6. Documentar as nossas aplicações

Deixa eu começar dizendo que sim, eu sei que há um monte de geradores de documentação por aí, mas na minha experiências eles só se aplicam para para gerar documentação de APIs para que outros desenvolvedores a usem. Se você estiver trabalhando com uma aplicação normal que pessoas comuns usarão, você vai ter que escrever documentação que um leigo possa entender (por exemplo, como funciona a sua aplicação, guia de resoluções de problemas, etc).

Não é difícil ver que esse é o temor dos desenvolvedores. É só dar uma olhada em todos projetos open-source que existem. Qual é a única coisa que eles estão constantemente pedindo ajuda? Documentação.

5. Aplicações sem documentação

Eu nunca disse que não éramos hipócritas. Desenvolvedores precisam constantemente integrar bibliotecas e aplicações de terceiros em seu trabalho. Para fazer isso, precisamos de documentação. Infelizmente, como mencionado no item 6, os desenvolvedores odeia escrevê-las.

Não há nada mais frustante do que tentar utilizar uma biblioteca de terceiros, tendo absolutamente nenhuma ideia do que serve metade das funções. Qual é a diferença entre funcaoA() e funcaoSimilarB()? Preciso executar uma verificação nula antes de acessar a propriedade X? Terei que fazer na tentativa e erro! Urgh!

4. Hardware

Qualquer desenvolvedor que já tenha sido chamado para depurar uma estranha ocorrência no servidor de banco de dados ou porque as unidades RAID não estão funcionando corretamente, sabe que esses problemas são chatos. Não parece ser incomum que, desde que trabalhamos com computadores, devemos saber como arrumá-los. Mas na verdade isso vale pra alguns desenvolvedores somente. Muitos de nós não sabemos ou não nos interessa em saber o que está acontecendo depois que sua aplicação está no servidor em produção.

3. Imprecisão

“O site está quebrado”. “Funcionalidade X não está funcionando corretamente”. Solicitações vagas são difícieis de lidar. É sempre surpreendente pedir para um não-desenvolvedor reproduzir o erro. Eles parecem não compreender que “está quebrado, arrume!” não é informação suficiente para que possamos trabalhar nela.

Software é (na maioria das vezes) determinista. Nós gostamos que seja dessa forma. Muitos nos ajuda em dizer em qual etapa do processo está quebrada do que simplesmente pedir para consertarmos.

2. Outros desenvolvedores

Desenvolvedores nem sempre se dá bem com outros desenvolvedores. Isso é chocante mas é verdade. Isso poderia facilmente ter sua própria lista de top 10, mas eu vou listar somente alguns:

• Estar irritado ao ponto de ser agressivo;
• Não entender que há tempo para debater a arquitetura do sistema e outro para desenvolver o código.
• Incapacidade de se comunicar de forma eficaz ou utilizando uma terminologia confusa.
• Incapacidade de assumir as responsabilidade.
• Desmotivação com o projeto.

E o último, mas não menos importante, o número um das coisas que mais nos irritam.

1. Olhar seu código seis meses depois

Já olhou seus códigos antigos? Como você foi estúpido! Como você poderia ter escrito aquilo? Joga tudo fora!

Bom, a notícia é que você não está sozinho.

A verdade é que no mundo do desenvolvimento está em constante mutação. O que nós consideramos como uma boa prática hoje poder ser obsoleto amanhã. E simplesmente não é possível escrever um código perfeito, porque as normas sobre as quais nosso código é julgada está evoluindo a cada dia. É difícil lidar com o fato de que seu trabalho, tão bonito quanto ele pode ser agora, será provavelmente ridicularizado posteriormente.

É frustante, porque não importa o quanto nossos estudos para melhoria constante para que nós utilizemos as melhores ferramentas, modelos e melhores práticas, haverá sempre uma melhor. Pra mim, essa é a coisa que mais me incomoda.

Bom, está aí. As dez coisas que mais irritam desenvolvedores. Se você achar que falta algo, envie aqui nos comentários!