Una entrevista

¿Por qué escogí dedicarme a la programación de computadoras?

Para cuando tomé la decisión, en quinto de bachillerato, ya hacía unos tres años de haber escrito mi primer programa. Mis opciones fueron ingeniería electrónica (hardware) o ingeniería en sistemas computacionales (software). Decidí dedicarme a lo que ya era mi hobbie (pasatiempo) pues era algo que disfrutaba mucho y, además, era con lo que pronto conseguí mis primeras ganancias (escribí un programa para llevar la contabilidad básica de un negocio pequeño con una IBM PC y tal programa se vendió en repetidas ocasiones).

Programar una computadora para mí siempre ha sido sinónimo de diversión: la mayoría de mis primeros programas fueron juegos para mi propio disfrute. Además, la idea de que me pagaran por hacer lo que para mí es esparcimiento me sorprendió y no me desagradó.

¿Me ayudó en el campo laboral lo que me enseñaron durante la universidad?

Gran pregunta. En parte, sí, claro. Pero –ya se sabe– la pregunta clave es si yo aproveché las oportunidades a mi alcance en la universidad; es decir, lo que termina sirviendo de los sistemas escolares depende, en su mayor parte, del aprendiz, no de la institución. En otras palabras, lo que sirve es lo que aprendes por interés propio, no tanto lo que enseñan. Por supuesto, si en el camino uno se topa con una luminaria de maestro –caso esporádico en mi recorrido– entonces preguntar mucho es lo debido. Lo que sí tuvo una importancia capital es tener acceso sin restricción a todo el equipo de cómputo disponible en la institución: diversos tipos de computadoras y sus dispositivos periféricos, sistemas operativos, lenguajes, e incontables tomos de documentación de dichos sistemas. Me ofrecí de voluntario en el centro de cómputo de la escuela de ingeniería, me dieron copia de las llaves y todo el acceso sin restricción –aunque en alguna ocasión escribí un programa para conseguir la contraseña hacia un sistema que otros intentaron monopolizar, ¡los insulsos! (años después supe que ese tipo de programa le llaman “troyano”.)

Otro factor clave fue aprovechar el acervo bibliográfico disponible. Como sugiere Shelby Foote: «A university is just a group of buildings gathered around a library.» Una institución suele tener recursos para comprar ejemplares que no están al alcance de un joven aprendiz. Para mí, ahí encontré las bases de las que habla la gente, no en las aulas —el aula, en su mayor parte, es el espacio laboral del gremio magisterial; es decir, su objetivo es la enseñanza, no el aprendizaje, este último está principalmente en las manos del individuo con el gusto por indagar—. Sin embargo, cuando dicho acervo no fue suficiente, entonces averigüé en otros acervos: al no encontrar algún libro en la biblioteca de la universidad, entonces viajaba y pasaba horas en la biblioteca de ingeniería de la UNAM, en Ciudad Universitaria (por cierto, esa biblioteca también resultó ser una mina de oro).

No tardé en tomar conciencia de que el contenido académico oficial, para mi caso, era tan sólo una pequeña parcialidad del panorama teórico-práctico ya disponible. Este panorama, y no sólo aquella parcialidad, representa en realidad las bases de una profesión actual en cómputo. Por cierto, a decir del perfil teórico-práctico de los egresados que llegan a pedir trabajo hoy, sospecho que la misma toma de conciencia también se puede aplicar a muchos contenidos oficiales universitarios hoy en día. En cualquier caso es pertinente tomar nota de la respuesta de David Parnas ante la pregunta “What are the most exciting/promising software engineering ideas or techniques on the horizon?”: «I don’t think that the most promising ideas are on the horizon. They are already here and have been here for years but are not being used properly.»

¿Qué futuro veo para la carrera de tecnologías de información?

La revolución informática está en sus inicios, por lo que hay mucho por pensar y por practicar al respecto en diversidad de profesiones. En específico, las habilidades para programar computadoras y saber aplicar atinadamente las teorías del cómputo concurrente y distribuido para lograr sistemas confiables y robustos seguirán siendo habilidades y conocimientos muy importantes para la sociedad:

¿Por qué creo que son necesarias en la vida diaria las tecnologías de la información?

