Programar tal vez no es lo que tu crees que es

El año pasado, una docena de amigos quisieron saber mi opinión sobre si sería útil para ellos aprender a programar. La impresión que tenían todos ellos es que este tipo de habilidades están en gran demanda en el mercado laboral, particularmente para trabajos en ciencia de datos, y que aprenderlas les ayudaría a encontrar más y mejores oportunidades. Sin embargo, la abundancia excesiva de libros, cursos en línea y videos sobre este tema distraen la atención y hacen difícil determinar por dónde empezar. “¿Cuáles son los buenos cursos?”, “¿Qué lenguaje aprender?”, “¿Cuánto tiempo tomaría?” Y, lo que es más importante, “¿valdría la pena?”

Para responder a estas preguntas, me parece útil distinguir dos actividades que están relacionadas pero no son lo mismo: codificación y programación. Codificación es la traducción correcta de “coding”, sin embargo en español se suele usar exclusivamente la palabra “programación” en todos los contextos. En inglés, ambas palabras suelen usarse indistintamente, pero ignorar la distinción entre ellas puede causar confusión y generar expectativas equivocadas. Mi impresión es que muchos de esos nuevos trabajos, que han surgido tras la revolución de la ciencia de datos y el “machine learning”, están buscando personas con habilidades de programación, no solo de codificación. Eso no significa que aprender a codificar no sea útil e incluso muy satisfactorio.

La codificación y la programación están asociadas con el proceso de hacer que una máquina haga algo por uno. En este contexto específico, la “máquina” es una computadora, y la forma de “hacer que haga algo por uno” es a través de un programa informático. Es importante aclarar ese punto porque si uno se apega a la definición estricta, se podría decir que uno “programa” su alarma para despertar por la mañana, pero no es de eso de lo que estamos hablando aquí. El énfasis de la codificación está en la parte del “código”, que se refiere a un conjunto específico de instrucciones que se escribe en un lenguaje de computadora. El énfasis de la programación está en encontrar la solución a un problema utilizando una máquina.

De una u otra forma, la codificación y la programación tienen en común cuatro etapas interrelacionadas: el diseño de la solución; escribir código de computadora; depuración y documentando de código. Una visión muy estrecha de la codificación argumentaría que esta se refiere exclusivamente a la segunda etapa. Yo lo veo de manera diferente, más como una versión simplificada, algo asi como programación para el aficionado. Pero antes de subrayar a las diferencias, permítanme describir brevemente estas cuatro etapas.

  • Diseñar la solución a un problema implica descomponerlo en una serie de pequeños problemas que pueden resolverse ejecutando una serie de pasos mecánicos, es decir, encontrar una solución algorítmica. Siempre que estoy pensando en cómo abordar el problema, evito sentarme frente a la computadora y prefiero tomar un cuaderno donde dibujo diagramas y escribo las diferentes operaciones y cálculos que la computadora deberá realizar. Para mí, esta es la mejor etapa en todo el proceso, y en mi mundo ideal, me gustaría dedicar el 99% del tiempo a pensar en el problema y el 1% a las tres etapas que siguen.
  • Escribir el código es simplemente juntar los comandos en un lenguaje de computadora. Puede requerir entre una docena de líneas de comandos o miles de ellas, y en las que se utilizan diversos procedimientos para acceder a la memoria, recuperar y crear datos, o ejecutar instrucciones para controlar la computadora. Los recién llegados pueden pensar que la programación tiene que ver con escribir códigos, cosa que ciertamente suena un poco aburrido, sin darse cuenta de que hay etapas más agradables, como la anterior, o más estresante, como la siguiente.
  • La depuración (en inglés “debugging”), es decir, buscar errores en el código, es una experiencia horrible que se come parte del alma y puede llevarlo a uno a los límites de la locura. Es sorprende cuánto tiempo puede pasar uno en esta etapa, y lo peor es que no sabe a priori cuánto tiempo tomará: Desde el momento en que se ejecuta el programa por primera vez, hasta el momento en que declara que está libre de errores, se puede tomar desde un segundo hasta varios meses.
  • Finalmente, documentar se refiere a describir lo que hace el código y cómo usarlo. Va desde algunas líneas comentadas en el código hasta manuales completos de operación. Igual que el uso de hilo dental, esto no es algo emocionante de hacer pero no es opcional, y hay consecuencias feas si uno no lo hace.

Una buena manera de pensar la diferencia entre codificación y programación es preguntando quién va a ser el usuario: ¿es uno o alguien más? Cuando uno codifica, el usuario es la misma persona que escribe el programa; cuando uno programa, el usuario es alguien más. Por ejemplo, si estás escribiendo un código que te está ayudando a automatizar o acelerar un proceso que necesita en la casa o en la oficina, y no estás planeando que alguien más lo use, entonces estamos hablando de codificación. Por otro lado, si escribes un software que será utilizado por tu equipo, o por usuarios externos, entonces eso es programación.

