Aprende a programar en 10 años

Encontré este artículo hace tiempo, escrito por Peter Norvig. Lo traduje a falta de una versión en español completa y neutral, y lo comparto con ustedes.

No me tomo crédito por el artículo. No incluye comentarios de mi parte. Yo únicamente hice la traducción.

Aprende a programar en 10 años

¿Por qué todos tienen tanta prisa?

Ve a cualquier librería, y encontrarás cómo Aprender Java en 7 Días (Teach Yourself Java in 7 Days) junto a interminables variantes ofreciendo cómo aprender Visual Basic, Windows, Internet y muchos más en unos cuantos días u horas. Hice la siguiente búsqueda en Amazon.com:

pubdate: after 1992 and title:
days and (title: learn or title: teach yourself)

y obtuve 248 resultados. Los primeros 78 fueron libros de computación (el número 79 fue Learn Bengali in 30 days, Aprenda bengalí en 30 días). Reemplacé "days" con "hours" y obtuve un resultado notablemente similar: 253 libros más, con 77 sobre computadores seguidos por Teach Yourself Grammar and Style in 24 Hours (Aprende Gramática y Estilo en 24 Horas) en el número 78. Fuera de los 200 primeros, 96% fueron libros sobre computación.

La conclusión es que, o la gente está muy apresurada por aprender computación, o las computadoras son algo tan fabulosamente fácil de aprender como ninguna otra cosa. No hay libros de cómo aprender Beethoven, o Física Cuántica, o Estética Canina, en unos cuantos días. Felleisen y otros hablan de esto en su libro How to Design Programs (Cómo diseñar programas), diciendo Programar mal es fácil. Los idiotas pueden aprenderlo en 21 días, aún si son tontos (dummies).

Analicemos lo que el título Aprenda C++ en Tres Días (Learn C++ in Three Days) puede significar:

  • Aprenda: En tres días no tendrás tiempo para escribir suficiente código significativo, y aprender de tus aciertos y errores. No tendrás tiempo para trabajar con un programador experto y entender lo que es vivir en un ambiente en C++. En resumen, no tendrás tiempo para aprender mucho. Así que el libro puede hablar únicamente de una familiaridad superficial, no de una comprensión profunda. Como dijo Alexander Pope, aprender poco es algo peligroso.
  • C++: En tres días podrías aprender algo de la sintaxis de C++ (si es que ya conoces otro lenguaje), pero no podrás aprender mucho sobre cómo usar el lenguaje. En resumen, si fueras, digamos, un programador de Basic, podrías aprender a escribir programas del estilo de Basic usando sintaxis de C++, pero no podrás aprender para qué es realmente bueno (y malo) C++. Así que ¿cuál es el punto? Alan Perlis dijo alguna vez: Un lenguaje que no afecta tu forma de pensar en la programación, no merece ser aprendido. Es posible que aprendas un poco de C++ (o más probablemente, algo como Javascript o Flash’s Flex) porque necesitas interactuar con una herramienta existente para realizar cierta tarea. Pero entonces, no estás aprendiendo a programar; estás aprendiendo a realizar esa tarea.
  • en Tres Días: Desafortunadamente, no es suficiente, como se muestra a continuación.

