Si no tienes un nivel avanzado de inglés, no te desanimes

Aunque los lenguajes de programación y su documentación correspondiente se desarrollen en inglés, no es imposible aprender a programar sin saber inglés. Existen numerosos recursos para principiantes en español, algunos de los cuales han sido citados en la Tabla 1 de este artículo. Y aunque es innegable que tener habilidades lingüísticas en inglés (más bien en la lectura, para leer la documentación y los foros; y en la comprensión auditiva, para el aprovechamiento de video-tutoriales) es una ventaja a la hora de programar a nivel profesional, también es cierto que si no se poseen estas habilidades se pueden compensar con el uso de traductores, y que a medida que se avanza en las habilidades de Tabla 1 (comienzo).

Una discusión no inclusiva de los lenguajes de programación. Un shell es una interfaz de línea de comandos (es decir, de programación) de un sistema operativo, como por ejemplo sistemas operativos similares al Unix. Los lenguajes de programación de bajo nivel se ocupan del hardware de un ordenador. El proceso de pasar de las instrucciones literales del procesador hacia aplicaciones legibles para humanos se llama "abstracción". Los lenguajes de bajo nivel requieren poca abstracción. Los lenguajes interpretados son más rápidos de probar (por ejemplo, para la ejecución de algunas líneas de código); esto facilita el aprendizaje a través de la prueba y el error. Los lenguajes interpretados tienden a ser más legibles para el ser humano. Los lenguajes compilados son poderosos, porque a menudo son más eficientes y se pueden utilizar para tareas de bajo nivel. Sin embargo, la distinción entre lenguajes interpretados y compilados no es siempre rígida. Todos los lenguajes que se presentan a continuación son gratuitos, a menos que se indique lo contrario. La página de Wikipedia sobre lenguajes de programación proporciona una gran visión general y una comparación de lenguajes.

Tabla 1 (continuación).

Tabla 1 (final). 

Comenzar con el final en mente

Cuando tengas tu objetivo en mente puedes elegir el lenguaje de programación. ¿Quieres ser programador? ¿Quieres desarrollar herramientas bioinformáticas? ¿Quieres implementar herramientas?

¿Quieres que se analicen ya estos datos? Escoge un enfoque y un lenguaje que se adapte a tus metas a largo y corto plazo. Los lenguajes varían en intención y uso. Cada lenguaje y paquete fue creado para resolver un problema particular, por lo que no hay un lenguaje universal "mejor". Elige la herramienta adecuada para el trabajo seleccionando un lenguaje que se adapte bien a las preguntas biológicas que deseas hacer. Si muchas personas en tu campo usan un lenguaje, es probable que funcione bien para los tipos de problemas que encontrarás. Si la gente en tu campo usa una variedad de lenguajes, tienes opciones. Para evaluar la facilidad de uso, considera cuánto apoyo de la comunidad tiene un lenguaje y la cantidad de recursos generados por la comunidad, tales como la prevalencia del desarrollo del usuario, el soporte de paquetes (documentación y tutoriales) y la "presencia" del lenguaje en las páginas de ayuda. En la práctica, las licencias de los lenguajes varían en costo para uso académico y comercial. Los lenguajes libres son más amigables para el trabajo de código abierto (es decir, compartir tus análisis o paquetes). Ve la Tabla 1 para una breve discusión de varios lenguajes de programación, sus características clave y dónde aprender más.

Los pasos pequeños son pasos

Una vez que hayas comenzado, concéntrate en una tarea a la vez y aplica tu pensamiento crítico y tus habilidades para resolver problemas. Esto requiere desglosar un problema en pasos. El análisis de datos ómicos puede sonar difícil, pero los pasos individuales que componen esta tarea no lo son: por ejemplo, leer los datos, decidir cómo interpretar los valores que faltan, escalar según sea necesario, identificar las condiciones de comparación, dividir para calcular el valor de cambio de expresión de una condición respecto a su referencia (fold change), calcular significancia, corregir para pruebas múltiples. Divide un problema grande en tareas pequeñas e implementa una a la vez. Edita iterativamente para lograr eficiencia, flujo y concisión. Los errores ocurrirán. Eso no es un problema; lo que importa es que los encuentres, los corrijas y aprendas de ellos.