Esta forma de ver ambas actividades saca a la superficie las muchas consideraciones que se necesita para la una pero no para la otra, y se vuelven más claras al evaluar lo que implica en las cuatro etapas que describí anteriormente.

  • Al codificar, uno busca una solución rápida para un problema y uno queda satisfecho cuando esta soluciona el caso especifico que a uno le interesa. Al programar, se debe pensar en una solución más general que pueda manejar todo tipo de casos y escenarios. Velocidad, memoria, compatibilidad, todo esto se vuelve bastante relevante. Cuando programas, no solo necesitas resolver el problema, también debes hacerlo de la mejor manera posible.
  • La elección de un lenguaje de programación al codificar, principalmente cuando eres un principiante, no debe ser una cuestión de pensar demasiado. Cualquiera de los sospechosos des siempre (Python, R, Ruby, Java, C, Matlab, Perl, …) funcionará bien. Es cierto que algunos lenguajes son más apropiados para resolver algunos tipos de problemas que otros, pero la realidad es que a este nivel no hay mucho daño en adherirse a la antigua Ley del Instrumento (“si todo lo que tienes es un martillo, todo lucirá como un clavo “). Sin embargo, todo se vuelve más complicado al programar, ya que necesitas tener en cuenta muchas consideraciones: sostenibilidad, velocidad de desarrollo, interconectividad con otras herramientas, experiencia, costos, etc. Lo más probable es que no haya un lenguaje perfecto y que termines usando una plataforma en la que combines varios.
  • El guión para la depuración cuando se codifica es el siguiente: ejecuta el código; si falla, busca el error y arréglalo; vuele al primer paso. Si te sientes como si estuvieras jugando un insoportable y doloroso juego de “Whack-a-Mole” entonces probablemente lo estés haciendo bien. Hay algunas maneras de hacer que el proceso sea un poco más manejable, pero honestamente, no hay nada mejor que eso. Cuando estás programando, el enfoque tiene que ser sistemático, probando en paralelo todo tipo de escenarios, entendiendo cómo los maneja el programa, y mejorándolo paso a paso. Buenas prácticas incluyen ejecutar periódicamente una batería de pruebas y mantener una lista detallada de los errores y las funciones que aún no se han resuelto.
  • Cuando se codifica, documentar significa agregar algunas líneas aquí y allá en caso de que necesite volver a revisar el código en el futuro. No creo que sea una cuestión para obsesionarse, tal vez basta con añadir una descripción de lo que está haciendo el código y una nota sobre los pasos críticos. Por otra parte, al programar no puedes esperar a que las musas te inspiren a escribir la documentación y, al igual que en las etapas anteriores, esto debe abordarse de  una manera metódica y con los otros programadores y usuarios en mente. Como regla general, no importa cuánto hayas documentado tu código, todavía estará incompleto.

Aprender a codificar puede ser tremendamente divertido, y si trabajas en un entorno de oficina, siempre será una habilidad increíblemente poderosa para tener en tus manos. Desafortunadamente, Excel se ha convertido en la navaja suiza del mundo corporativo, difundiendo la creencia de que las hojas de cálculo son la única forma en la que los no iniciados pueden usar una computadora. Pero eso podría jugar a tu favor si decides aprender a codificar, ya que podrás hacer tareas que están fuera de alcance de las que pueden hacer tus colegas. Ten en cuenta que todo el material de mercadeo educativo, que te promete que vas a aprender a programar en solo 48 horas, debe entenderse más como la promesa de que aprenderás los conceptos básicos de la codificación, e incluso entonces necesitarás dedicar mucho más tiempo resolviendo problemas reales para afinar esa habilidad

Aprender a programar es algo que probablemente toma miles de horas, cientos de miles de líneas y muchos años. Necesitarás aprender más de un lenguaje de programación, y recomendaría que al menos uno de ellos sea un programa compilado de bajo nivel como C, que te permitan comprender mejor cómo funcionan las computadoras. Una buena manera de sumergirse en la experiencia de programación es contribuyendo activamente en cualquiera de los miles de proyectos de código abierto que puedes encontrar en GitHub, obligándote a adoptar muchas de las prácticas del oficio.

Programar es más una carrera que una habilidad, y está bien si decides que no necesitas ir por ese camino. La codificación pueder ser un maravilloso pasatiempo para cultivar, un arma afilada para tener en un entorno de trabajo de oficina y una hermosa manera de apreciar más el mundo digital donde vivimos hoy en día.

2 thoughts on “Programar tal vez no es lo que tu crees que es”

  1. En las empresas grandes de desarrollo de software muchas veces se usa un esquema estratificado, en el que un grupo de personas (Analistas de negocio o ingenieros de requerimientos) se encarga del contacto con el cliente para el levantamiento de requerimientos; otro grupo de arquitectos o diseñadores de software se encarga del diseño de la solución; un tercer grupo de desarrolladores se encarga de traducir ése diseño en código fuente; y un cuarto grupo se encarga de las pruebas.
    Pero bajando un nivel en la estratificación, algunas veces el tercer grupo se subdivide en dos, que en la empresa para que trabajaba se denominaban “Analistas Desarrolladores” (Los encargados de traducir el diseño en un conjunto de especificaciones condicionales muy básicas, a nivel de función; algo como “Esta función, con una entrada de las variables a y b, debe retornar una variable c, que cumple con estas condiciones); y los “Desarrolladores” propiamente dichos (Encargados de traducir esa especificación en una secuencia de líneas de código que cumpla con las condiciones establecidas por los anteriores).
    Bajo mi concepto, siempre he pensado que si bien todas estas personas, en conjunto, se dedica a “programar”; la tarea de éstos desarrolladores es simplemente la de “codificar”; no necesariamente porque hagan algo para sí mismos ni porque el código que produzcan no tenga en cuenta consideraciones de calidad como desempeño, velocidad de respuesta, etc.; sino porque aunque pueden desarrollar para otros, todas esas consideraciones de calidad, e incluso de cómo se debe abordar el problema a nivel funcional, ya han sido tomadas por ellos, y lo único que les resta a ellos es traducir esas decisiones en código ejecutable.
    ¿Qué piensas?

    Like

    1. Cuando estaba preparando el material de esta entrada vi que mucho de la distinción entre coding y programming era precisamente entre analistas desarrolladores y desarrolladores. Tal vez ahi es mas natural hacer la distincion. Yo lo que quise fue extender esa distincion fuera del ambiente puro de desarrollo de software en algo mas general. Lo que me movio fue esta ola de “aprendamos todos a programar” que se siente por estos dias, y que creo que coge a mas de un incauto.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s