Programadores: Lo que decimos vs. Lo que realmente queremos decir

Entre celebración y celebración por el día del programador, nos tomamos una pausa para el blog :)

Lo que un programador dice, y lo que en verdad quiere decir: Las frases más comunes para librarnos de culpa y juzgar a otros -sobretodo a los que nos caen mal-.

A continuación, su análogo en español:

Los 6 tipos de Programador

Con 7 años de experiencia, 2 empleos, 5 equipos de trabajo, 

y ya habiendo liderado de 2 de ellos, puedo darme el lujo de "clasificar" a mis compañeros de trabajo en distintos tipos de programadores, según la calidad de su trabajo.

Pero no es sino después de leer un artículo de Steven Benner, en donde describe casi a la perfección a los tipos de programadores con los que uno tiene que lidiar. Si tal vez no son todos, sí que son los más reincidentes:

1. El parchador. (The duct tape programmer)

Puede que el código no sea lindo,
pero maldición, ¡funciona!

Este tipo es la base de tu empresa. Cuando algo vaya mal, él lo reparará ipso facto y dejándolo funcionando correctamente.

Pero -por supuesto- no le interesa nada más:
cómo se vea, la facilidad de uso, el orden del código, técnicas de programación, variables innecesarias, la optimización de algoritmos, el mantenimiento, el uso de estándares, ni otra de esas "trivialidades".

Él sólo "hará que suceda", lo solucionará sin pérdida de tiempo.
La mejor forma de trabajar con él, es enfocarse en un problema y dejarlo trabajar.

Los 9 principios básicos para todo Programador

Hay algunos criterios que un aprendiz de programador no siempre toma en cuenta, por desconocimiento;
o peor aún: que un programador "experimentado" no toma en cuenta por mediocridad negligencia.

Según creo, estos criterios necesitan ser enseñados explícitamente a los newbies y amateurs, aunque también son aprendidos y comprobados durante la práctica; para finalmente, ser aplicados inconscientemente de manera intrínseca por un programador experimentado.

1. Desarrollar código fácil de entender.

Así, se hace código comprensible trascendiendo el tiempo; y no tener que deducir tantas las líneas de código.

Pero eso no es suficiente:

No comentar todo (cada declaración de variables, cada abrir y cerrar de llaves, cada conexión a BD), porque demasiados comentarios irrelevantes quitan atención a los comentarios importantes.

Un buen complemento a los comentarios también es el hacer un código claro y bien definido, no redundante ni aglutinado.

Tal vez cause gracias, pero siendo objetivos: Es egoísta e inmaduro.

2. No complicar el código.

Muchas veces solucionamos algún problema de la forma más enredada por dar una impresión de "soluciones complejas desde una mente compleja". 

O peor aún: porque no queremos dedicarle más tiempo para simplificar la solución.

El arte de la programación está en la abstracción de desarrollar soluciones sencillas para problemas complicados. 

Debemos buscar la forma más simple de resolver las cosas. Esto ayudará a entender el código mejor y a mantenerlo* de una manera más eficiente, haciéndolo menos propenso a errores.