La inmersión es la mejor herramienta de aprendizaje

No armes un análisis “caótico” intercalando entre lenguajes y/o entornos. Mientras aprendes, si un trabajo se puede hacer en un solo lenguaje o entorno, hazlo todo allí. Por ejemplo, la importación de una hoja de cálculo de datos (como la que verías en Excel) no es necesariamente sencilla; Excel determina automáticamente cómo leer el texto, pero el método puede diferir de las convenciones en otros lenguajes de programación. Si el proceso de importación "lee mal" tus datos (por ejemplo, celdas en blanco no se leen en blanco o "NA", los números están entre comillas que indican que se leen como texto, o no se mantienen los nombres de las columnas), puede ser tentador volver a Excel para corregirlos con estrategias de búsqueda y reemplazo. Sin embargo, estos problemas pueden solucionarse leyendo correctamente el archivo y entendiendo las estructuras de datos del lenguaje. Como una lengua hablada (^{Genesee, 1991}, ¹⁹⁹⁴), la inmersión es la mejor herramienta de aprendizaje (^{Campbell & Bolker, 2002}; ^{Guzdial, 2004}). Además de ralentizar la curva de aprendizaje, la transferencia a través de los programas induce al error. Ver referencias (^{Boddy, 2016}; ^{Linke, 2009}; ^{Zeeberg et al., 2004}; ^{Ziemann, Eren, & El-Osta, 2016}) para errores adicionales inducidos por Excel o procesamiento de textos.

Eventualmente, podrás identificar tareas que no se adaptan bien al lenguaje que utiliza. En ese momento, puede ser útil aprender otro lenguaje para utilizar la herramienta adecuada para el trabajo. De hecho, comprender un lenguaje facilitará el aprendizaje de otro. Hasta entonces, sin embargo, concéntrate en la inmersión para aprender.

Llama a un amigo

Existen numerosos recursos en línea: tutoriales, documentación y sitios web destinados a la comunidad para preguntas y respuestas (StackOverflow, StackExchange, Biostars, etc.), pero nada reemplaza a un amigo o la ayuda de un colega. Encuentra una comunidad de programadores, desde usuarios principiantes hasta experimentados, para pedir ayuda. Es posible que desees buscar tanto apoyo técnico (es decir, un grupo centrado en un lenguaje) y apoyo en relación con una aplicación científica en particular (por ejemplo, un grupo centrado en análisis ómicos). Muchas universidades tienen grupos de computación científica, alojados en la biblioteca o en el departamento de tecnología de la información (TI); estos grupos pueden ser tu punto de partida. Si tu laboratorio o universidad no tiene una comunidad de programadores, búscalos virtual o localmente. Los cursos de Coursera, por ejemplo, tienen paneles de comentarios para que los estudiantes respondan a las preguntas de los demás y aprendan de sus compañeros. Organizaciones como Software y Data Carpentry o grupos de usuarios de lenguajes tienen listas de correos para conectar a los miembros. Muchas ciudades tienen eventos organizados por grupos de usuarios de lenguajes específicos o grupos de interés que se centran en los grandes datos (big data), el aprendizaje automático o la visualización de datos. Estos pueden encontrarse a través de meetup.com, grupos de Google, o a través del sitio web de un grupo de usuarios; algunos de ellos se incluyen en la Tabla 1. Una vez que encuentres una comunidad, pide ayuda. En las etapas iniciales, la ayuda en persona para deconstruir o interpretar una respuesta en línea es invaluable. Además, pídele un código a un amigo. Tú no escribirías un trabajo sin antes leer un montón de trabajos o comenzarías un nuevo proyecto sin seguir a unos cuantos experimentadores. Primero, lee sus códigos. Implementa e interpreta, tratando de entender cada línea. Regresa para discutir tus preguntas. Una vez que empieces a escribir, pide que lo editen.

Aprende A Hacer Preguntas

