Al convertirnos en programadores solemos volvernos un poco excéntricos, cada quien se hace con un estilo de programación diferente al de otros, sin embargo muchas veces nosotros los programadores nos volvemos tan parecidos en ciertos aspectos, como en las cosas que odiamos:

1. Comentarios que explican el “como” y no el “qué”. Lo que me han metido hasta la saciedad este año en la cabeza es la costumbre de documentar correctamente los apartados o métodos adecuadamente explicando todo lo que en un futuro no podamos entender y procurando hacérselo comprender a otras personas. Hay programadores que más que creen que los comentarios se utilizan para poner el pseudocódigo, vamos prácticamente repiten la información que te da el propio código. El siguiente ejemplo es revelador:

r = n / 2; //Igualamos r a n dividido por 2

//Se repite mientras r – (n/r) sea mayor que t
while ( abs( r – (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); //Igualamos r a la mitad de r + (n/r)
}

2. Las interrupciones. Todos los desarrolladores sabemos cuando estás totalmente enfrascado en el código un momento de distracción puede eliminar todos los pensamientos que tenías en tu cabeza, con el consecuente problema de tener que volver a “conectarte” después de una interrupción. Las causas suelen ser llamadas, mensajes o Messenger en su defecto, jefes o compañeros con su aliento en tu nuca preguntándote por la resolución de un método o metiéndote caña con los plazos de entrega (menos si trabajas en Microsoft, parece ser) y otras de la misma índole.
3. Ampliación del ámbito. Que casualmente se suele dar durante el desarrollo de la aplicación. Esto significa que en un principio te asignan un problema sencillo de unas “pocas líneas” y a medida que pasa el tiempo y la fecha de entrega se acerca aumenta considerablemente la dificultad del problema porque resulta que ahora los analizadores y el cliente deciden que sería mejor si… Como ejemplo nada mejor que el del post original:

Versión 1: Mostrar un mapa de geolocalización
Fácil, cojo un mapa de por ahí y unas pocas líneas de código y a otra cosa mariposa
Versión 2: Mostrar un mapa 3D de localización
Madre del verbo bendito, qué bien se lo pasan tocando las narices a uno, ahora hay que currarse más el diseño y con suerte encontrarlo, cogerlo y adaptarlo de código ya existente
Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando
WTF!

4. Gestores que no entienden de programación. Qué bien, el desarrollador el último otra vez, la incapacidad de los gestores muchas veces supone un problema terrible para el desarrollador, como no.
5. Documentación. Además del código el programador debe crear documentación que suele incluir documentación para el usuario final y documentación del propio programa en algunos casos.
6. Aplicaciones, métodos o clases sin documentación. Es bastante frustrante tener que implementar una API que tenga una documentación prácticamente nula dejándonos el método de “A ver qué pasa si ejecuto este método” como única solución.
7. Hardware. Los errores de hardware son realmente complicados de detectar y conllevan el cabreo del usuario final, pensando éste que el principal problema está en que la aplicación está mal desarrollada.
8. Imprecisiones. Irritante como lo que más es la imprecisión tanto en el nivel de usuario como en el de desarrollo y diseño, cosas que se deberían pulir realmente y que suelen venir desde fases anteriores que suelen ser más abstractas.
9. Otros programadores. Choques de personalidad, problemas de comprensión, falta de habilidad en la comunicación, falta de iniciativa, apatía hacia el código o el proyecto…
10. Tu propio código 6 meses después. Cuando seis meses después intentas reciclar tu propio código es cuando te preguntas si realmente eres tan malo documentando como los demás.

El original está en ingles “Top 10 Things That Annoy Programmers” y ha sido traducido en Variable Not Found.