Algunos investigadores (Bloom (1985), Bryan y Harter (1899), Hayes (1989), Simmon y Chase (1973) han demostrado que toma alrededor de diez años desarrollar experiencia en gran variedad de áreas, incluyendo ajedrez, composición musical, manejo de telégrafo, pintura, piano, nadar, tenis, e investigación en neuropsicología y topología. La clave es la práctica deliberada: no sólo hacerlo una y otra vez, sino retarte a ti mismo con una tarea que va más allá de tus habilidades actuales, intentarlo, analizar tu desempeño durante y después de hacerlo, y corregir cualquier error. Entonces repetirlo. Y una vez más. No parece haber atajos: incluso a Mozart, quien fue un prodigio musical a los 4 años, le tomó 13 años más convertirse en músico de clase mundial. En otro género, los Beatles parecieron incursionar con una serie de hits #1 y una aparición en el show de Ed Sullivan en 1964. Pero ya habían estado tocando en un pequeño club en Liverpool y Hamburg desde 1957, y aunque tuvieron un gran número de seguidores desde el principio, su primer gran éxito, Sgt. Peppers, fue lanzado en 1967. Malcolm Gladwell reporta que un análisis a estudiantes de la Academia de Música de Berlín comparó a los alumnos separados en grupos de desempeño alto, medio y bajo y les preguntó cuánto dedicaban a practicar:

Todos, de los tres grupos, comenzaron tocando aproximadamente a la misma edad – por los cinco años. En esos primeros años, todos practicaban más o menos el mismo tiempo – unas dos o tres horas a la semana. Pero alrededor de los ocho años, las verdaderas diferencias comenzaron a notarse. Los estudiantes que terminaron como los mejores de su clase practicaban más que los demás: seis horas a la semana a los nueve años, ocho a los 12 años, 16 horas a la semana a los 14, y cada vez más, hasta que a los 20 años practicaban más de 30 horas a la semana. A los 20 años, los músicos de élite tenían una totalidad de 10,000 horas de práctica en el transcurso de su vida. Los estudiantes con desempeño medio tenían, en contraste, un total de 8,000 horas, y los futuros profesores de música, sólo arriba de 4,000 horas.

Así que 10,000 horas, no 10 años, es el número mágico. (Henri Cartier-Bresson (1908-2004) dijo Tus primeras 10,000 fotografías son las peores, pero él tomaba más de una por hora). Samuel Johnson (1709-1784) pensó que esto tomaba aún más tiempo: La excelencia en cualquier área puede ser obtenida únicamente con el trabajo de una vida entera; no se puede comprar a un precio menor. Y Chaucer (1340-1400) dijo La vida es corta, y el arte, muy largo para aprenderlo. Hipócrates (c. 400BC) es conocido por el extracto ars longa, vita brevis, que es parte de la cita Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile, que se puede traducir como vida corta, arte largo, oportunidad efímera, experimento traicionero, juicio difícil. Aunque en latín, ars puede significar arte o artesanía, en el griego original, la palabra "techne" sólo puede significar "habilidad", no "arte".

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

  • Interésate en la programación, y hazlo de vez en cuando sólo por diversión. Asegúrate que sea lo suficientemente entretenido para que siga gustándote en diez años.
  • Conversa con otros programadores; lee otros programas. Esto es más importante que cualquier libro o curso.
  • Programa. La mejor forma de aprender es con aprender haciéndolo. Dicho de manera más técnica, el máximo nivel de desempeño para los individuos en cierto campo no se obtiene automáticamente en función de la experiencia extendida, sino que el nivel de desempeño puede incrementar incluso en individuos muy expertos como resultado del esfuerzo deliberado de mejorar. (p. 366) y el aprendizaje más efectivo requiere una tarea bien definida con un nivel de dificultad apropiado para el individuo, retroalimentación informativa y oportunidades de repetición y corrección de errores. (p. 20-21) El libro Cognición en Práctica: Mente, Matemáticas, y Cultura en la Vida Cotidiana es una referencia interesante de este punto de vista.
  • Si quieres, estudia una carrera universitaria (o en una escuela de graduados). Esto te dará acceso a algunos trabajos que requieran un grado académico, y te ayudará a comprender mejor el área, pero si no te gusta la escuela, puedes (con algo de dedicación) obtener una experiencia similar en el trabajo. En cualquier caso, aprender solo de libros no será suficiente. La educación en ciencias computacionales no puede hacer experto programador a nadie, así como estudiar brochas y pigmentos no puede hacer a alguien un experto pintor dice Eric Raymond, autor de El nuevo Diccionario de Hackers. Uno de los mejores programadores que he contratado sólo tenía certificado de preparatoria; produjo mucho software bueno, tuvo su propio grupo de noticias, e hizo tanto dinero en acciones como para comprar su propio club nocturno.
  • Trabaja en proyectos con otros programadores. Sé el mejor programador en algunos; sé el peor en otros. Cuando eres el mejor, probarás tus habilidades como líder, e inspirarás a los demás con tu visión. Cuando seas el peor, aprenderás lo que hacen los maestros, y lo que no les gusta hacer (lo que te pongan a hacer por ellos).
  • Trabaja en proyectos después de otros programadores. Involúcrate en comprender un programa escrito por alguien más. Fíjate en lo que tardas en comprenderlo y arréglalo cuando el programador original no te vea. Piensa en cómo diseñar tus programas para hacerlo más fácil a quienes tengan que mantenerlo por ti.
  • Aprende al menos una docena de lenguajes de programación. Incluye 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 de C++), uno que soporte co-rutinas (como Icon o Scheme), y uno que soporte paralelismo (como Sisal).
  • Recuerda que existe una "computadora" en el término "ciencias de la computación". Aprende cuánto tarda tu computadora ejecutando una instrucción, leyendo una palabra de la memoria (con y sin errores de caché), leyendo palabras consecutivas del disco, y buscando una nueva localidad de memoria (Respuestas aquí).
  • Involúcrate en el programa de estandarización de algún lenguaje. Podría ser el comité ANSI C++, o podría ser decidiendo si el código de tu equipo tendrá dos o cuatro espacios de indentación. Como sea, aprenderás lo que a otras personas les gusta en un lenguaje, que tan a fondo les gusta, y tal vez incluso por qué les gusta.
  • Ten la cordura para liberar ese programa de estandarización tan rápido como sea posible.

Con todo esto en mente, es cuestionable qué tan lejos puedes llegar con los libros. Antes de que naciera mi primer hijo, leí todos los libros How To (Cómo hacerlo), y aún me sentía como un novato perdido. Treinta meses después, cuando nació mi segundo hijo, ¿volví a los libros? No. En vez de eso, confié en mi experiencia personal, que resultó ser mucho más útil y tranquilizante para mí que miles de páginas escritas por expertos.

Fred Brooks, en su ensayo No Silver Bullet (Sin balas de plata) identificó un plan de tres partes para encontrar a grandes diseñadores de software:

  • Identificar sistemáticamente a buenos diseñadores a temprana edad.
  • Asignar un mentor para ser responsable del prospecto y mantener su expediente.
  • Proveer oportunidades a los diseñadores en crecimiento para interactuar y estimularse mutuamente.

Con esto se asume que algunas personas ya tienen las cualidades necesarias para ser un gran diseñador; el trabajo ayudará a integrarlos en el ambiente. Alan Perlis lo pone más claro: A cualquiera se le puede enseñar a esculpir: Miguel Ángel pudo haber sido educado para no hacerlo. Así es con los grandes programadores.

Así que, adelante, compra un libro de Java; probablemente le encontrarás provecho. Pero no cambiarás tu vida, ni tu experiencia como programador en 24 horas, ni días, ni siquiera 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.
  • Bryan, W.L. & Harter, N. "Studies on the telegraphic language: The acquisition of a hierarchy of habits". Psychology Review, 1899, 8, 345-375
  • Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.
  • Chase, William G. & Simon, Herbert A. "Perception in Chess" Cognitive Psychology, 1973, 4, 55-81.
  • Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Respuestas

Tiempo aproximado de distintas operaciones en una PC convencional:

ejecutar una instrucción típica 1/1,000,000,000 s = 1 ns
leer de la memoria de caché L1 0.5 ns
predicción de salto errónea 5 ns
leer de la memoria de caché L2 7 ns
cierre/apertura de exclusión mutua 25 ns
leer de la memoria principal 100 ns
enviar 2KB por una red de 1Gbps 20,000 ns
leer secuencialmente 1MB de memoria 250,000 ns
encontrar dentro de una posición de un disco nuevo 8,000,000 ns
leer secuencialmente 1MB del disco 20,000,000 ns
enviar un paquete de EEUU a Europa y de regreso 150 ms = 150,000,000 ns
s: segundos
ns: nanosegundos
ms: milisegundos
KB: Kilobyte
MB: Megabyte
Gbps: Gigabits por segundo

Selección del lenguaje

Muchas personas han preguntado qué lenguaje de programación deben aprender primero. No hay una respuesta a esto, pero se deben considerar estos puntos:

  • Usa a tus amigos. Cuando me preguntan ¿qué sistema operativo debo usar, Windows, Unix o Mac?, mi respuesta normalmente es: lo que sea que usen tus amigos. La ventaja que obtengas de aprender de tus amigos compensará cualquier diferencia intrínseca entre sistemas operativos, o entre lenguajes de programación. También considera a tus amigos futuros: la comunidad de programadores de la cual serás parte si continúas en esto. ¿Los lenguajes que eliges tienen una gran comunidad o una pequeña? ¿Los libros, sitios web y foros de ayuda en línea son suficientes para obtener respuestas? ¿Te agrada la gente en esos foros?
  • Mantenlo simple. Lenguajes de programación como C++ y Java están diseñados para desarrollo profesional y equipos de programadores expertos que se preocupan por la eficiencia en tiempo de ejecución. Por lo tanto, estos lenguajes tienen partes complejas para esas circunstancias. A ti te preocupa aprender a programar. No necesitas esas complicaciones. Quieres un lenguaje diseñado para programadores nuevos, que sea fácil de aprender y recordar.
  • Juega. ¿De qué manera te gustaría aprender a tocar piano? ¿la normal, interactiva, en la que oyes cada nota cuando la tocas, o en modo "batch", en el que sólo oyes las notas cuando terminaste la canción completa? Claramente, el modo interactivo hace más fácil aprender piano, y también la programación. Busca un lenguaje con un modo interactivo y úsalo.

Dados estos criterios, mi recomendación para un programador novato serían Python o Scheme. Pero las circunstancias pueden variar para cada persona, y hay otras buenas opciones. Si tu edad tiene un sólo dígito, tal vez prefieras Alice o Squeak (aprendices de edad avanzada podrían disfrutarlos también). Lo importante es que elijas uno y comiences.


Apéndice: Libros y otros recursos

Muchas personas me han preguntado qué libros y sitios web deberían estudiar. Repito que "un libro solo no será suficiente" pero puedo recomendar los siguientes:


Notas

T. Capey señala que la página del libro Complete Problem Solver en Amazon ahora tiene los libros "Teach Yourself Bengali in 21 days" y "Teach Yourself Grammar and Style" bajo la sección de "Clientes que compraron este artículo también compraron éstos". Supongo que una gran parte de la gente que vio ese libro viene de esta página. Gracias a Ross Cohen por su ayuda con Hipócrates.

Peter Norving (Copyright 2001)

Artículo original (en inglés).

Anuncios

Autor: Israel Muñoz

Soy desarrollador de software, principalmente dedicado a desarrollo de aplicaciones web. Especializado en .NET full-stack, además de tecnologías front-end HTML, CSS y JavaScript. A ratos, profesor de materias de informática. Me gusta mucho todo lo que tiene que ver con las tecnologías nuevas para desarrollo web, y el diseño de sitios y aplicaciones.

Un comentario en “Aprende a programar en 10 años”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s