Hay una respuesta para casi cualquier cosa en línea, pero hay que saber qué pedir para obtener ayuda. Para saber qué preguntar, tienes que entender el problema. Comienza por interpretar un mensaje de error. Debes estar atento a los errores genéricos y aprender de ellos. Identifica qué componente del mensaje de error indica cuál es el problema y qué componente indica dónde está el problema (Figura 1 a Figura 4). Comprender el problema es esencial; este proceso se llama "debugging". Sin comprender realmente el problema, cualquier "solución" propagará e incrementará el error, haciendo más difícil la interpretación de los errores en el futuro. Una vez que entiendas el problema, busca respuestas. La búsqueda de respuestas requiere un googleo efectivo. Aprender el vocabulario (y meta- vocabulario) del lenguaje y de sus usuarios. Una vez que entiendas el problema y tengas identificado que no existe una solución obvia (y públicamente disponible), pide respuestas en las comunidades de programación (Tabla 1). Al preguntar, parafrasea el problema fundamental. Incluye mensajes de error e información suficiente para reproducir el problema (incluye paquetes, versiones, datos o datos de muestra, código, etc.). Presenta un breve resumen de lo que se hizo, lo que se pretendía, cómo interpretas el problema, qué medidas de resolución de problemas ya se han tomado, y si has buscado la respuesta en otras publicaciones. Véase el siguiente sitio web para sugerencias: http://codereview.stackexchan- ge.com/help/howto-ask y (^{Collado-Torres, 2017}). Termina con un "gracias" y espera a que llegue la ayuda. Es importante revisar los blogs de las páginas web oficiales de los lenguajes de programación que usamos ya que normalmente hay una sección de discusiones o blogs, y si un paquete utilizado está en un repositorio como por ejemplo GitHub, debemos siempre recurrir al issue tracker del repositorio.

No reinventes la rueda

Usa todos los recursos disponibles, incluyendo tutoriales en línea, ejemplos en la documentación del lenguaje, códigos publicados, fragmentos de códigos interesantes que tu compañero de laboratorio compartió, y, sí, tu propio trabajo. Lee ampliamente para identificar estos recursos. Copiar y pegar(ctrl+x, ctrl+v) es tu amigo.

Figura 1 Anatomía de un mensaje de error, Parte 1 (o: Cómo escribir más de una línea de código). Aquí mostramos un ejemplo del proceso de depuración en R utilizando el entorno RStudio, con el objetivo de concatenar dos palabras. 

Figura 2 Anatomía de un mensaje de error, Parte 2 (o: Sólo porque funcione, no significa que sea correcto). Aquí le ofrecemos más ejemplos del proceso de depuración. Los ejemplos mostrados se llevan a cabo en Python usando un cuaderno Jupyter. Los entornos como RStudio y los cuadernos Jupyter son dos ejemplos de entornos de desarrollo i 