Los productos de la técnica informática abarcan más y más el territorio de lo cotidiano, y parece que tal tendencia continuará. Pero la aplicación técnica necesita enfocarse principalmente a resolver problemas reales en la sociedad, no sólo a crear necesidades artificiales que distraen nuestra atención hacia aquellos problemas. Por ejemplo, un problema real es el analfabetismo multifuncional de muchos de nosotros que con frecuencia no somos capaces de lograr una lectura básica de comprensión, ya sin mencionar una lectura crítica habitual (un epítome de tal analfabetismo se puede observar en algunos así llamados “líderes” políticos en posiciones de cabeza de gobierno de todo un país). Ya ni siquiera mencionar la habilidad de redactar claramente por escrito alguna idea relevante. Por otro lado, los productos de la técnica parecen avivar una info-adicción por la cual la atención cotidiana no parece estar en discutir temas relevantes en la sociedad sino sólo estar distraídos con los chismes del día a través de dispositivos electrónicos portátiles.

¿Cuánto tiempo tardé en encontrar trabajo después de egresar?

En mi caso, empecé a ejecutar proyectos de desarrollo de software como profesional pagado desde el segundo semestre de la carrera. He sido empleado y también me he desempeñado ofreciendo mis servicios profesionales con mi propia empresa de consultoría. Por fortuna, en general, no me han faltado proyectos de desarrollo de software, aunque en ocasiones tardan en concretarse pues busco ejecutar proyectos con un enfoque distinto al enfoque que tiene saturado al mercado.

¿Cuál es el salario que puede aspirarse?

El salario puede variar mucho pues depende de varios factores como la geografía, el tipo de mercado, el tipo de actividad profesional dentro las diversas áreas de tecnologías de información, el tipo de proyecto y su modelo de negocio, etc. La revista Software Gurú suele publicar estudios de salarios; por ejemplo: Estudio de Salarios 2014.

¿Qué es redactar?

¿Cuán símil o disímil es redactar en un lenguaje natural, e.g., castellano o inglés, que redactar en un lenguaje artificial, e.g., Visual C^# o Go?

Si redactar es la acción de ordenar ideas en nuestra mente con el propósito de ponerlas por escrito, entonces escribir software en un lenguaje de programación también implica redacción. Lo cual de igual forma implica que las habilidades para escribir mejor software están directamente relacionadas con las habilidades para redactar mejor.

Por supuesto, no es exactamente lo mismo redactar un texto narrativo que un texto argumentativo o uno descriptivo. Asimismo, no sería lo mismo redactar un texto expositivo que redactar un texto fuente como expresión de un diseño detallado de software (también conocido como «código fuente») pues cada tipo de texto asume un conjunto de expectativas diferentes por parte de su audiencia. Además, la redacción de software no sólo tiene por audiencia a procesadores basados en carbono (cerebros humanos), sino también a procesadores basados en silicio (cerebros electrónico-digitales).

Crear software es una actividad reciente en la historia de la humanidad con apenas aproximadamente 70 años de recorrido histórico. Un profesional de desarrollo de software requiere reflexionar sobre qué es esta actividad y cuáles tipos de habilidades se requieren para practicarla cada vez mejor. Desde 1968 se ha sugerido que podría ser una disciplina de ingeniería, y sí comparte ciertos atributos con ese grupo de disciplinas. Pero no sólo es eso sino que también comparte rasgos con otras disciplinas tanto puramente intelectuales como performativas –disciplinas que dependen de constantes ensayos para lograr un cierto nivel de calidad en su desempeño, el cual será necesario repetir en cada entrega.

Una disciplina puramente intelectual es, por ejemplo, la formulación matemática que sirve para explicar y predecir fenómenos físicos. Tal formulación se realiza una vez y si el resultado es correcto entonces puede ser utilizada posteriormente múltiples veces sin requerir el mismo tipo de esfuerzo intelectual que fue necesario para la formulación inicial. Por otro lado, el despliegue artístico coreográfico en un escenario requiere ser realizado con el mismo tipo de esfuerzo, cada vez. Crear software no-trivial requiere de una síntesis entre ambos tipos de disciplinas pues un proyecto para crear software no-trivial suele encontrarse en un escenario o contexto con oportunidades nuevas y restricciones distintas en cada ocasión.

Our civilization runs on software

Pruebas unitarias como actividad de diseño

