Aprender a programar, y nos referimos a un lenguaje concreto, sino al oficio, es algo que no viene sin esfuerzo. Muchos programadores cuando empiezan a menudo se enfrentan a los mismos obstáculos. En este artículo analizaremos las principales adversidades a las que se enfrenta un programador intentando dar consejos sobre cómo superarlas.
La idea es prevenir a todos aquellos desarrolladores y programadores noveles sobre algunas de las principales frustraciones de la profesión para que intenten atajarlas lo mejor posible y facilitarles la entrada en este oficio tan apasionante y prometedor.
Las dificultades que citaremos a continuación no son las únicas a las que se enfrenta un programador en formación, pero se podría decir que son las más comunes. Si eres programador y quieres añadir alguna más, te animamos a que lo hagas en la sección de comentarios para completar esta entrada.
1. Estar atascado
Una de las peores cosas que le pasa a todo el mundo cuando empieza en cualquier actividad con algún grado de complejidad es quedarse atascado. Puede que estés intentando instalar algo y no puedes continuar porque el sistema te da un error incomprensible, o quieres añadir una ruta a tu aplicación y la aplicación te da un pantallazo sin más, sin un triste mensaje de error. ¿Qué hacer? No hay un camino claro a seguir.
En primer lugar decir que el hecho de quedarse atascado es el pan de cada día de los programadores - y no solo los principiantes. Hay que aprender a ser un poco indulgentes con nosotros mismos. Hay días en los que parece que no avanzamos, y en los que estar atascado es la norma. Pero en verdad esos periodos de frustración son la base para progresar. No hay aprendizaje sin frustración.
El enfoque que debemos tener es el siguiente: lo más común es no avanzar y cada vez que lo hagamos, tenemos que celebrarlo y sentirnos orgullosos. Si no eres capaz de gestionar la frustración y buscarle un enfoque positivo, quizás nunca serás un buen programador.
Hay muchas formas de intentar salir de un bloqueo de este tipo, hay miles de recursos en la web, foros llenos de comentarios y de situaciones que te pueden ayudar. La forma de salir de un estado de enrocamiento es simplemente solucionar el problema para seguir avanzado. Esto es fácil de decir pero difícil de hacer.
La mejor táctica en estos casos es pensar que la barrera que tenemos enfrente es una grandísima oportunidad para aprender algo nuevo. Para ello tenemos que aprender a desarrollar nuestra paciencia. No es recomendable chocar contra el muro a lo loco intentando solventar el problema mal y pronto.
Lo más aconsejable es coger perspectiva e investigar sobre el problema, familiarizándose con la tecnología en la que estamos. Si entendemos a la perfección la raíz del problema aunque no seamos capaces de arreglarlo a la hora de hacer que el software funcione, ya habremos hecho grandes progresos. Esta forma de gestionar las frustraciones, aprendiendo de cada una de ellas, hará que a la larga avancemos más rápido, evitando obstáculos y atascos programando.
2. La soledad del programador
Otra gran fuente de frustraciones viene de programar de forma solitaria. Cuando empezamos a programar no nos vemos obligados a formar parte de un equipo de desarrollo. Estamos todo el tiempo solos, haciendo algún curso enlatado o leyendo una documentación infumable, y no somos capaces de avanzar. Además, si tenemos un programador senior a mano en la empresa, nos da un poco de reparo interrumpirles ya que no queremos invadir su tiempo de programación y su proceso mental, ya que para muchos de los programadores experimentados estos momentos de máxima concentración son sagrados. Es muy incómodo interrumpir a un compañero cuando está programando.
La experiencia nos muestra que, en general, los programadores son seres solitarios que llevan bien el aislamiento. Quizás es muy aventurado decir que la programación es un deporte en equipo, que no siempre lo es, pero sí podemos afirmar que es una actividad en la que se ven implicadas varias personas, y es de alguna manera un oficio social. Un código no es bueno porque nos gusta solo a nosotros, es bueno cuando un equipo y un jefe de desarrollo o de producto dan su visto bueno. El mejor código siempre nace del consenso.
Hoy en día se utilizan hasta el extremo acrónimos anglosajones para debatir qué hace que un código sea bueno. El principio DRY (no te repitas), o los principios SOLID de la programación orientada a objetos para hacer software robusto, el KISS (el diseño debe ser sencillo), o el SRP (Principio de responsabilidad única) que sostiene que una clase o módulo debe tener una sola razón para cambiar, porque debe tener una sola responsabilidad y el YAGNI (ahorra tiempo y esfuerzo implementando solo lo necesario), etc...
Estos principios surgen cuando los programadores tienen que revisar y dar mantenimiento al código de otros programadores, y empiezan a determinar qué prácticas hacen que un software sea posible y más fácil de mantener y cuales provocan lo contrario. Esta forma de trabajar hace que todos seamos mejores programadores.
En campusMVP siempre hemos sostenido que la mejor forma de aprender a programar es programando (de perogrullo, sí, pero luego no se aplica en mucha de la formación que hay por ahí). En consecuencia, al tener que aprender haciendo, hace que el aprendizaje de la programación sea una actividad social. Necesitas a alguien que te proporcione otras ideas o diferentes enfoques, y también que evalúe la calidad del código que estás programando.
3. Los despistes
Una de las mayores barreras que tenemos que superar en la rutina diaria como programadores son los despistes. La sintaxis de muchos lenguajes de programación puede ser enrevesada y difícil de retener y recordar. O lo que es peor: muy parecida de unos a otros y debes trabajar con varios de ellos. Esto forma parte inherente de la complejidad de la programación: tenemos que ser capaces de acordarnos de miles de pequeños detalles.
Para mitigar el problema podemos ser metódicos a la hora de documentarnos. Es buena idea tener la documentación de lo que estemos usando a mano, para poder acceder a ella a golpe de teclado.
Otra práctica recomendable es ejercitar la memoria por medio de la repetición. Podemos, por ejemplo, escribir en un blog técnico documentando aquellas cosas que nos hayan resultado complicadas, y describiendo cómo las hemos resuelto. Un buen truco es compartirlo con nuestros compañeros para que comenten lo que quieran y nos ayuden a mejorar. Las bitácoras, si somos capaces de mantenerlas en el tiempo, también nos ayudan a ver lo lejos que hemos llegado al echar la vista atrás.
Otra técnica de repetición es decir las cosas en voz alta. La memoria auditiva está infravalorada. Evidentemente no te vas a poner a hablar como un loco en una sala llena de programadores, pero podemos buscar un lugar apropiado y a un compañero dispuesto a comentar un extracto de código complicado.
Por último, otra técnica es que nos busquemos un reto de programación semanal. Perfila retos que te ayuden a mejorar en aquellas cosas en las que sueles fallar programando.
4. No temas a la revisión por pares
La revisión por pares es algo muy común en el mundo de la programación. Lo mejor es acostumbrarse a ello y verlo como una oportunidad de mejora. Es mucho peor no hacer la revisión por pares que hacerla para todas las partes implicadas. No hay que tenerle miedo.
Es una oportunidad de mejora para el programador y es bueno hacerlo a todos los niveles, incluso entre programadores senior. Nunca se sabe cuándo algún compañero puede identificar un algoritmo mejor en relación con la tarea en la que estamos trabajando.
También es bueno para la empresa ya que pueden ver ayudarnos a ajustarnos a los estándares de la empresa y saber si tu trabajo está hecho conforme a los mismos. Quizás tenemos mucha proyección dentro de la empresa y es una forma de identificarlo.
Otro aspecto positivo es que nos obliga a entender el por qué hacemos las cosas. Y si no lo entendemos, nos obliga a hacer preguntas sobre el diseño y el código de las aplicaciones. Lo que no queremos es llegar a las sesiones de revisión y no estar alineados con los estándares de la empresa. Queremos que nuestro código sea consistente con el resto del software que se hace.
5. No internalizar nuestros logros
Muchas veces nos sentimos un fraude, caemos en lo que los psicólogos llaman el síndrome del fraude o síndrome del impostor. Esto nos ocurre a los programadores cuando no somos capaces de reconocer nuestros logros y tememos ser un fraude. Es un tema muy manido que probablemente ya conocemos todos y que sucede en todas las profesiones.
Para evitar caer en este estado de ansiedad es buena idea intentar realzar nuestros logros. Al igual que en punto anterior, usando un blog técnico, podemos claramente ver nuestro progreso si echamos la vista atrás. El crecimiento de un programador novel en un año es tan grande que la mayoría no se da cuenta de cuánto han mejorado hasta que se comparan con su yo del pasado.
Otra forma de destacar los logros es hablar sobre ellos de vez en cuando en reuniones de trabajo. Es lo que se llama hacer retrospectiva cada X tiempo para analizar los aciertos de un proyecto de software, y no solo los errores, ni la pila de cosas que quedan por hacer. Lo lógico es que el 80% de las reuniones sean sobre errores y cosas que queden por hacer. Lo que no es bueno es que el 100% sean así. Tenemos también que abrir espacio para celebrar lo que hemos hecho bien y darnos refuerzo positivo para repetir esas conductas en el futuro y estar auto-motivados por ello.
Cuando somos un programador que está empezando no nos sentimos tan cómodos usando lenguaje técnico como nuestros compañeros. Para mejorar en estos contextos es bueno buscarse situaciones en las que podemos hablar sobre código sin que haya cosas importantes en juego.
Por ejemplo, hablar sobre código a la hora de comer con compañeros, asistiendo a meet-ups, viendo videos en YouTube o escuchando podcasts. Lo normal es que no entiendas todo, pero con el paso del tiempo, irás adquiriendo conceptos y podrás entender más cosas, hacer mejores preguntas para terminar haciendo mejores aportaciones en las reuniones en las que sí hay cosas importantes sobre la mesa.
En muchas empresas tienen la costumbre de traer invitados a reuniones que no son de su competencia. Puede que nos sintamos abrumados y que pensemos que es una pérdida de tiempo, pero en verdad se aprende muchísimo y nos da mucha perspectiva de las cosas del trabajo y de los motivos de las decisiones que nos afectan en el día a día. Si en tu empresa no lo hacen, no temas en pedir que te inviten a una de vez en cuando, a tu superior no le va a parecer mal que muestres entusiasmo e interés por la empresa.
6. Programar es resolver problemas
Tenemos que saber que esta profesión implica resolver problemas. No hay otra forma de concebirla. Es muy habitual que programando nos encontremos siempre en dos fases: avance-muro. Todo va bien, avanzamos, y de repente nos encontramos un muro infranqueable y estamos ahí parados. Sorteas el muro tras solucionar el problema, avanzas otro poco, y de la nada, otro muro...
No es descabellado afirmar que en cualquier tarea que implique escribir código siempre vamos a tener que solucionar algún problema inesperado que nos encontraremos por el camino. La programación es así, es pegarse de frente contra muros.
La mayoría de las barreras las podemos pasar preguntando a algún compañero o usando Internet o trasteando algo con el código. En no pocas ocasiones no somos capaces de saber cómo avanzar. Los mensajes de error muchas veces son indescifrables o simplemente no hay mensaje de error, y las búsquedas en Internet nos llevan a callejones sin salida.
En estos casos un posible enfoque es entrar en profundidad a evaluar el problema. Aquí tenemos que parar en seco y empezar a reflexionar más profundamente. Para empezar, debemos cuestionar nuestras presunciones con preguntas del tipo:
- ¿Qué cosa no funciona?
- ¿Por qué he pensado que iba a funcionar?
- ¿Qué cosas he dado por supuesto que iban a funcionar pero no he verificado?
Es en estos momentos en los que tener una buena base de conocimiento de nuestro trabajo marca la diferencia frente a aquellos que han aprendido solo "recetas" o son "programadores de Stack-Overflow" (de copia-pega: ¡hay muchos!). Este tipo de preguntas nos obligan a meternos de lleno en el problema en cuestión, centrarnos en él, en vez de saltar de una posible solución a otra. Nos obligan a pensar mucho en el código que tenemos entre manos y revisar todo de arriba abajo.
Otra posible ayuda a la hora de solucionar problemas es leer la documentación a fondo. No es la forma más popular de resolver un problema, pero nos aporta más contexto y, a fin de cuentas, es otra forma de aprender más. Es el camino más largo, pero en la etapa de programador junior nunca se puede considerar una pérdida de tiempo leer documentación.
Es bueno tomarse un tiempo para aprender más sobre el lenguaje de programación o el framework. Por otro lado, al leer la documentación podemos discriminar mucha información que hemos memorizado ya que sabemos dónde encontrarla y la tenemos perfectamente localizada.
Llegados a este punto, y con el nuevo conocimiento adquirido, podemos volver a crear el código de forma distinta e ir viendo cómo se comporta la aplicación paso a paso. Aunque no logremos que funcione, si conseguimos que nos devuelva un mensaje de error descifrable, ya hemos dado muchos pasos hacia adelante.
Otro posible enfoque es buscar la solución en Internet. Ir a Google y ponerse a investigar cada uno de los hilos y los blogs que hacen alguna mención al problema que tenemos.
A veces esta forma de enfocar el problema nos funciona bien, pero otras nos pasamos media mañana investigando para no avanzar nada. Probar diferentes estrategias una tras otra esperando a que alguna nos funcione nos puede dar varios dolores de cabeza y no es una forma de aprender en profundidad el framework o el lenguaje de programación. Es como jugar a los dados hasta que salga la combinación de números que queremos. Algo siempre se aprende, pero no nos da todo el contexto del problema, y tras todo el tiempo invertido investigando y haciendo ensayo y error, quizás sea mejor invertir un poco más y aprender más a fondo.
7. Diferenciar entre buenas prácticas y estilos de programación
Como desarrolladores junior nos falta experiencia para saber si nuestros mentores nos están enseñando buenas prácticas o si nos están imprimiendo su estilo de programación. Si sospechamos que lo que nos están enseñando es más bien su forma de hacer las cosas que buenas prácticas, quizás resulte un poco violento plantearlo, especialmente si tu mentor es un desarrollador senior de la empresa en la que trabajas. Puede resultar muy complicado salir de estas dudas sin caer en la confrontación.
Muchas veces estamos en pleno proceso de aprendizaje y nos enseñan cómo se hacen las cosas en la empresa. Pueden ser buenas prácticas o no... De todos modos lo mejor es que en líneas generales confiemos en que saben lo que están haciendo. Habiendo dicho esto, como novatos muchas veces nos corresponde dar por hecho que nuestros compañeros más veteranos son algo obstinados, siempre pensarán en primer lugar que la persona que está equivocada eres tú, y que prefieren ceñirse a su forma de hacer las cosas antes que cambiar. Algunos incluso se desenvuelven con aires de superioridad.
Sea cual sea la situación, siempre tendremos que asumir el hecho de que los mandos técnicos de la empresa tienen su forma de hacer las cosas, y tenemos que vivir con ello.
Si detectamos que algo se puede hacer mejor (de verdad, con razón), lo mejor es sacar el tema sin entrar en una confrontación directa. Siempre podemos preguntar con educación por qué se hace algo de una manera determinada, para luego añadir, si vemos algún tipo de apertura por la otra parte, la forma en la que creemos que se podría hacer, justificando bien el porqué. Siempre nos vamos a encontrar con personas que nunca van a transigir y que se consideran infalibles, pero salvo contadas excepciones, incluso los programadores senior quieren aprender nuevas formas de hacer si se basan en argumentaciones sólidas.
Conclusión
En general, sentimos frustración cuando nos quedamos atascados en algo. Esa frustración se puede mitigar si encontramos un apaño para seguir, pero también si aprovechamos las adversidades para aprender, que también nos proporciona una sensación de progresar.
Por si no te habías dado cuenta, este es el blog de campusMVP, la mejor forma de aprender a programar.
Nuestra metodología hace que te encuentres adversidades muy concretas por el camino. Si haces alguno de nuestros cursos de programación, a partir de lo explicado y de las prácticas especialmente diseñadas, te surgirán dudas que tendrás que preguntar, te tendrás que pegar con ellas. Y esto es otra forma más de aprendizaje, pues nos obligará a reflexionar y concretar los detalles de la tecnología.
Con campusMVP, para que no nos quedemos atascados existe la figura del tutor, que normalmente es la persona que ha diseñado el curso. El tutor contestará las dudas al mismo tiempo que seguimos practicando y/o estudiando en paralelo. Obtener respuestas rápidas y precisas por parte de los tutores que asisten tu formación es muy importante. No sirve que te contesten cuatro días más tarde.
¡Anímate con uno de nuestros cursos y cuéntanos que tal te ha ido!
Fecha de publicación: