Para ser un buen programador

Para comenzar yo no soy un programador, si bien conozco de C, y he hecho programación durante los años de la universidad, no soportaría los requerimientos que tienen los programadores actuales. (Uso de varios lenguajes, transacciones con BBDD, diseño de interfaz de usuario, diseño de proyectos, etc.)
Pero me gusta, es interesante y hasta más sencillo que entender a una persona. Entre los libros que me gustan bajar, hay varios de programación, y ya viene siendo hora de que los revise y me ponga a aprender, encontré algunas líneas de interés para los programadores o las personas que gustarían de ser programadores (aunque dudo mucho de que puedan liberarse de las personas, como están organizadas las empresas el programador no cuenta con administrador del proyecto y menos tiempo y recursos para hacer un correcto desarrollo de software, desarrollo sin UML, que risa me dan.)
Prentice Hall Linux Programming by Example por Arnold Robbins, autor muy conocido en el mundo de Unix.
Aquí la traducción del Apéndice A de dicho libro, muy interesante por cierto:

Apéndice A. Enséñese a Programar en Diez Años

"Experiencia, s: Algo que no obtiene hasta justo después que lo necesite."
-Olivier

Este capítulo está escrito por y Protegido por Derechos de Autor © 2001 por Peter Norvig. Reimpreso con permiso. El artículo original, incluyendo los enlaces, están en http://www.norvig.com/21-days.html. Lo hemos incluido por que creemos que lleva un importante mensaje. La anotación anterior es una de nuestras favoritas de siempre, y como se aplica al objetivo de este apéndice, lo hemos incluido también.

¿Por qué todos están tan apurados?

Ingrese a una librería, y verá como Teach Yourself Java in 7 Days así como infinidad de variaciones ofreciendo enseñarle Visual Basic, Windows, el Internet, y demás en pocos días u horas.
Hice la siguiente busqueda en Amazon.com:
pubdate: after 1992 and title: days and (title: learn or title: teach yourself)
obteniendo 248 resultados. Los primeros 78 eran libros de computación (el número 79 era Teach Yourself Bengali in 30 Days). Reemplacé "días" por "horas" y sorprendentemente obtuve resultados similares: cerca de 253 libros, con 77 libros de computación seguidos por Teach Yourself Gramatic and Style in 24 Hours como número 78. De los primeros 200, 96% eran libros de computación.
La conclusión es que la gente está apurada para aprender acerca de las computadoras, o que las computadoras son de alguna manera fáciles de aprender que todo lo demás. No hay libros acerca de aprende Beethoven; o Física Cuántica, o aún Crianza de Perros en unos pocos días.
Analicemos que puede significar un título como Teach Yourself Pascal in 3 Days:

Aprender: En 3 días no tendrá tiempo para escribir varios programas relevantes, y de aprender de sus progresos y fracasos. Usted no tendrá tiempo para trabajar con un programador experimentado y aprender lo que es vivir en ese ambiente. Resumido, usted no tendrá tiempo para aprender mucho. Entonces ellos solo pueden estar hablando de una familiaridad superficial, no de un profundo entendimiento. Como Alexander Pope dijo,

un pequeño aprendizaje es una cosa peligrosa

.

Pascal: En 3 días usted tal vez pueda aprender la sintaxis de Pascal (si es que ya conocía un lenguaje similar), pero no aprenderá mucho de como usar la sintaxis. En resumen, si usted fuera un programados de Basic, usted podrá aprender a escribir programas en el estilo de Basic usando la sintaxis de Pascal, pero usted no podrá aprender para que es útil (e inútil) Pascal. Entonces, ¿cuál es el punto? Alan Perlis dijo una vez:

Un lenguaje que no afecte su forma de pensar acerca de la programación, no vale la pena aprender.

Un posible punto es que usted tenga que aprender un poco de Pascal (o usualmente, algo como Visual Basic o Javascript) por que necesita conectarlo con una herramienta existente para cumplir con una tarea específica. Pero, entonces usted no está aprendiendo como programar; esta aprendiendo como cumplir con esa tarea.

En Tres Días: Desafortunadamente, esto no es suficiente, como muestra la siguiente sección.

Enséñese a Programar en Dies Años

Los investigadores (Hayes, Bloom) han demostrado que toma cerca de diez años desarrollar la experiencia en cualquiera de una amplia variedad de áreas, incluyendo ajedrez, composición de música, pintura, piano, natación, tenis, e investigación en neuropsicología y topología. Parece que no hay atajos verdaderos, aún Mozart, que era un prodigio de la música a los 4 años, le tomo más de 13 antes de que comenzara a producir música de clase mundial. En otro género, los Beatles aparecen impactando la escena , apareciendo en el show de Ed Sullivan en 1964. Pero ellos estuvieron tocando desde 1957, y mientras tenían atractivo ya desde antes, su primer gran éxito , Sgt Peppers, fue lanzado en 1967. Samuel Johnson indica que toma más de diez años:

La excelencia en cualquier área puede obtenerse solo por la labor de una vida de duración; no se puede adquirir por un precio menor.

Y Chaucer replicó:

