Aprendí a programar durante un largo y largo lapso.
Los primeros programas que escribí (bastante mal, podría agregar), estaban en BASIC en una variedad de máquinas. Realmente no sabía lo que estaba haciendo y en su mayoría solo estaba experimentando, a partir de ejemplos en la documentación o revistas. Modificaba los programas existentes para hacer cosas nuevas, o escribía nuevos programas y me topaba con los límites de mi conocimiento. La mayoría de mis programas eran horribles. Pero, me mantuve en ello.
Para mi octavo cumpleaños, recibí una TI-99 / 4A.
En ese momento, ya sabía algo de BASIC de otras máquinas a las que tenía acceso (principalmente Commodore VIC-20 y Commodore 64). Me lancé a aprender TI BASIC, y luego a TI Extended BASIC. También obtuve una suscripción a 99’er Magazine (más tarde conocida como Home Computing Magazine), e intenté absorber todo lo que pude desde cualquier ángulo: revistas, libros, lo que sea.
Alrededor de 4 años después, obtuve un cartucho de memoria Mini de TI. Este cartucho con respaldo de batería le permite programar en lenguaje ensamblador para la TI-99 / 4A. Me enseñé el lenguaje ensamblador y comencé a aprender cómo funcionaban los niveles más bajos de la computadora.
También aproveché todas las oportunidades que pude para aprender a programar otras computadoras (principalmente en BASIC en este momento), incluyendo Commodore PETs, Apple] [s, TRS-80s, IBM PCs, etc. Había muchos puntos en común, pero también muchas diferencias.
Avancé unos años y obtuve acceso a un compilador de Pascal. Hubo Apple Pascal en Apple ///, y Turbo Pascal 3 en la PC. Pasé la mayor parte de mi tiempo de Pascal en Turbo Pascal. (Realmente nunca entendí a Apple Pascal).
Pascal me enseñó acerca de las funciones y procedimientos y la programación estructurada de una manera que BASIC no pudo. BÁSICO, después de todo, carecía de variables locales. Bueno, al menos ese fue el caso de la forma más común de BASIC, programada en el estilo más típico. TI Extended BASIC ofreció subrutinas estructuradas, al igual que QBASIC, pero su utilidad se perdió en mí hasta que encontré a Pascal, lo que me obligó a aprenderlas y apreciarlas .
Intenté enseñarme C durante la escuela secundaria, pero la falta de acceso a un compilador decente me frenó. Sin embargo, cuando llegué a la universidad, aprendí C durante mi primer año y no miré hacia atrás.
Paralelamente, aprendí varios lenguajes de ensamblaje: TMS9900, 6502 y 8086. No era necesariamente un gran programador en ninguno de estos. Pero, logré generar algunos hacks decentemente frescos.
Durante años después de eso, fui programador de ensamblados en C +. Tomé más lenguajes de ensamblaje cuando encontré nuevos procesadores. 6805, 68HC11, 8051, etc.
A lo largo de todo este tiempo, hubo un hilo común: realmente no sabía lo que estaba haciendo. Pero, seguí jugando con eso, y cuando empecé a darme cuenta de lo que estaba haciendo, empujé el sobre a nuevos espacios donde no sabía realmente lo que estaba haciendo. Hubo algunas dinámicas clave que sentí que sirvieron como claves para mi éxito:
- Estar cómodo con no saber lo que estaba haciendo, pero aun así tratar de hacerlo de todos modos. Si alguna vez hubiera sentido que no debería hacer esto porque no sabía cómo, nunca lo habría intentado. En cambio, lo tomé como un reto para resolverlo.
- Nunca estar cómodo con solo tener éxito. Una vez que me di cuenta de lo que estaba tratando de resolver, eso significaba que era hora de descubrir lo siguiente. No me sentía cómodo quedándome quieto después de haber logrado mi meta a corto plazo.
- Tratando de averiguar “cómo hicieron eso”. Siempre he tenido la sed de descubrir cómo funcionan las cosas y cómo replicar las cosas que me cautivaron. Si no pudiera encontrar un libro o artículo que lo explicara, trataría de descifrarlo por mí mismo.
- Intentar descifrar o aprender mejores maneras, y no siempre suponer que sé mejor. Recuerdo la primera vez que vi una implementación rápida (en Northstar Z80 BASIC), y me preguntaba cómo una rutina con una llamada a RND en el medio podría arreglar las cosas. Estaba transfiriendo el código entre dos máquinas, y reimplementé el ordenamiento como una especie de burbuja. Pero archivé eso en mi memoria y luego supe cómo funciona el ordenamiento rápido y por qué RND era importante. Desde entonces, he intentado desafiar mis suposiciones cuando veo algo que no tiene sentido, y desafiar las suposiciones de los demás cuando dicen “Deberías hacerlo de esta manera”. Por lo que sé, podría estar en un lado o en el otro de la división de quicksort-vs-bubblesort, y ellos también podrían. Esa experiencia con quicksort fue tanto humillante como empoderadora.
- Me di desafíos continuos. Programé por diversión, y parte de eso es buscar nuevos desafíos para estirar las habilidades. Competí en concursos de programación, por ejemplo. Muchos de los involucrados tenían problemas complejos de optimización, que me enseñaron un nuevo conjunto de habilidades. También desarrollé un emulador de Intellivision, una cadena de herramientas y algunos juegos. Para mí, hice de la programación un esfuerzo casi diario.
- Mantenía mi juego actual (al menos eventualmente). Una vez que aprendí C y las estructuras de datos, hubo un período en el que pensé que sabía todo lo que necesitaba saber. Pero con el tiempo, se hizo evidente que no lo hice. Había clases crecientes de programas que ni siquiera sabía cómo probar la programación. Finalmente, me saqué de mi rutina y aprendí lo que podríamos llamar “C ++ moderno”. (Y antes de eso, me lancé a Perl 5, y luego a Perl 5 + Moose). Esa inducción incluía el aprendizaje orientado a objetos, varios patrones de diseño, programación genérica, etc.
- Enseñar a los demás. No hay una prueba más fuerte de tus propias habilidades que tratar de enseñárselas a otra persona. Si realmente tratas de enseñar a otros cómo hacer algo, hasta el punto de que comprendan, tienes que entender bien el material.
En estos días, cuando se trata de la programación de cualquier lenguaje en particular, hay una gran cantidad de recursos en línea para darle los detalles. Algunos de esos recursos ofrecerán enfoques de libros de cocina para problemas comunes, y otros son más abstractos, no están vinculados a un lenguaje específico. Y hay mucho en el medio.
Si realmente desea aprender a programar “en general”, entonces querrá enfocarse en comprender esos recursos más abstractos. Claro, puede confiar en un enfoque de libro de cocina para resolver un problema. Pero vale la pena entender por qué funciona y cómo podría traducirlo a otro idioma (si tiene sentido hacerlo), o modificarlo si tiene un problema ligeramente diferente.
Vale la pena leer artículos de programadores expertos sobre formas de atacar problemas. Vale la pena intentar comprender los estilos de programación que aún no ha utilizado. (Imperativo, procedimental, orientado a objetos, genérico, funcional …) Cada uno le da una perspectiva diferente sobre el problema que está tratando de resolver y le brinda diferentes herramientas para atacarlo.
Y lo más importante: PRÁCTICA. Para aprender realmente a programar, necesitas programar. Regularmente. Todo el tiempo. Si no practicas una habilidad, la perderás.
Hay algunas habilidades de programación que probablemente he perdido. Si me pidieras que escribiera un programa de Pascal hoy, probablemente lo haría muy mal. Probablemente volveré a la competencia básica en unos pocos días, pero no sería un experto de inmediato. Pero si me pidiera que reuniera un script en perl y un programa en C ++ 14, sería mucho más eficiente. ¿Por qué? Práctica regular en esos idiomas.
Pero incluso con el programa Pascal, mis problemas principales serían la sintaxis y los idiomas específicos del idioma. Los algoritmos y los enfoques para estructurar y descomponer problemas tienden a ser agnósticos del lenguaje.
Resumiendo: aprendí a codificar haciendo. Busqué recursos para ayudarme cuando y donde pueda. No me rendi Me permití sentirme cómodo operando en el límite de mi conocimiento y capacidad, y continué empujando esa frontera hacia adelante. Traté de enseñar a otros lo que sé, lo que me obligó a saberlo mucho mejor. Reconocí que no lo sé todo y que podría aprender algo de aquellos que lo saben mejor. Y finalmente, no solo “hice”, seguí “haciendo” y seguí “haciendo”. No hay sustituto para la práctica.