Hace ya como quince años que escribí una librería muy sencilla que llamé AutoTest. La escribí en Visual C# 1.0 y .NET Framework 1.0 por ahí entre 2000 y 2001. Me hizo falta pues en ese tiempo no supe de la existencia de ninguna librería para pruebas unitarias en .NET. Me hizo falta para diseñar software pues desde esa época ya estaba yo «infectado de pruebas». La infección, como a muchos otros diseñadores de software de aquella época, me ocurrió al exponerme a dos experiencias: (1) la lectura del artículo por Kent Beck y Erich Gamma con las palabras «Test infected» en el título, (2) la lectura y participación en las campales discusiones en la lista de distribución por correo electrónico de Object Technology User’s Group (OTUG) hospedada por la ya desaparecida Rational Corp. Discusiones donde personajes como Grady Booch, Kent Beck, Robert C. Martin, Steve Mellor, etc., polemizaban sobre métodos sistemáticos de análisis y diseño, sobre eXtreme Programming en general y Test-first programming en particular (ahora mejor conocida como Test-Driven Development, TDD), y sobre otras escuelas de pensamiento en diseño profesional de software.

AutoTest fue mi herramienta en ese tiempo para escribir pruebas unitarias a priori automatizas en .NET y con ello expresar varios tipos de expectativas de mis diseños. Expectativas que verificaba por demanda de manera ejecutable y automática. A esa técnica luego empecé a llamar: la realización de una «especificación funcional ejecutable».

Antes de AutoTest ya había ocurrido mi infección por escribir pruebas unitarias como un medio para diseñar software; es decir, a priori: no como validación y verificación de algo ya existente (a posteriori) sino como medio para empezar a pensar el diseño de la interfaz pública del software que aún no existe. Tiempo antes mi infección ya me había hecho tomar la versión CppUnit para Visual C++ de Michael Feathers —a su vez inspirada en la versión inicial de JUnit de Erich Gamma y Kent Beck— y adaptarla para el Borland C++Builder 4.0 de aquel 1999.

Con “contagio” o “infección” me refiero a que una vez que entendí y experimenté la técnica de diseñar software por medio de pruebas unitarias, entonces decidí de manera irrevocable que no había vuelta atrás pues me había topado con algo para lograr un siguiente nivel de calidad y profesionalismo en diseño de software. Además, el artículo «Test infected», ya mencionado, se refiere más o menos a esto mismo.

Olvidé que en ese tiempo había publicado una breve nota al respecto de AutoTest. La escribí antes de que existiera Blogger.com y en aquel entonces la publiqué en mi primer espacio en Internet: AutoTest - Unit testing framework.

En un proyecto personal en la actualidad salió el tema de los riesgos de confiar demasiado en herramientas que intentan “hacer todo por ti” y, por supuesto, salió a colación el manuscrito del Profesor Edsger Wybe Dijkstra donde mencionó algo al respecto. No tenía a la mano mi colección base de referencias, así que hice una búsqueda para localizar en Internet dicho manuscrito y en los resultados apareció mi nota de hace casi quince años.

¿Más lenguajes de programación?

Así como se contempla un atractivo y alejado paraje al mismo tiempo que crece un vehemente anhelo de muchas y variadas vivencias en dicho paraje, así quisiera yo entender lo que Ludwig Wittgenstein quiso decir en la proposición 5.6 de su obra «Tractatus logico-philosophicus: Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt (los límites de mi lenguaje significan los límites de mi mundo).»

Quizá la enorme diversidad de formas de expresión humana sea un indicio de lo mucho que los humanos pretendemos expresar. Si es verdad que algunas formas de pensamiento filosófico sólo pueden ser expresadas a cabalidad en determinado lenguaje, entonces quizá eso sugiera algunas diferencias entre un espacio conceptual y un espacio lingüístico. Por ejemplo, la diferencia de amplitud; es decir, hay un número mucho mayor de conceptos en comparación con el número de palabras a la fecha para expresar todos esos conceptos. Otro ejemplo, la diferencia diacrónica; es decir, la precedencia en el tiempo del concepto –que ocurre por primera vez en alguna mente humana– con respecto a la expresión lingüística para dicho concepto –que surge como necesidad de expresar el concepto.

Me pregunto si algo así aplica para el caso de los lenguajes artificiales que aspiran a ser medio para expresar intenciones computacionales.

Quizá un lenguaje artificial usado para adiestrar a una computadora (o el adiestrado resulta ser uno mismo), en general, sería un medio para expresar una forma particular de computación digital en un determinado nivel de abstracción; digamos, no es lo mismo pensar CLR via C# que pensar Windows via C++ (como lo explica Jeffrey Richter), o no es lo mismo la actitud racional hacia el diseño de programas que alude Alexander Stepanov en su «From Mathematics to Generic Programming» que el énfasis visual de Scratch, ofrecido por MIT.

Entonces, por ejemplo, en el caso de Rust o de Go, o de muchos otros lenguajes de programación de computadoras, no veo otra más que conocer e intentar masticar las formas de expresión propias de un lenguaje artificial (o natural) para luego evaluar con cuál puedo expresar diferentes formas de computación. ¡Al parecer la diversión no termina, sino apenas empieza!

Por lo que sí tiene sentido preguntarse: What is code?

Goce profesional

El 23 de diciembre de 2006, hace aprox. nueve años, publiqué la nota que ahora refiero. Esa nota recién llegó a mi memoria después de concluir hoy una intensa sesión de diseño y desarrollo de software. Una sesión por el simple y puro placer de diseñar y escribir código que hace funcionar a una computadora en la precisa pauta que le ordeno.

«It’s only writing code but I like it, ... I like it!!!» … «I like to write code.»

La nota es: You can have joy even if you do not have fun (lasting satisfaction).

Top coder

¿Alguien interesado en aprender a programar computadoras? A continuación refiero una estrategia sólida:

«Go to http://topcoder.com/tc and http://codeforces.com/. Participate in ALL competitions. Dedicate 4…6 hours a day practicing. Come up with a plan, like "10 easy problems per day, three mediums and one hard per week". Solve ALL the problems. Never let them hang. Develop a habit of going to bed with the feeling of accomplishment.

Ask on the forums if you are stuck; make it a habit to practice asking good questions as well.

Read other people's code. Learn from it relentlessly! ...» —Dima-Korolev

Repetición cíclica y aprendizaje

Una de las implicaciones de lo dicho en la nota El progreso de un aprendiz sería la idea de la repetición cíclica y su potencial relación con una idea general de aprendizaje.

¿De qué tipo de repetición cíclica estamos hablando aquí? Claro, no una que sea mecánica e irreflexiva, sino una que implique retroalimentación y la consecuente adaptación para el ciclo sucesivo.

Si por aprender también entendemos cambiar o mejorar en algo, entonces en cada ciclo uno podría identificarse algún delta de cambio o mejora en ese algo, por mínimo que fuese y cualquiera que fuese su signo (pues no toda repetición implica avance). En mi caso, una frecuente dificultad está en identificar ese delta pues suelo permanecer ciego de mi propio desempeño, o tiendo a ver sólo lo que me causa autocomplacencia, o estoy tan cerca de la situación que no alcanzo a ver el panorama y las deficiencias que se hacen aparentes sólo a distancia. Por eso, con la misma frecuencia, necesito la retroalimentación de otros.

Hay muchas corrientes y escuelas de pensamiento para la programación de computadoras, y, por fortuna, hay muchas donde la cooperación tiene un lugar predominante. Es decir, donde el diseño detallado (también conocido como «código fuente») es visto y revisado con frecuencia por más de un solo par de ojos. Por lo tanto, si alguno aquí busca ser practicante –como sigo intentando ser– de alguna de esas corrientes o escuelas cooperativas de programación, entonces podría, si gusta, compartir algún diseño detallado del que quiera retroalimentación. Así, los interesados podremos aprender juntos algo.

¿Alguien se anima?

Estudiar código de otros

La sola idea de aprender a programar no deja de interesarme. Quizá es por lo que solía decir Kristen Nygaard: «To program is to understand.»

Recién recordé años imberbes, y en perspectiva, reconozco la influencia que entonces tuvo tener en mis manos el clásico: Algorithms + Data Structures = Programs, de Niklaus Wirth (la edición Prentice-Hall de pasta dura de febrero del 76). Mirar el código en esas páginas, y sentir la urgencia de intentar esos programas en alguna computadora con el fin de entender lo que ocurría, fue emocionante.