la vida tan corta, el arte muy largo para aprender.

Aquí mi receta para el éxito en la programación:

• Interesesé en la programación, y hagalo por que es divertido. Asegurese que siga siendo divertido así deseará poner 10 años de su parte.


• Hable con otros programadores; lea otros programas. Esto es más importante que otros libros o cursos de capacitación.


• Programe. La mejor clase de aprendizaje es haciendo. Para ponerlo de manera técnica,

  el máximo nivel de rendimiento para los individuos de cierto dominio no se obtiene automáticamente como una función de experiencia extendida, pero el nivel de rendimiento puede incrementarse aún en individuos altamente experimentados como resultado de esfuerzos deliberados de mejoramiento

  (p.366) y

  el aprendizaje más efectivo requiere tareas bien definidas con un apropiado nivel de dificultad para el individuo particular, retroalimentación informativa, y oportunidades para repetir y corrección de errores.

  (p. 20-21) El libro Cognition in Practise: Mind, Mathematics and Culture in Daily Life es una referencia interesante para este punto de vista.


• Si desea, ponga 4 años en una universidad (o más en una colegio de graduados). Esto le dará acceso a algunos trabajos que requieren credenciales, y le brindará un entendimiento más profundo del campo, pero si no gusta de la escuela, puede (con algo de dedicación) tener experiencias similares en el trabajo. En cualquier caso, estudiar de un libro no es suficiente.

  La educación en Ciencias de la Computación no hará de cualquiera un experto programador más que estudiar pinceles y pigmentos hará de cualquiera un experto pintor

  dice Eric Raymond, autor de The New Hacker's Dictionary. Uno de los mejores programadores que he contratado tenía solo secundaria completa; el producía buen y abundante software, tiene su propio grupo de noticias, y por opciones de participación es sin alguna duda más rico de lo que podría ser.


• Trabaje en proyectos con otros programadores. Sea el mejor programador en algunos proyectos; sea el peor en otros. Cuando sea el mejor, probará sus habilidades para dirigir el proyecto, y para inspirar a otros con su visión. Cuando sea el peor, aprenderá que hacen los expertos, y aprenderá que no gustan de hacer (por que harán que usted lo haga por ellos).


• Trabaje en proyectos después de otros programadores. Involúcrese en entender el programa escrito por alguien más. Vea que es necesario para entenderlo y arreglarlo cuando los programadores originales no estén. Piense en como diseñar programas para facilitar el trabajo de quienes le darán mantenimiento después de usted.


• Aprende al menos media docena de lenguajes de programación. Incluyendo un lenguaje que soporte abstracción de clases (como Java o C++), uno que soporte abstracción funcional (como LISP o ML), uno que soporte abstracción sintáctica (como LISP), uno que soporte especificaciones declarativas (como Prolog o plantillas C++ ), uno que soporte corutinas (como Icon o Scheme) y uno que soporte paralelismo (como Sisal).


• Recuerde que hay "computación" en "ciencias de la computación". Aprenda cuanto tiempo le toma a su computadora ejecutar una instrucción, tomar una palabra de memoria (con y sin perdida de cache), leer palabras consecutivas del disco, y buscar una nueva localización en disco.


• Involúcrese en un esfuerzo de estandarización de lenguaje. Puede ser el comite ANSI C++, o puede ser decidiendo si su estilo de programación local debe de tener 2 o 4 espacios de indentación. De cualquier manera, aprenderá que gusta a otra personas de un lenguaje, cuan profundo es su sentimiento y tal vez un poco de porque se sienten así.


• Tener el buen sentido para salir del esfuerzo de estandarización de lenguaje tan pronto como sea posible.

Con todo esto en mente, es cuestionable que tan lejos pueda llegar aprendiendo de libros. Antes de que mi primer hijo naciera, leí todos los libros How To, y aún me sentía como un principiante sin ideas. 30 meses después, cuando mi segundo hijo nació, ¿regresé a los libros para recordar? No. Confié en mi experiencia personal, que resulto ser aún más útil y reafirmante para mi que miles de páginas escritas por expertos.
Fred Brooks, en su ensayo No Silver Bullets identifico un plan de tres partes para encontrar a grandes diseñadores de software:

1. Sistemáticamente identifique a los mejores diseñadores tan pronto como sea posible.


2. Asigne un mentor de carrera que sea responsable por el desarrollo del prospecto y que mantenga cuidadosamente un archivo de carrera.


3. Provea oportunidades para diseñadores en crecimiento para interactuar y estimularse entre ellos.

Esto asume que algunas personas ya tienen las cualidades necesarias para ser un gran diseñador; el trabajo es coaccionarlos apropiadamente. Alan Perlis lo pone más sucintamente:

Cualquiera puede aprender a esculpir: Miguelangel debió aprender a no hacerlo. Lo mismo es para los grandes programadores.

Entonces, siga adelante y compre ese libro de Java; probablemente le encuentre un uso. Pero no cambiará su vida, o su experiencia general real como programador en 24 horas, días o aún meses.

Referencias

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol.20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver, Lawrence Erlbaum, 1989.

Lave, jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.