Proporciona integrados; estos entornos ofrecen soporte adicional, incluyendo herramientas de depuración incorporadas. Primero, mostramos un error que no induce un mensaje de error, pero que el usuario debe depurar crédito si es apropiado (por ejemplo, comentario "adaptado de la secuencia de comandos de...") o necesario (por ejemplo, leer los detalles de las licencias del software). Documenta tus secuencias de comandos comentando (usa #) en notas para ti mismo para que puedas usar el código antiguo como plantilla para el trabajo futuro. Estos comentarios te ayudarán a recordar lo que cada línea de código intenta hacer, acelerando tu habilidad para encontrar errores. Los lenguajes incluyen sus métodos de comentar el código que haces, es importante que aprendas esa herramienta antes de que empieces a escribir programas extensos.

Desarrolla buenos hábitos desde el principio

La investigación computacional es investigación, así que utiliza tus mejores prácticas. Esto incluye el mantenimiento de un cuaderno de laboratorio computacional y la documentación de tu código. Un cuaderno de laboratorio computacional es por definición un cuaderno de laboratorio: tu cuaderno de laboratorio incluye protocolos, por lo que tu cuaderno de laboratorio computacional también debe incluir protocolos. Figura 3

Figura 3 Anatomía de un mensaje de error, Parte 3 (o: Rastree el camino hasta el problema). Aquí mostramos un mensaje de error explícito. 

Los protocolos computacionales son secuencias de comandos, y estos deben incluir el código en sí y cómo acceder a todo lo necesario para implementar el código. Debes incluir también la entrada (datos brutos) y la salida (resultados). Las figuras y la interpretación pueden incluirse si así es cómo organizas tu cuaderno de laboratorio. Desarrolla "buenas prácticas digitales" (estrategias para guardar archivos). Es más fácil organizar un cajón que organizar todo un laboratorio, así que comienza tan pronto como empieces a aprender a programar. Si puedes encontrar ese experimento que hiciste el 12 de junio de 2011 -tu protocolo y resultados- en menos de cinco minutos, deberías ser capaz de encontrar esa figura que se generó para la reunión de laboratorio hace tres semanas, completa con código y datos, en menos de cinco minutos también. Esto requiere un buen control de versiones o documentación de tu trabajo. Como con los protocolos, cada vez que ejecutes una secuencia de comandos, debes tener en cuenta cualquier modificación que se realice. Figura 2

Figura 4 Anatomía de un mensaje de error, Parte 4 (o: Depuración de una solución). Por último, mostramos cómo depurar una solución para entender una línea de código que se encuentra en Internet. 

Documenta todos los cambios en los protocolos experimentales y computacionales. Estos hábitos te harán más eficiente al mejorar la reproducibilidad de tu trabajo. Para consejos específicos, véanse ^{Perez-Riverol et al., 2016}; ^{Sandve, Nekrutenko, Taylor, & Hovig, 2013}; ^{Schnell, 2015}.

La práctica hace al maestro

Utiliza conjuntos de datos ficticios para practicar un problema o análisis. Los datos biológicos rápidamente se vuelven grandes. Es difícil de encontrar la aguja en un pajar computacional, así que prepárate para tener éxito practicando en un ambiente controlado con ejemplos más sencillos. Genera pequeños conjuntos de datos ficticios que utilizan la misma estructura que sus datos. Haz que los datos sean lo suficientemente simples como para predecir cómo los números, texto, etc., deberían reaccionar en su análisis. Haz pruebas para asegurarte de que reaccionan como se espera. Esto te ayudará a comprender lo que se está haciendo en cada paso y solucionar los errores, preparándolo para ampliarlo a grandes e impredecibles conjuntos de datos. Utiliza estos conjuntos de datos para probar su enfoque, su implementación, y su interpretación. Los conjuntos de datos ficticios son su control negativo, lo que le permite diferenciar entre los resultados negativos y el fracaso de la simulación.

Sé autodidacta

¿Cómo te enseñarías si fueras otra persona? Te enseñarías con un poco más de paciencia y un poco más de empatía de lo que estás practicando ahora. No estás solo en tu frustración ocasional (Figura 5). El aprendizaje lleva tiempo, así que planifica adecuadamente. Los cursos introductorios son útiles para aprender lo básico porque lo básico es fácil de descuidar en el auto-estudio. Expresa expectativas claras para ti mismo y referencias para el éxito. Aplica parte de la estructura (plazos, tareas, etc.) que proporcionarías a un estudiante para ayudar a motivar y evaluar tu progreso. Si algo no está funcionando, ajústalo; no todos aprenden mejor con un solo enfoque. Explora tutoriales, clases en línea, talleres, libros como Practical Computing for Biologists (^{Haddock & Dunn, 2011}), reuniones de programación local, etc., para encontrar tu enfoque preferido.

Sólo hazlo

Empieza a programar. No puedes editar una página en blanco. Aprender a programar puede ser intimidante. El poder y la libertad que proporciona la realización de tus propios análisis computacionales aportan muchos puntos de decisión, y cada decisión aporta más espacio para los errores.

Figura 5 "¿Cómo salir del editor de vim?" (o: ¡Todos nos quedamos atascados en algún momento!). Véase: http://stackover- flow.com/questions/11828270/how-to-exit-the-vim-editor. 

Además, la evaluación de su trabajo es menos en blanco y negro que en algunos experimentos. Sin embargo, la programación tiene la ventaja de que el fallo está libre de riesgos. No se desperdician recursos, ni dinero, ni tiempo (¡el trabajo de un estudiante es aprender!), ni una reputación científica. En síntesis, el campo de juego es nivelado por el trabajo duro y el esmero. Así que, mientras que la programación puede ser intimidante, el paso más intimidante es empezar.