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...
Comentarios
Cesar, estupenda puntualización. A mi parecer el verdadero programador es el que conoce las herramientas y sabe utilizarlas (cómo y dónde) en los casos necesarios.
He visto programadores de los que hablar crear arrays de arrays de arrays para recorrer una estrucutra, mientras que otros más "prácticos" lo resuelven con su creatividad y práctica.
Me recuerda a cuando se estudía, que nos decían que lo importante era entenderlo y no memorizar.
Saludos,
Publicado por: Esteban | Mayo 3, 2006 12:46 PM
Muy cierto todo lo que dices, IMHO, lo importante no es la herramienta, sino saber como hacer las cosas.
Otro artículo que va por la misma onda:
http://www.codinghorror.com/blog/archives/000575.html
Saludos
Publicado por: Alex | Mayo 4, 2006 12:26 AM
Muy buen punto, por eso yo parto de la idea de que solo hay que entender la lógica de los lenguajes como tal, a la final casi todos se parecen. Luego está la sintaxis y los recursos que ofrezca cada uno. Un escritor no necesita saberse el diccionario para escribir un libro y jamas se lo va a saber. Igual pasa en todas las expresiones humanas, y existen estilos, tendencias, formas, etc, que los gringos, con su mente bien cuadrada basada en estadísticas y manuales llaman muy acertadamente Patrones. Sin embargo, aprendiéndose de memoria todos los patrones igual no se hace nada, lo importante es saber usarlos "donde y cuando" como decía Esteban.
Justamente hoy encontré la solución a un problema que tenía en la lista de osflash.org y de verdad me impresionó la creatividad de quien la creó. El problema era usar emoticones en un chat que estoy haciendo, y Flash si bien soporta incluir imágenes dentro de campos de texto en formato html este deforma el texto y lo hace discontinuo, es decir, luego de cada imagen salta a una nueva línea. Bueno a Simon se le ocurrió la brillante idea de crear los emoticones a partir de una fuente tipográfica hecha por el mismo también, entonces así los emoticones se incluyen como un caracter mas. Y mas impresionante, los emoticones son de colores y se forman superponiendo cada color que en realidad son letras. Realmente impresionante la creatividad y funciona perfecto. E aquí la información:
http://chattyfig.figleaf.com/pipermail/flashcoders/2005-November/154296.html
Saludos
Publicado por: Rafael | Mayo 4, 2006 03:43 AM
Yo tengo una postura un tanto distinta. Si bien estamos totalmente de acuerdo en que la creatividad y la habilidad para resolver el problema es fundamental, para lograr esta experticia es necesario, mas no suficiente, el tener un suficiente bagaje de conocimientos.
Como dice Rafael, al final todos los lenguajes se parecen un tanto, pero la única manera de lograr un resultado decente en uno, saliendo del "hola, mundo", es conociendo sus mañas y por lo menos parte del manual.
En latinoamerica le tenemos un susto tan grande a los manuales y a las especificaciones que es natural que se tome en cuenta a quien lo hace.
Resumen: no se puede tener creatividad y habilidad sin conocimientos, tanto adquiridos por lecturas como por la experiencia. Pedir creatividad sin trabajo previo sólo lleva a reinventar la rueda.
Publicado por: Clbustos | Mayo 4, 2006 09:24 AM
Efectivamente, yo mismo he planteado la necesidad de conocer la api para no reescribirla, pero ese conocimiento basta con que sea a alto nivel, con que se sepa qué es lo que ya hay implementado, sin necesidad de llegar a extremos como conocer la lista de parámetros de un método determinado de una clase dada, cuando eso es algo que está en la documentación de cualquier lenguaje.
En lo que quiero insistir es en que es mucho más práctico a medio y largo plazo el comprender el lenguaje que el aprender el lenguaje de memoria
Publicado por: Cesar Tardaguila | Mayo 4, 2006 10:21 AM