Los básicos de la programación en ese libro siguen, para mí, igual de vigentes. Además, hay otros excelsos libros de introducción a la programación. Por fortuna puede uno acudir a maestros como Bjarne Stroustrup o Bertrand Meyer que, como Niklaus Wirth, son autores generosos. Por fortuna, podemos sopesar sus palabras que dirigen con lucidez a quienes buscamos aprender a programar; un par de ejemplos son las siguientes referencias. Además, reproduzco un párrafo del prefacio del maestro Meyer que al repasarlo me hizo recordar cuán importante es estudiar el código de otros.

Programming — Principles and Practice Using C++, por Bjarne Stroustrup.

TOUCH OF CLASS — Learning to Program Well with Objects and Contracts, por Bertrand Meyer.

«Because from day one of the course you will have the whole power of EiffelStudio at your fingertips, you will be able to skip many of the “baby” exercises that have traditionally been used to learn programming. The approach of this book is based on the observation that to learn a technique or a trade it is best to start by looking at the example of excellent work produced by professionals, and taking advantage of it by (in order) using that work, understanding its internal construction, extending it, improving it — and starting to build your own. This is the time-honored method of apprenticeship, which places newcomers under the guidance of experts.» —Bertrand Meyer

¿Por qué reflexionaría un programador de computadoras?

Jugar con una computadora ha sido para mí una constante fuente de gozo y diversión desde mi etapa adolescente. La idea de controlarla para que aparezca algo en la pantalla o para que haga diferentes cosas al pulsar diferentes teclas ha sido para mí puro pasatiempo. Aún recuerdo mi sorpresa al escuchar que jugar de esa manera podría ser un trabajo remunerado. Estaría dispuesto a pagar por la oportunidad de pasar mi tiempo divirtiéndome al explorar una computadora, cuán interesante ha sido que no he tenido que pagar sino que me pagan por jugar y divertirme al controlar computadoras para que hagan con exactitud lo que yo les dicto (algunas veces lo hacen). Cuánto más afortunado ha sido que hay mucho por leer y aprender sobre cómo controlarlas cada vez mejor. Ejercer control sobre un objeto complejo como una computadora es algo muy divertido para mí. El juego se llama: administrar la complejidad para lograr la ilusión de control y de simplicidad, entre más control y más simplicidad, más diversión.

Un aspecto de especial placer estético para mí ha sido el teclado. Me parece como una especie de clavicordio, el teclado me parece un extraordinario mecanismo sobre el cual puedo poner mis manos para intentar lograr algo artístico. Una computadora de hoy es una muy notable maquinaria.

Programar para mí no es un “trabajo” que me veo en la necesidad de hacer para obtener dinero. Para mí, programar computadoras es un juego y, por tanto, tiene que ser divertido y adecuado para muchas horas de ocio; de otra manera no tendría sentido para mí hacerlo. El “trabajo”, aquello obligado e indeseable, no ofrece espacio para reflexiones ociosas pues el trabajo es lo contrario al tiempo libre de una persona. Programar una computadora para mí es siempre una opción para mi tiempo libre, para mi ocio. Es ahí, en la recreación, donde se busca más gozo y más diversión, ahí cobran sentido las preguntas y la indagación por el conocimiento que ayude a avivar ese deleite. Pues el conocimiento intensifica el goce.

Por otro lado, otra condición para la reflexión es la tragedia. La desdicha puede impelernos preguntas que en otras condiciones no haríamos. Pasar muchas horas diarias haciendo algo de manera obligada e indeseable suena como un infortunio, como una tragedia. Ahí, al padecer el “trabajo”, también tienen sentido las preguntas y la indagación que ayuden a disminuir el tormento.

Regresar a los básicos implica formular preguntas muy básicas. Por ejemplo, ¿a qué nos referimos cuando decimos “programar una computadora electrónico-digital”? ¿En qué consiste hacer eso, aun si sólo queremos lograr algo “práctico”?

Reflexionaré más sobre esa pregunta más adelante. Aquí sólo citaré lo que el autor de The Art of Computer Programming ha escrito en varias publicaciones:

«Science is what we understand well enough to explain to a computer. Art is everything else we do.» —Donald E. Knuth