Introducción
Aprender a programar, no me refiero a un lenguaje de programación en concreto, sino al arte como tal, es algo que no viene sin esfuerzo. Muchos desarrolladores de software cuando empiezan a menudo se enfrentan a los mismo obstáculos.
En este artículo, quiero hablar sobre algunos de ellos, se que existen muchos más, y que varían de acuerdo a la persona, pero me enfocare en los más comunes.
Sin esfuerzo, no hay aprendizaje, pero el esfuerzo no es gratuito - César Coll.
1. Estar atascado
Uno de los obstáculos con el cual se enfrenta todo el mundo cuando empieza en cualquier actividad con algún grado de complejidad es quedarse atascado. Puede que estés intentando aprender un nuevo lenguaje, librería, o framework y no puedas continuar porque no entiendes los términos, la documentación, o quizás ya estés desarrollando algún software y al momento de compilar te de un error o peor aun que no te muestre ninguno y solo se cuelgue.
Lo primero que debemos hacer ante una situación así es gestionar esa frustración y darle un enfoque positivo, de lo contrario nos quedaremos cada vez más atascados.
Existen muchas maneras de intentar salir de un bloqueo de este tipo; Por ejemplo en la web hay miles de recursos, foros llenos de comentarios y de situaciones que nos pueden ayudar. esto sonará muy fácil decirlo, pero difícil de hacer, es solucionar el problema para seguir avanzando.
En otras palabras es ver con otros ojos el problema como una grande y maravillosa oportunidad para aprender algo nuevo.
2. Soledad del programador
Cuando empezamos a desarrollar, no nos vemos obligados a formar parte de un equipo de desarrollo. Estamos todo el tiempo solos, haciendo algún curso o leyendo una documentación que a la final no entendemos, cayendo nuevamente el punto número 1.
Hablaré un poco sobre mi experiencia dentro de la compañía para la cual trabajo actualmente, en la cual contamos con un líder de equipo que posee un amplio conocimiento, el cual nos ofrece su acompañamiento durante cada proceso que realizamos, a pesar de ello siento mucha pena molestarle o interrumpirle ya que siento que invado tiempo de desarrollo y proceso mental, dado qué para muchos desarrolladores experimentados estos momentos de máxima concentración son sagrados. Es muy incomodo interrumpir a un compañero cuando está programando.
Puedo afirmar que el desarrollo de software es una actividad donde involucra 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 líder de desarrollo o de producto dan su visto bueno. El mejor código siempre nace del consenso.
3. Los despistes
Una de las mayores barrera que tenemos que aprender a superar en la rutina diaria como desarrolladores son los despistes. La sintaxis de muchos lenguajes de programación puede ser enrevesada y difícil de retener o 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.
Una práctica recomendable es ejercitar la memoria por medio de la repetición, cada vez que repetimos una acción, estamos creando memoria muscular; Por ejemplo dentro de la compañía, desde el líder y jefe de desarrollo, y cada uno de los miembros del equipo hacemos uso de Stack OverFlow, Los Junior entre otras, para documentar todas aquellas cosas que nos hayan resultado complicadas, y describiendo cómo las hemos resuelto. También lo que hacemos es que compartimos con nuestros compañeros para que comenten lo que quieran y nos ayuden a mejorar.
Puedes escribir pequeños documentos, notas, preguntas o artículos, si diste con la solución a algún problema, con esto no solo logras mejorar y ayudar a otros, sino que con el tiempo te servirán para ver lo lejos que has llegado al echar la vista atrás.
Otra técnica de repetición es decir las cosas en voz altas. La memoria auditiva está infravalorada. por ejemplo, un amigo y compañero de trabajo Santiago Guerrero, varias veces he tenido la oportunidad de observarlo trabajar, y utiliza mucho esta técnica, Evidentemente no habla como loco en plena oficina o algo por el estilo, pero aveces tiene problemas en alguna parte del código o implementación de algún feature y no encuentra la solución y empieza a hablarme referente al problema que tiene, y cuando menos piensa pummmm, lo citó - "ah bro, creo que puedo hacer esto, o resolverlo de esta manera", y así termina hallando la solución al problema.
Los invito a leer también su artículo, muy interesante en el cual nos enseña su perspectiva personal sobre cómo iniciar y avanzar en el camino del desarrollo de software.
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 fortalecen nuestra capacidad para ajustarnos a los estándares 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 desarrolladores de software 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.
Me sucede muy a menudo, a veces caigo en estado de ansiedad por creer que no avanzo o que no estoy logrando nada; He tenido la oportunidad de compartir estas experiencias con varios miembros del equipo, pero sobre todo con Santiago Guerrero, el cual me ha aconsejado que intente realzar los logros, no necesariamente tienen que ser grandes para celebrarlos.
cada cierto tiempo o cuando tenemos la oportunidad de sentarnos a charlar, hacemos algo que se llama retrospectiva de algunos meses atrás, para analizar los aciertos del proyecto, del trabajo y no solo errores ni las miles de cosas que quedan por hacer.
Con esto quiero decir que tenemos o debemos 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 meetups, 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 aportes en las reuniones en las que sí hay cosas importantes sobre la mesa.
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 - error. Todo va bien, avanzamos, y de repente nos encontramos un muro infranqueable y estamos ahí parados. logras solucionar el problema, continuas, y de la nada, otro error...
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 profundamente. Para ello 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.
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.
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.
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.
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.
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.