No es mejor programador el que mejor se aprende el manual

Hay cierta tendencia en algunas comunidades de desarrolladores a considerar que el programador más brillante es aquel que mejor conoce la api de su lenguaje de elección. Se muestra respeto, incluso cierta veneración, por aquél que es capaz de recitar de carrerilla la cadena de herencia de un componente de interfaz de usuario, siendo ese respeto y admiración directamente proporcionales a la profundidad de esa cadena de herencia.

Pero tener buena memoria no tiene porqué significar lo mismo que ser competente. En realidad el aprendizaje compulsivo de una api puede ser un recurso para esconder ciertas carencias.

No digo con esto, evidentemente, que no haya que tener cierto conocimiento de qué se puede y quéno se puede hacer con la api del lenguaje. Pero ese conocimiento debe estar orientado sobre todo a evitar el reinventar la rueda, el implementar cosas que ya están implementadas.

Programar es una actividad creativa. Requiere de una creatividad distinta a la que necesita un diseñador cuando está frente a un documento de Freehand recién creado, pero no por ello deja de precisar de altas dosis de imaginación, abstracción, intuición, aprovechamiento de las propias experiencias, capacidad de improvisación y de cambiar y adaptar sobre la marcha la idea inicial.

¿Qué es preferible, por tanto, trabajar en la fijación en la memoria de una lista de funciones que va a cambiar, que va a ser modificada, ampliada por un extremo y reducida por el otro en la próxima revisión del lenguaje, o intentar mejorar la intuición, la capacidad de abstracción, el lado creativo en definitiva?. Porque, si hay algo seguro en este mundo, es que la api va a cambiar. Las librerías de la primera versión pública de Java (Java 1.02) eran alrededor de 200 clases. Hoy, sólo en J2SE hay unas 3500. ¿Qué inversión es más rentable a largo plazo, la memorización de esas librerías, o la interiorización de aquello para lo que se pueden utilizar, de forma que se pueda volver a ellas como referencia cuando sea necesario concretar una solución?

Porque el manual siempre va a estar ahí, encima de la mesa, dispuesto a echar una mano cuando se le pida. El problema es que el manual que va a estar ahí mañana no tiene porqué ser el mismo que está hoy. Entre otras cosas porque el lenguaje en el que tenemos que trabajar puede cambiar. ¿O es que a nadie le ha caído nunca un proyecto encima en un lenguaje del que no tenía ni idea?

Además, si sólo se mira al manual, si sólo se saben atacar los problemas del día a día a base de academicismo se cae en el peor de los riesgos que puede asumir un programador: el anquilosamiento, la muerte de la imaginación, la muerte de la capacidad para buscar soluciones alternativas. Cuando todo se basa en seguir los procedimientos, en atenerse a una forma estricta y encorsetada de hacer las cosas, se pierde la capacidad de buscar soluciones alternativas, que antes o después, van a ser necesarias.

Y si algo se necesita, a día de hoy, con la complejidad del software que construimos, es la capacidad de respuesta, de implementar soluciones imaginativas, de pensar sin restricciones, sin corsés. No es fácil, no...

Usuarios que han visto este tema también han visto...

- Consejos para tu Blog
- Tu sitio web en dispositivos móviles
- ¿Widgets, gadgets, artilugios…? ¿Son realmente útiles?
- Avatar marketing
- Cultura electronica

- Versión imprimible de este documento

- Enviar por e-mail este documento