Afrontémoslo: no queremos ser programadores mediocres. ¡Queremos ser
programadores [geniales,increíbles,superlativos]! Queremos
ser los programadores a los que llaman cada vez que están en un aprieto,
y queremos ser los programadores que se sumergen en bases de código
desconocidas y producen código perfecto en cuestión de minutos. Código
que estaría en el Louvre como una obra de arte, estudiado por
generaciones de programadores por su belleza intrínseca y funcionalidad
excepcional.
¿Por qué íbamos a querer ser programadores mediocres? ¿No es mediocre lo opuesto a genial? ¿No deberíamos esforzarnos por ser grandes programadores?
Por supuesto, deberíamos esforzarnos por ser grandes programadores a largo plazo, pero para llegar a ser grandes programadores primero debemos pasar por la etapa de ser programadores mediocres.
Los programadores mediocres saben que no son (todavía) grandes programadores. Los programadores mediocres ven la distancia entre donde se encuentran actualmente y la grandeza que quieren en sus trabajos de programador. Son conscientes del trabajo que implica ser un gran programador y creen que si hacen el trabajo también llegarán a ser grandes programadores.
Pero también ven sus propias faltas y carencias. Ven el historial de su navegador lleno de búsquedas en internet de sintaxis y conceptos básicos. Ven sus archivos de correo electrónico de preguntas que han hecho a otros programadores. Se estremecen ante su código de hace varios meses y se preguntan si alguna vez llegarán a ser grandes programadores con todos estos errores y traspiés. Ven la brecha entre ellos y los grandes programadores, y se siente como si la brecha se ensanchara a cada paso del camino.
Los programadores mediocres se preguntan si vale la pena. Se preguntan si deberían hacer algo más con sus vidas además de programar computadoras. Tal vez no sean tan buenos como creían, o tal vez les falte ese talento especial que tienen los grandes programadores. Tal vez sientan que aprendieron cosas equivocadas al principio de sus viajes, o tal vez piensen que deberían haber comenzado antes.
Ven que otras personas que tienen un gran éxito como programadores y se preguntan si estuvieron ausentes el día en que se entregaron los grandes genes programadores.
La verdad es que todos somos programadores mediocres de alguna forma. Seguimos realizando preguntas y teniendo que echar un vistazo a sintaxis y conceptos en nuestro día a día cuando programamos. Las computadoras continúan evolucionando y los programadores continúan añadiendo complejidad cada día a las tareas de programación. Conlleva mucho ancho de banda mental mantener todos esos conceptos frescos en nuestra mente.
Este libro trata de ayudarte en tu viaje como programador mediocre. Juntos descubriremos algunos conceptos erróneos comunes que tenemos sobre la programación, el fracaso y el crecimiento. Entenderemos que el acto de programar y desarrollar es algo que hacemos todos los días. Todos los días podemos mejorar en pequeñas cosas. Son estos pequeños cambios los que nos transforman de programadores mediocres en mejores programadores.
Hay muchos libros sobre cómo convertirse en un mejor programador. Tienden a tener listas de verificación y otros consejos que el autor considera lo suficientemente importantes como para que los hagas a fin de convertirte en un mejor programador. Suelen centrarse en mejoras específicas, como por ejemplo elegir el mejor editor, escribir mejores casos de prueba o beber mucha agua. Esos libros tienen muchos consejos útiles, pero se leen como una lista de cosas que debes hacer todas a la vez para tener éxito. Este libro intentará no cargarte con más trabajo (probablemente ya tengas suficiente). Más bien, discutiremos lo que se siente siendo un programador. Hablaremos de las emociones que aparecen mientras programamos, los sentimientos de frustración, culpa, ira e insuficiencia. Trataremos de las dificultades para aprender cosas nuevas y mantener tus habilidades actualizadas. Hablaremos de esos momentos en los que tienes ganas de darte por vencido y alejarte de la informática y si esos sentimientos provienen de un lugar de amor o de una preocupación por no está al día.
Este libro es un viaje personal para ambos. Es una memoria de mi tiempo como programador y mis sentimientos a lo largo del camino. He pensado muchas veces en rendirme y encontrar una carrera diferente, pero hacer otra cosa que no sea programador de computadoras me asusta aún más. ¿Significa eso que estoy atrapado en un uróboro (N. del traductor: un símbolo que muestra a un animal con forma de serpiente que engulle su propia cola y que forma un círculo con su cuerpo. El uróboro simboliza el ciclo eterno de las cosas) perverso de autocompasión y dudas? Difícilmente. Significa que necesito profundizar más para comprender por qué elegí el camino de ser programador y darme cuenta de que me costó mucho llegar aquí y que me llevará mucho más llegar a donde quiero estar. Es un compromiso de ver las cosas como son ahora y seguir adelante desde donde estoy parado.
No soy doctor ni terapeuta. No tengo cualificación para darte un consejo médico. Soy programador. Toda la información de este libro está dada desde la perspectiva de un programador con dificultades y no debe tomarse como un consejo médico. Si necesitas ayuda de un profesional médico, por favor busca a una persona que pueda ayudarte. (Hay un capítulo entero sobre buscar ayuda de otras personas casi al final de este libro).
Comencemos nuestro viaje averiguando dónde estamos y recordando qué nos llevó a este lugar.
No recuerdo cómo conocí el texto de Craig Maloney, quizás dí con él porque le sigo en Mastodon y desde ahí conocí su proyecto. Cuando lo conocí, antes de leerlo, quizás pensé que sería un montón de recursos y consejos técnicos para las nuevas personas que llegaran a esto de la programación, pero me resultó curioso el título.
Después de leerlo, me dí cuenta que no. Que no se hablaba de nada técnico sobre programación, que lo que aquí se cuenta tiene que ver más con el aspecto psicológico y mental en lo referente a la programación que con aspectos técnicos.
Yo, sin ser programador, encontré en el libro algunos consejos y trucos interesantes para aplicar en mi día a día en algunos aspectos de mi faceta digital (mi blog, traducciones, colaboraciones, etc).
Y como siempre, de ese interés personal nació esta traducción que hoy tienes delante, después de pedir el correspondiente permiso al autor original. Me gustó lo que se contaba y la traducción “me obligaba” a tener que leer el texto y comprenderlo para realizarla y poder compartirla con todo el mundo.
Si tu trabajo tiene que ver de alguna manera con la programación y en algún momento te has sentido una persona perdida, frustrada o fuera de lugar, este texto te ayudará a saber que es algo común y el autor compartirá contigo sus visiones de su propio viaje en el mundo de la programación y cómo consiguió ir pasando etapas en ese viaje. Tu tendrás tu propio camino en el viaje de la programación, pero tomar como referencia lo que otras personas han sentido quizás te sirva como ayuda en los momentos bajos del camino, espero que sea así.
Pero si no eres programador, también es un texto interesante, este es un relato en el que el autor revela sus puntos flacos, y comparte algunos de los recursos que le han ayudado a conseguir sus metas. Quizás tu puedas aplicarlas a tu día a día en otras facetas, a mí me han servido.
La traducción la he realizado en un repositorio git hospedado en Codeberg donde tienes disponible todos los capítulos y el código original que utiliza el autor para generar su página web.
Si este u otro contenido que creo te resulta interesante, siempre puedes agradecérmelo mediante una donación en Liberapay. Pero tanto si donas como si no, todo el contenido que creo estará libre para que lo disfrutes.
Tienes tu propia historia única de cómo has llegado hasta aquí como programador. Es posible que te hayas enterado de qué era eso de la programación cuando eras un niño curioso que quería ver lo que un ordenador podía hacer. O quizás es posible que hayas llegado como un adulto que escuchó sobre estas cosas llamadas computadoras que puedes programar. Sea cual sea tu caso, has tenido un viaje para llegar hasta este punto y aprendiste una cierta cantidad de cosas para llegar hasta aquí. Pasaste tu tiempo libre aprendiendo a escribir código, o tuviste la suerte de poder trabajar en la programación como parte de tu trabajo. Fuiste a la escuela para aprender más sobre programación o quizás tomaste clases de extras. Compraste libros o leíste artículos en Internet para aprender más sobre programación. Cualquiera que sea el camino que hayas tomado, iniciaste tu viaje como programador.
Y ahora te sientes estancado.
Miras a tu alrededor y te preguntas si alguna vez sabrás todo lo que deberías saber. Lees un artículo en un sitio y se despierta tu interés. Un amigo en Internet menciona esta cosa genial que ha encontrado y espera que aprendas más al respecto. Tu colega encontró algo que podría resolver un problema que tiene en un proyecto y ahora tienes algo más que aprender.
Casi todas las semanas surgen nuevos temas y tecnologías. Estas “cosas” se van introduciendo en nuestras discusiones de programación y en nuestro trabajo. Quizás encuentres estas cosas nuevas que aparecen en anuncios de trabajo que requieren un mínimo de más de 3 años de experiencia, y te preguntas cómo alguien podría tener ese nivel de experiencia. Tal vez elegiste ignorar estas cosas durante un tiempo y ahora se han convertido en un factor determinante en tu trabajo. Es como si alguien cambiara un simple bit de estado 0 a 1 y ahora ya no eres digno de ser llamado programador a menos que hubieras sido uno de los primeros en adoptar estas cosas.
Cada una de estas experiencias te hace sentir como si estuvieras incompleto sin aprender estas cosas nuevas. Nos muestran que no importa cuál sea nuestra experiencia actual, todavía hay lagunas en nuestro conocimiento que deben ser llenadas. Cuando miras hacia el horizonte, puedes ver las brechas que surgen entre el lugar donde estás y el lugar donde crees que deberías estar.
Elegí la palabra “brecha” (Nota del traductor: en inglés usa la palabra “gap” que tiene distintos significados como brecha o hueco) para describir la diferencia entre dónde estás ahora y dónde crees que deberías estar por una buena razón. Una brecha es algo impuesto por otros, ya sea por la fuerza o por negligencia. Si aparece un agujero en la cerca de tu jardín, significa que la cerca es más débil para proteger el jardín. Una brecha también puede ser algo que requiere nuestra atención. En inglés la expresión “Mind the gap” es una frase acuñada a finales de la década de 1960 por el metro de Londres para advertir a la gente sobre el espacio que hay entre la plataforma y los vagones del tren. Si las personas no tienen cuidado con ese espacio, podría generar una situación insegura.
La brecha en este caso es la distancia entre nuestras habilidades actuales y dónde pensamos que deberíamos estar. A veces las brechas son auto impuestas debido a nuestros propios deseos de mejorar, pero la mayoría de las veces las brechas son impuestas de manera externa.
Uno de los grandes creadores de brechas en nuestra profesión como programadores es el cambio. Como programadores estamos siempre alerta del ciclo de los cambios en la cultura de la programación. Estamos constantemente enfrentándonos a los cambios que nos llegan: cambios de tecnología, cambios de prioridades en el trabajo o incluso cambios en nuestra estrategia para tratar de mantenernos al día con las demandas que se nos piden.
El cambio también puede provenir de dentro de nuestra comunidad. En nuestra comunidad de programadores y usuarios puede cambiar a nuevos puestos de trabajo o nuevas tecnologías. Es posible que ya no obtengamos el apoyo que necesitamos para hacer nuestro trabajo y que nos enfrentemos a la posibilidad de que nosotros también necesitemos actualizar nuestras habilidades o nos quedemos atrás en una comunidad abandonada.
El cambio puede provocar estrés. Es común en el círculo de los programadores porque las cosas cambian a menudo. Lo que funcionaba el viernes por la tarde puede que ya no sirva el lunes por la mañana debido a un cambio en una biblioteca que estábamos utilizando. Nuestro entorno de desarrollo podría romperse debido a una actualización que no se aplicó de la manera correcta. El código en producción podría necesitar algunos parches de seguridad y esos parches significan que tenemos que volver a hacer una gran parte de nuestro software porque si no ya no funcionaría. Hay una gran variedad de maneras en las que estamos inmersos en ese ciclo del cambio.
No todo el cambio es malo. El software que utilizamos podría tener razones muy válidas para cambiar. Las nuevas funcionalidades que deben ser añadidas requieren nuevas formas de pensar nuestro código. Las correcciones a problemas de seguridad podrían significar que nuestros sistemas ahora serán más resistentes frente a ataques externos, pero requieren diferentes formas de utilizar ese sistema. Nuevas y mejores optimizaciones pueden llevar a que nuestro código se ejecute de una manera más rápida pero necesite algunos ajustes para que pueda beneficiarse de esa velocidad. Refactorizar una API puede llevarnos a interactuar con nuestros sistemas de una manera más limpia y concisa, pero puede introducir cambios que no son compatibles con el código actual.
El cambio puede ser positivo, pero el cambio requiere tiempo y esfuerzo para adaptarse a él. La brecha solo se puede cerrar si tenemos los recursos y el tiempo necesario para trabajar en ella. Si estamos luchando con nuestra carga de trabajo actual y alguien cambia la forma en que funciona algo, ahora tenemos que tener en cuenta nuestro tiempo para adaptarnos a ese cambio. Si nuestro músculo de memoria mental sabía cómo funcionaba algo y ahora se enfrenta a un cambio significativo, requiere que volvamos a entrenar ese músculo de memoria mental para que coincida con la forma en que funciona ahora. Y si ya sientes que no comprendes los sistemas y entornos en los que estás trabajando, añadir cambios adicionales pueden dejarte varado entre las brechas recién formadas de tu conocimiento.
Me encantaría decirte que hay una manera de cerrar esa brecha, decirte que has aprendido todo y que ya te puedes sentir a salvo porque ya dominas la totalidad de la programación.
Desafortunadamente, yo no he encontrado una manera de cerrar las brechas.
Puedes seguir aprendiendo todo lo que hay que saber sobre cualquier tema sobre el que hayas escogido aprender. Puedes realizar todos los cursos disponibles. Puedes asistir a todas las charlas y debates, leer informes que traten del tema e incluso realizar tu propia investigación y aún así te puedes seguir sintiendo como que no has cerrado definitivamente esa brecha.
Así que, si no hay una manera de cerrar por completo la brecha ¿Qué puedes hacer?
Tienes tres posibles opciones disponibles:
La primera opción es no intentarlo. Asumir que siempre habrá algo más que aprender. ¿Por qué preocuparse? Es más sencillo auto convencerte de que nunca serás capaz de cerrar esa brecha del conocimiento. La mejor opción es, te dices a ti mismo, quedarte con lo que sabes y aguantar todo el tiempo que puedas.
La segunda opción es intentar hacerlo todo a la vez. Te lees cada libro, cada artículo de un blog, cada nuevo informe, vídeo, o lo que sea para intentar aprender sobre el tema. A continuación, te das cuenta que solo tienes una cantidad finita de tiempo para aprender sobre el tema y que no puedes consultar todo ese material a la vez. Revisas tu progreso y te desesperas porque tu aprendizaje no está progresando tan rápido como te gustaría. Culpas a los materiales de aprendizaje por tu falta de progreso y buscas algo más que te ayude a aprender mejor el tema. La frustración se instala cuando te culpas a ti mismo por no haber comenzado antes a cerrar esta brecha.
La tercera opción es el enfoque más mesurado. Empiezas poco a poco con pequeñas tareas y avanzas hacia la meta. En lugar de ver la brecha como algo que se deba cerrar, te das cuenta de que no puedes conocer la totalidad de cualquier tema que estés aprendiendo. Disfrutas del conocimiento que recibes en la búsqueda del aprendizaje del tema. Mantienes un ritmo constante para aprender tanto como puedas. En lugar de lamentarte por no haber comenzado antes, estás agradecido de haberlo hecho.
De estas tres opciones, la primera y la tercera son en las que encontrarás mayor satisfacción. La primera opción (no intentar) te permite acomodarte con el conocimiento que tienes. Pero hay una desventaja en simplemente permanecer en el lugar. Nuestra industria está en constante cambio y la tecnología sigue avanzando. Lo que solía ser la norma se convierte en algo ya obsoleto y lo que estaba a la vuelta de la esquina se convierte en lo que está siendo demandado.
Una de las habilidades más útiles de un programador es la capacidad de adaptarse a las nuevas tecnologías. A medida que cambia nuestro entorno tecnológico, nuestra capacidad para adaptarnos a esos cambios nos permite continuar como programadores. Máquinas más rápidas, diferentes tecnologías, diferentes dispositivos, diferentes requisitos, cada uno de estos nos trae desafíos emocionantes si los reconocemos. Pero también consumen tiempo para aprender y crean brechas en nuestro conocimiento. Confiar en nuestro conocimiento previo para llevarnos a través de estos cambios no será suficiente. Tenemos el desafío de adaptarnos al nuevo entorno.
La segunda opción (tratar de acapararlo todo y frustrarse) es el camino menos óptimo. Tratar de aprender con todos los recursos disponibles e incrustándolos en nuestros cerebros es un camino hacia la frustración, la fatiga y el agotamiento. Muchos desarrolladores intentan esto porque sienten la necesidad de adaptarse al nuevo entorno, pero es difícil hacer muchos cambios radicales de una sola vez. Es como tratar de desarrollar alas para volar porque llegas tarde a una cita: te sentirás frustrado por su incapacidad para desarrollar alas y aun así llegarás tarde a tu cita. La segunda opción también mide tu progreso en función de cuánto más crees que debes avanzar. Descarta el progreso hecho y crea un ciclo sin fin hacia una línea de meta en continuo movimiento.
De las tres opciones, la tercera opción es la que tiene más sentido. El tomar una decisión mesurada para cerrar las brechas de nuestro conocimiento nos permite disfrutar más del proceso de aprendizaje. Al conseguir pequeños pasos en nuestro viaje, esto nos concede pequeñas victorias en el camino recorrido. En vez de esperar una gran transformación nos permitimos cambios graduales para adaptarnos a nuestro entorno.
Con este acercamiento mesurado y gradual también obtenemos la sabiduría de que no tenemos que cerrar todas las brechas. Nos permitimos seguir aprendiendo en las áreas que necesitamos y de forma gradual vamos construyendo nuestras propias habilidades.
También nos podemos dar cuenta, que cerrar la brecha por completo es una ilusión. Mientras seamos personas vivas siempre habrá brechas, ya que surgen cosas nuevas cada día. Podemos escoger cómo de expertos podemos ser en cualquier tema que hayamos escogido aprender. Incluso podemos esforzarnos por aprender tanto como podamos, pero lo hacemos con una sensación de alegría en el proceso de aprendizaje, no por una necesidad perversa de tratar de recopilar la totalidad del conocimiento informático en nuestras cabezas.
El secreto para avanzar en nuestro viaje como programadores y desarrolladores es darnos cuenta de que cada paso que damos en ese camino es valioso y digno de nuestra atención. El hecho de que no hayamos aprendido la última tecnología en quince días no significa que debamos dejar de intentarlo. Tampoco aprender una tecnología solo para ver cómo se ve eclipsada por otra cosa, significa que nuestro tiempo de aprendizaje se haya desperdiciado. Cada desafío al que nos enfrentamos, cada tecnología que aprendemos y cada hora que dedicamos a programar es un paso más en nuestro viaje para convertirnos en mejores programadores. Cada error y giro equivocado nos presenta oportunidades para aprender de esos errores y crecer como programadores y desarrolladores. No existe un camino perfecto para mejorar en esto. Incluso si lo hubiera, estoy seguro de que podríamos señalar cualquier punto de nuestro pasado y decir que fue menos que perfecto. No es posible trazar el camino perfecto desde donde estamos hasta donde deseamos estar. Peor aún, es una ilusión que nos impide avanzar en nuestra práctica diaria de programación y desarrollo. Puede parecer trillado decir “el viaje es la recompensa”, pero cada día que trabajamos como programadores y desarrolladores estamos un día más cerca de cerrar esas brechas en nuestro conocimiento y estar más contentos de ver cómo crecen nuestras habilidades.
A lo largo de la historia de la computación ha habido personas que han demostrado increíbles capacidades a la hora de crear código. Residen en el panteón de los grandes programadores informáticos: Ada Lovelace (la primera programadora de computadoras), Dennis Ritchie (el creador del lenguaje de programación C), Rear Admiral Grace Murray Hopper (creadora de COBOL y acreditada por encontrar el primer “error” informático documentado). (N. del traductor: un error informático en inglés es llamado “bug” que también se puede traducir como bicho o insecto) y muchos más. También tenemos desarrolladores en nuestras propias comunidades, que tienen un cierto grado de notoriedad, ya sean las personas que escribieron el lenguaje de programación que usamos actualmente, las personas que mantienen el sistema operativo que usamos o alguien que saltó a la fama en nuestra comunidad preferida. Puede ser intimidante cuando nos comparamos con estas grandes personas. Después de todo, cualquier cosa en la que estemos trabajando actualmente podría no estar a la altura de lo que estas personas hayan hecho. Peor aún, podemos estar trabajando en algo similar y sentir que cualquier cosa en la que estemos trabajando nunca estará a la altura de lo que estas personas han logrado. Incluso podemos ser amigos de programadores que parecen resolver las cosas mucho más rápido y de una manera más elegante que nosotros y maravillarnos de cómo parecen tener todo ese conocimiento al alcance de la mano que posiblemente no podamos entender.
Uno de los mejores consejos que he recibido sobre compararnos con los demás, es darnos cuenta de que la comparación es entre nuestra vida entre bastidores versus la actuación final que ven los espectadores. La metáfora se basa en el teatro, donde los artistas saben todo lo que no está bien sobre la actuación de su propio grupo de teatro y lo comparan injustamente con la actuación final de otro grupo de teatro. Esta metáfora es útil en nuestro caso porque tendemos a comparar todas las cosas que sabemos (las largas horas de crear código improductivas, las dificultades para aprender, etc.) con el producto final de otra persona. No vemos su lucha para hacer que las cosas funcionen, o sus innumerables horas haciendo prototipos de mierda y proyectos sin terminar antes de hacer lo que admiramos. Permítete tener un lugar entre bastidores desordenado y hacer muchos ensayos, y comprende que se necesita esfuerzo y práctica para realizar una buena actuación.
Hay una tradición en algunos proyectos de programación (especialmente en proyectos de desarrollo de juegos donde hay un final claro para el proyecto cuando se envía el producto) de hacer una autopsia del proyecto. Lo que hace la autopsia, es permitir que los desarrolladores de un proyecto indiquen lo que salió bien y lo que no salió bien. Las mejores autopsias tienden a ser relatos sinceros de los éxitos y fracasos de un proyecto.
La autopsia puede ser una mirada fascinante al desarrollo de un proyecto. Me he encontrado leyendo muchas de estas, en busca de información sobre el proceso de desarrollo. Pero hay una trampa sutil en la autopsia: son un recuerdo de eventos desde el punto de vista de un proyecto exitoso (o fallido). Son un recuerdo de alguien que trabajó en un proyecto que fue lo suficientemente exitoso, como para que tu dediques tiempo a leer sobre los altibajos de ese proyecto. Están escritos desde una perspectiva en la que el éxito del proyecto es una conclusión inevitable (o están escritos sobre proyectos que se destacaron por cómo fallaron o no cumplieron con las expectativas de los involucrados). Puede llevar a la creencia de que en lo que estás trabajando no es tan importante como las cosas en las que están trabajando otras personas. Pero no sabemos la importancia de nuestro proyecto en tiempo real. Incluso la gente en la autopsia no sabía si su proyecto funcionaría o tendría éxito mientras trabajaban en él. Es posible que nuestros proyectos nunca vean la luz del día o que sean algo que cambie el mundo. No podemos saber el valor de aquello en lo que estamos trabajando mientras lo hacemos (aunque podemos tener una idea de si sentimos que nuestro trabajo es importante o no).
Una autopsia también tiene el beneficio de la retrospectiva. Las decisiones que eran claras y definitivas en ese momento podrían no tener mucho sentido cuando se las compara con los datos obtenidos más adelante en la vida útil del proyecto. También hay un problema con la “memoria selectiva” en la que es posible que algo no se recuerde con la misma claridad o se combine con otros eventos. Declaraciones confiadas como “Sabíamos que esto no habría funcionado” en realidad podrían haber sido “No estábamos seguros de si esto funcionaría, así que probamos varias cosas. Todas no funcionaron”. Debes considerar a cualquiera que escriba sobre su pasado como un narrador poco confiable. Cierto, pueden ser los mejores y más informados narradores que tenemos, pero no tienen una perspectiva objetiva de lo que sea que estaban creando. Tienen sus propios prejuicios y razones para las historias que presentan en una autopsia. Debes tratar estas autopsias como tratarías una autobiografía de una persona famosa: una fuente primaria con una agenda para mostrar el tema de la mejor manera posible.
No hay nada de malo en leer una autopsia sobre un proyecto, podemos aprender mucho sobre cómo se ejecuta un proyecto (o no se debe ejecutar) y qué peligros debemos tener en cuenta si seguimos un camino similar, pero hay que comprender que estás leyendo un informe (ya sea de una persona o de un equipo de personas). Tienen la perspectiva de alguien profundamente involucrado en el conflicto. Estás mirando sus recuerdos de tácticas, no la estrategia general que los trajo al lugar.
Hay muchas medidas que la gente usa para clasificar a los programadores. Es probable que hayas visto que estas medidas se manifiestan de diferentes maneras: sitios de competencia, números de commits en un proyecto, medidas de productividad, tiempo para entregar el código y los buenos sentimientos viscerales que podamos sentir, como se hacía antiguamente. Nos lo hacemos a nosotros mismos y a los demás. Comparamos nuestro trabajo con el trabajo de nuestros compañeros y gente que admiramos, pero eso puede llevarnos a hacer comparaciones que no son objetivas o no se basan en todos los datos. Puedo compararme con personas que hacen programación de bajo nivel y encontrar que no estoy a la altura en ese ámbito. No importa que no haya hecho mucha programación de bajo nivel, la comparación es válida. O puedo compararme con personas que fueron asesoradas por programadores cuyos nombres son legendarios en su campo. Encontraré brechas entre mi conocimiento y el de ellos, porque no tuve acceso a esos mentores (o peor aún: no aproveché los mentores a los que podría haber accedido. ¡Ups!). Comparaciones como estas no ayudan y nos llevan a castigarnos por no ser otra persona. Nuestra evaluación de nuestros proyectos e historia nos da la conclusión de que no somos esa otra persona, ni podríamos ser nunca esa otra persona.
El mayor problema con la clasificación de programadores (o en cualquier caso, clasificación de cualquier cosa) es que los sistemas de clasificación están basados en una serie de criterios. No hay un estándar real para clasificar programadores. Los sitios donde se clasifica y puntúa programadores en base a un número de problemas resueltos o la dificultad de los problemas resueltos solo han determinado que hay una serie de programadores que realmente disfrutan resolviendo esa clase de problemas. También han reunido a un grupo de programadores que dedicarán tiempo y esfuerzo a resolver estos problemas y serán competitivos mientras los resuelven. Nos dice poco sobre las habilidades del programador fuera de esa materia.
También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina “código de golf”, donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar acerca de cómo de “limpia” es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la “notación Big O”, una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que utilizó un programador en su código. Podemos hacer una prueba de estrés o de esfuerzo del código para determinar lo bien que se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra, es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar la rueda de un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar ruedas de automóvil. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.
También hay una tendencia a medir la productividad del programador mediante cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan commits. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los commits que están realizando otros programadores. Dado que podemos medir la cantidad de commits, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de commits que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus commits con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. Nos preguntamos “¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?”
Es incluso todavía más frustrante cuando otras personas utilizan estas medidas para judgar la productividad y las contribuciones con código. Podemos encontrarnos siendo criticados por nuestros resultados (o la falta de estos).
Los commits y las líneas de código son las medidas más visibles de la productividad al crear código, pero no muestran mucho sobre la práctica real de la programación. No podemos medir la cantidad de tiempo que dedicamos a pensar en el problema con solo mirar un commit. No vemos las montañas de material de referencia que usó el programador para encontrar una solución y ciertamente no sabemos si este commit es el resultado de una tarde de trabajo o de muchos días de trabajo (a menos que se hagan commits con más frecuencia). Incluso podríamos descubrir que esta persona está actuando como el punto central de una organización y está integrando el trabajo de varias personas en sus commits.
Medirnos a nosotros mismos basándonos en la cantidad de la producción de otras personas es fácil y muy seductor pero no es útil para hacerse una idea de cómo mejorar nosotros mismos en nuestra tarea de crear código (a no ser que sea “generando más commits”). Esa forma de pensar puede llevarnos a creer que no estamos dedicando el tiempo suficiente a la “programación real” y provocar exceso de trabajo, estrés y agotamiento.
Hay momentos en los que es útil compararnos con otros programadores. A veces podemos aprender sobre nuevas tecnologías o nuevas metodologías mirando el trabajo de otras personas, pero es fácil caer en la trampa de pensar que porque no estamos al nivel de otros programadores somos de alguna manera inferiores a ellos. En lugar de ver a otros programadores como competencia, deberíamos verlos como compañeros. Todos estamos en esta profesión trabajando para mejorar nuestros respectivos proyectos. Con el software libre y de código abierto tenemos una oportunidad única de ver cómo otras personas hacen su trabajo en público. Podemos aprender del código de otras personas de la misma manera que los científicos pueden mirar los artículos de otros científicos para ver qué funcionó (y pueden mejorar la validez del artículo con una réplica y repetición). Ningún programador está completamente aislado del trabajo de los demás. (Es raro que un programador haya creado el código de todo su entorno de programación desde cero sin el trabajo de otras personas). Todas las personas aprendemos unas de otras, pero en lugar de intimidarnos por el trabajo de otras, podemos desarmarlo y aprender de él. Si tenemos suerte, podemos aprovechar la oportunidad para preguntarles cómo funciona el código y por qué eligieron escribir el código de esa manera.
Es valioso hacer preguntas a nuestros compañeros programadores. Tendemos a pasar por alto hacer preguntas por miedo a que vamos a hacer algo obvio o hacer una pregunta que nos haga sentir incómodos por haberla realizado. Hacer preguntas es muy útil cuando no entendemos qué está pasando con una idea o una pieza de código en particular. Hay programadores a los que no les importa responder preguntas, y espero que los encuentres. De acuerdo, hay algunos programadores que están muy ocupados y es posible que no tengan el tiempo o la predisposición para responder preguntas, pero si realmente estamos atascados y hemos agotado todas las demás vías, tal vez podamos hacerles preguntas que no requieran mucho de su tiempo y esfuerzo. Incluso pueden estar agradecidos por la pregunta porque les da una idea de una perspectiva que de otro modo no tendrían. Cuando hacemos preguntas iniciamos un intercambio de ideas en ambas direcciones.
Hacer preguntas es todo un arte y puede ser frustrante cuando las personas no responden nuestras preguntas o nos responden con otras preguntas o sugerencias que no son útiles. Esto se manifiesta en intercambios donde la persona A pregunta: “Me gustaría saber cómo hacer X” y las personas B y C responden “Yo en tu lugar haría Y”. Es frustrante cuando la gente no responde a nuestras preguntas de manera directa. También es fácil verse envuelto en intercambios con la gente sobre los méritos de hacer Y, donde Y fue sugerido por otra persona que no tiene nada que ver con la pregunta original sobre X. Pero si volvemos a enmarcar la experiencia como “esta persona está tratando de ayudarme, tal vez haya algo en esta recomendación que pueda ser útil”, entonces podemos tener una mejor conversación. Quizás lo que estamos preguntando no es la mejor manera de hacer algo y hacer una pausa para escuchar puede ayudarnos a comprender mejor por qué hicieron su sugerencia.
El sacar nuestros egos de la pregunta nos permite estar más abiertos a las respuestas que recibimos. Cuando las personas no entienden nuestra pregunta, es fácil tomarla como algo personal y protestar pensando “no me entienden” o “no me escuchan”. Al abstraernos de la pregunta nos permite tomar la respuesta proporcionada “tal cual” y nos da la capacidad de cambiar la pregunta según sea necesario para obtener mejores respuestas.
Por supuesto, hay personas que no responderán pensando en lo mejor para ti y solo están interesadas en imponerte su propia visión del mundo. En lugar de responder a tu pregunta, cuestionan por qué estás haciendo eso y en su lugar sugieren que deberías usar su metodología. Puede requerir mucha energía enfrentarse con estas personas y decirles “no, realmente tenía la intención de aprender más sobre X”. Me gustaría tener buenas respuestas sobre cómo manejar a este tipo de personas. Muchas de estas personas, sienten que cualquier cosa que estén haciendo es el único camino correcto y aquellas personas que se desvían de su camino elegido son anatema para su mundo. Mi mejor sugerencia es agradecerles su tiempo y pedir ayuda a alguien más. Tal vez puedan ser útiles en el futuro cuando tenga preguntas sobre lo que sea que sea parte de su agenda, pero por ahora conviene ser lo más amable posible y desearles lo mejor en su viaje de programación. Los espacios tecnológicos tienen mucha gente que ha estado trabajando con computadoras durante mucho tiempo y se ha formado opiniones sólidas sobre sus herramientas y tecnologías. Mi esperanza es que puedas encontrar a las personas que también son amables y están dispuestas a compartir lo que saben y no acosarte con sus creencias arraigadas. Con el tiempo, también formarás tus propias creencias sobre lo que funciona y lo que no funciona y transmitirás ese conocimiento a los demás. Reconocer a las personas que están ahí para ayudar a educar y a las que están ahí para hacer proselitismo es parte de nuestro proceso de crecimiento.
Si vemos a otros programadores como compañeros de viaje en esta travesía, como colegas en nuestra práctica a la hora de crear código, entonces nos daremos cuenta que estamos en esto todos juntos. Incluso alguien con muchos más años de experiencia que nosotros es tu colega. Tienes conocimientos y experiencia que ellos no tendrán y ellos tienen experiencias y conocimientos que tu no tienes. Si nos despojamos de las barreras del estatus que percibimos y de la meritocracia de esas personas podremos entendernos mejor y aprender unos de otros.
El viaje para llegar a ser un programador mejor es largo y duro. Necesitamos los mejores compañeros que podamos encontrar para ayudarnos en este viaje. Necesitamos algo más que únicamente compañeros que tengan muy buenos conocimientos técnicos, también necesitamos compañeros con los que podamos hablar cuando la jornada termina. Necesitamos compañeros con los que podamos sentarnos alrededor de la fogata proverbial e imaginaria donde juntos podamos reír y compadecernos de nuestras luchas.
Tiene que pasar: algo que pensabas que era una buena idea no funcionó de la manera que lo habías planeado, y ahora te das cuenta de que has cometido un terrible error. A veces es algo que se podría haber evitado fácilmente (por ejemplo: realizar un commit de un código destinado a la depuración). A veces es una cascada de errores, cada uno de los cuales se basa en las consecuencias del error anterior. Está el error de ignorar los efectos secundarios de un módulo cuando se usa de una manera que no estaba prevista, o darse cuenta de que has diseñado un módulo pequeño y estrechamente acoplado y después descubrir que tu módulo será parte de una pieza de software más grande y tu código no está diseñado para hacer una transición sin problemas. ¡Vaya!
Sin embargo, los errores que realmente me asustan son los que no esperaba, aquellos en los que las consecuencias no deseadas corren desenfrenadas por todo el sistema como una reacción en cadena. Esos errores son los que me quitan el sueño por la noche.
Los programadores cometen errores. La naturaleza de nuestros trabajos requiere que seamos conscientes de lo que sucede en múltiples secciones de código. Perdemos la noción del estado de nuestro programa y del código que ya hemos realizado. Intentamos salpicar nuestro código con comentarios y recordatorios de lo que sucede en una sección del código, pero los comentarios se vuelven obsoletos y aumentan nuestra distracción. Nos apresuramos y confiamos que el músculo de nuestra memoria tome el relevo. Nos negamos áreas en las que podemos probar el código adecuadamente porque sentimos que debemos apresurarnos para hacer las cosas rápidamente.
Entramos en pánico, y cuando entramos en pánico cometemos errores.
Vamos a hablar con claridad: no hay manera de evitar o eliminar los errores. El software es demasiado complejo para estar completamente libre de errores. Sin embargo, lo que podemos hacer es crear lugares en los que podamos detectar tantos errores del código como sea posible antes de mostrarlo a los demás. Podemos comprender mejor nuestro código y lo que está haciendo cuando tenemos la capacidad de depurar y probar nuestro código en un entorno seguro. Podemos ver cómo se comportará bajo ciertas circunstancias. La creación de un modelo similar al del sistema de destino nos permite probar nuestro código con versiones más pequeñas de la realidad del sistema del destino y ver cómo se comporta en esas condiciones.
Ponemos mucho énfasis en evitar errores, tanto en la programación como en la cultura de la programación. Hay historias de terror de cómo pequeños errores en un programa causaron grandes dolores de cabeza a las personas involucradas. La moraleja de estas historias es que los errores simples pueden ser costosos y debemos ser doblemente cuidadosos para evitar errores. Estas anécdotas se cuentan con la esperanza de asustar a los desarrolladores para que sean más cautelosos, pero pueden tener el efecto contrario. Pueden hacer que los programadores se vuelvan paranoicos acerca de poder cometer cualquier error, y cuando operamos en un modo basado en el miedo, comenzamos a entrar en pánico. Decirle a los programadores que no cometan errores es similar a decirle a alguien que no tenga miedo: tienen más miedo de tener miedo.
La mejor (y quizás la única) forma en que aprendemos, es cometiendo errores. Aprender cometiendo errores es una forma efectiva de permitirnos ser curiosos y ver qué causó que el programa fallara. Cuando nos privamos de la libertad de cometer errores, nos privamos de las oportunidades de aprendizaje al cometer esos errores. Eso no significa que tengamos que cometer todos los errores que otros desarrolladores han cometido antes que nosotros (eso serían montones de errores). Tampoco significa que debamos introducir el caos en nuestro proceso de desarrollo para aprender mejor. Lo que significa es que debemos cometer nuestros propios errores a nuestra manera, para seguir aprendiendo y descubrir dónde existen lagunas en nuestra comprensión.
Necesitamos entornos donde los programadores puedan aprender de una manera segura de sus propios errores. Necesitamos espacios donde los programadores puedan sentirse bien y seguros a la hora de probar cosas nuevas. Necesitamos lugares donde los desarrolladores puedan probar sus ideas y que esos cambios no se extiendan a otros sistemas no relacionados. Esta es la mejor forma, con la que los desarrolladores pueden aprender y ser valientes en su proceso de aprendizaje.
Estos entornos deben replicar los sistemas de destino y deben estar lo más cerca posible de esos sistemas de destino. Eso no significa que haya que hacer copias exactas de entornos de producción costosos, pero sí se necesita crear modelos de entornos de producción que prueben la mayoría de las piezas con las que tu código entrará en contacto. Tener modelos o réplicas que reflejen los sistemas de producción significa que cuando muevas tu código a producción, introducirá menos cambios con consecuencias no deseadas. Tus cambios ya habrán existido en un entorno de producción. Puedes estar tranquilo sabiendo que los cambios que provoquen en estos modelos serán los mismos cambios que aparecerán en el sistema de destino.
En la situación más ideal, necesitarás tener un entorno como este, en una máquina que controles. Esto significa que no estás compitiendo con otros programadores de tu organización que también están siendo valientes con sus cambios. También querrás asegurarte de que tu entorno se mantenga actualizado con sus cambios (y cualquier cambio de producción) para que tu modelo de desarrollo coincida con lo que está en el sistema de destino y lo que estará en el sistema de destino. Un buen modelo es aquel que se mantiene actualizado con lo que se está modelando. Es lo mismo que un mapa de una ciudad: es mejor cuando coincide con el área de su modelo y se mantiene actualizado con los cambios que ocurren en esa ciudad. Un buen mapa de la ciudad podría informarte sobre las obras recientes que se están realizando en tu ruta. Un mapa inútil es aquel que ni siquiera muestra tu ruta porque no se había construido esa ruta cuando se creó el mapa. Si nuestro modelo de producción se está quedando atrás constantemente con respecto a lo que está en producción, dedicaremos más tiempo a rectificar los cambios que estamos haciendo con los cambios entre nuestro modelo y el que está en producción.
Esto también significa que deberíamos tener un entorno que se pueda reconstruir rápidamente y replicar según sea necesario. Tener un modelo que se convierte en su propia realidad separada se convierte en un sistema más para mantener. Este modelo debe ser algo que se pueda eliminar y reconstruir a voluntad para eliminar cualquier experimento anterior. Es mejor pensar en él como una copia efímera de tu entorno de destino que tiene un uso limitado y puede desecharse cuando ya no sea necesario. Este entorno de pruebas debe ser rápido a la hora de volverlo a replicar para que haya poca fricción a la hora de crear nuevos entornos para probar. Eso quizás puede significar crear secuencias de comandos para el proceso de construcción de estos entornos. La forma en que decidas hacer esto depende de ti, pero ten en cuenta que quieres algo que sea lo más simple posible y que requiera la menor cantidad posible de nuestra atención para replicarlo.
De nuevo, no tiene que ser perfecto, sólo es un modelo, pero necesita ser lo bastante similar al original para que tu código se comporte de una manera similar entre el modelo creado y el entorno real.
Hay un buen número de personas que te hablarán sobre los beneficios
de un sistema de control de revisiones (y muchas de esas personas te
mostrarán los pasos exactos para configurar un sistema de control de
revisiones). Los sistemas de control de revisiones como
git, svn, o cvs y similares han
ayudado a los programadores a coordinar lanzamientos de publicaciones y
mantener un registro de qué trabajos se han añadido a sus proyectos.
Tener un buen sistema de control de revisiones te permite crear áreas
donde puedas probar código nuevo sin tener que añadir estas pruebas a
código ya en producción. Un buen control de revisiones te permite crear
un espacio (o también llamados ramas o branch por su nombre
en inglés cuando estamos hablando de git) basado en un
código ya existente que puedes utilizar para experimentar y desarrollar.
También te permite realizar commits en ese espacio y divagar
tanto como necesites para poder explorar a fondo los cambios que estás
realizando. Sin embargo, lo que es más importante es que un buen sistema
de control de revisiones también te permitirá abandonar ese espacio si
lo necesitas, no estás forzado a añadir esos cambios a tu código en
producción. Esto te permite ver si algo podría funcionar o abandonar
esos cambios si no lo hace. Un buen control de revisiones brinda a los
programadores la capacidad de ramificarse desde cualquier punto en el
tiempo y explorar lo que sucedió en el código base. En cierto sentido,
son máquinas del tiempo y universos infinitos, lo que te permite jugar
con distintos escenarios “¿y si?” con tu código y avanzar y retroceder
en el tiempo en el código. Esto es vital para tu aprendizaje porque
puedes sentirte seguro probando y probando cosas y rebobinando esos
cambios (o eliminándolos por completo) sin afectar el trabajo de otras
personas.
Aprender cómo funciona tu sistema de control de revisiones te dará libertad para cometer errores. Muchos de estos sistemas pueden parecer complejos al principio, pero con la práctica continua y paciencia, comprenderás lo que hace el sistema de control de revisiones y cuáles son sus posibilidades. Podrás juzgar cuántos riesgos puedes tomar con tu código y tener más confianza con los riesgos que tomas.
El control de revisiones también puede desempeñar un papel importante al poder ver el desarrollo del código de otras personas. Puedes disponer de una ventana a su proceso de desarrollo y ver cómo se desarrollan ciertas características a medida que se añaden. Esto puede ayudarte a aprender sobre una base de código desconocida y mostrarte la dirección que tomaron para hacer el código de la manera que es. Puede brindarte una ventana a la historia de un proyecto y lo que se hizo para que sucediera. El control de revisiones puede ser una máquina del tiempo en la historia de un proyecto y puede ayudarte a comprender que la programación es un proceso. No todos los proyectos vienen completamente ya formados de la mente de los programadores.
A veces fallamos. A veces, el código que escribimos no está a la altura de las realidades del sistema en el que se implementa. Enviamos código que hace algo inesperado y como resultado, los sistemas se rompen. Podemos perder la noción de dónde estamos en nuestro código y hacer cambios que entren en conflicto con otros cambios, lo que luego hace que dediquemos tiempo a deshacer esos cambios. Todos estos casos causan malestar, ya sea para nosotros, las personas a las que ayudamos o las personas con las que trabajamos.
No voy a mentir: el fracaso apesta. Nos hace sentir que somos menos personas porque fallamos. Nos sentimos incómodos y nos preguntamos qué pensarán los demás de nosotros. ¿Tendrán los demás una mala opinión sobre nosotros? ¿Hemos dañado nuestra relación con aquellas personas que usan lo que sea que hayamos programado? ¿Hemos defraudado a nuestro equipo? Todas estas preguntas surgen de dos deseos: el deseo de hacer lo mejor posible y el deseo de no hacer daño a los demás. Queremos que los demás piensen bien de nosotros y de nuestras habilidades. El fracaso va en contra de esos deseos y amplifica cualquier sentimiento de insuficiencia que podamos tener. Esos sentimientos pueden incluir preguntarse si deberíamos programar o si nuestros talentos deberían usarse en otras áreas. Nos preguntamos si deberíamos rendirnos.
No solemos pensar en el fracaso como parte del proceso de aprendizaje. El fracaso a menudo se ve como el punto final del viaje. En la escuela, una nota baja se considera una castigo. No lo vemos como: “necesito practicar esto un poco más”, en cambio, sentimos que nos hemos causado vergüenza e incomodidad a nosotros mismos y a nuestros seres queridos. Nos perjudicamos gravemente a nosotros mismos, si no nos damos cuenta de que el fracaso es una parte natural del proceso de aprendizaje y que está bien fracasar. No todo lo que hagamos será perfecto. Los errores se infiltrarán en el mejor código que escribamos. Nos equivocaremos y desplegaremos el código en el sistema equivocado. Nuestros errores causarán malestar a los demás. Aceptar esto nos da la libertad de darnos cuenta que, a pesar de nuestros mejores esfuerzos, no seremos perfectos. En lugar de ver el fracaso como una limitación, podemos usarlo como parte de nuestro proceso de crecimiento.
Cuando nos damos cuenta de que vamos a cometer errores, podemos cambiar nuestro enfoque sobre cómo y dónde los cometemos. Antes mencioné sobre la creación de modelos de nuestros entornos. ¿Qué mejor manera de permitirnos cometer errores que en un entorno donde esos errores se pueden contener o revertir? La creación de modelos nos permite practicar y probar nuestras suposiciones en entornos que nadie más tiene que ver. Es similar a un lugar de ensayo para músicos, donde pueden repasar su material sin necesidad de tocarlo bien a la primera. Pueden resolver las partes problemáticas y cometer errores hasta que tengan confianza en su ejecución.
Los errores sirven para aprender qué funciona y qué no funciona. Son una parte integral de nuestro proceso de aprendizaje. Tenemos tendencia a recordar las lecciones de aquello que no funcionó bien, mejor que aquellas que sí funcionaron. Los errores nos ayudan a reforzar aquellas áreas donde nos faltan conocimientos y nos ayudan a comprender las brechas que aún tenemos que cerrar.
Los errores también actúan como un recordatorio para hacer una pausa por un momento y no dejarse llevar por la urgencia de las cosas. Mis propios errores tienden a surgir cuando me apresuro a cumplir con una fecha límite (ya sea real o auto impuesta). Mis peores errores suceden cuando estoy cansado y apurado, cuando prácticamente estoy golpeando el teclado tratando de hacer que algo (¡cualquier cosa!) funcione. Cuando me permito hacer una pausa por un momento, reflexionar sobre lo que estoy tratando de hacer y sentir la incertidumbre en el momento, puedo tomar medidas para recalibrar y reenfocarme en el momento. Me doy la libertad de corregir el rumbo y comprender que no estoy dando lo mejor de mí y necesito hacer algo diferente. Puede ser algo pequeño como darle un poco de descanso a mi cerebro o algo grande como revisar las suposiciones que hice sobre lo que estoy haciendo. Hacer la pausa me permite determinar si quiero continuar haciendo lo que estoy haciendo y entender si ese es el mejor camino.
Es interesante no cometer los mismos errores dos veces, pero incluso si repetimos el mismo error aún puede ser útil. Saber que hemos repetido el mismo fallo es útil porque nos da un patrón que podemos entender. Esos patrones nos muestran que hacer esto en particular conduce a un resultado erróneo que se vuelve a repetir. Luego podemos determinar qué causó el error y planificar cómo mitigarlo. Esto es parte del proceso de aprendizaje, siempre y cuando no caigamos en una espiral de auto-recriminación cuando nos demos cuenta de que hemos vuelto a cometer el mismo error.
Un truco que yo mismo debería usar con más frecuencia es escribir un registro en un diario. Llevar un diario de lo que ocurrió y cómo lo solucionamos es una forma de explicarle a otra persona (a menudo a nosotros mismos) lo que sucedió. Explicar lo sucedido nos permite convertirnos en maestros para nosotros mismos y para los demás. Refuerza nuestro proceso de aprendizaje. Escribir lo que sucedió de una manera que otros puedan entender, nos permite organizar los pensamientos en nuestra cabeza de una manera clara y comprensible. Cuando articulamos nuestros propios pensamientos sobre lo que sucedió y los transcribimos, comenzamos a comprender nuestros propios pensamientos y podemos liberarnos de otras ideas sobre cómo solucionar este y otros problemas. Nos damos la pausa que necesitamos para comprender completamente lo que sucedió y cuál es la mejor manera de avanzar. Nos convertimos en nuestra propia caja de resonancia de ideas sobre la mejor manera de proceder.
No se trata de mantener un registro para la posteridad para que podamos mirar hacia atrás en una lista de fallos y castigarnos por el pasado (si eres como yo, eso sucede automáticamente). Es una manera de enseñarnos a nosotros mismos y maximizar el proceso de aprendizaje. Se trata de darnos la libertad de ser el instructor de nuestro yo futuro para que podamos ser más conscientes cuando un error está a punto de ocurrir y comprender cómo corregirlo. Esto nos permite concentrarnos ahora mismo el tiempo suficiente para comprender qué sucedió, qué hicimos para corregirlo y cuál es la mejor manera de proceder a partir de aquí. También nos ayuda a ubicar dónde están nuestras lagunas de aprendizaje y las “próximas acciones” que debemos tomar para llenar esas brechas.
Hablaremos más sobre el proceso de llevar un registro en capítulos posteriores pero recomiendo encarecidamente el hábito de llevar un diario, aunque únicamente sea por la razón que le brinda un aprendiz dispuesto a enseñar, incluso si ese aprendiz eres tu mismo.
Siempre que pensamos en programadores tendemos a pensar en una persona sentada frente a un ordenador escribiendo código, con el brillo del monitor reflejándose en su cara. Normalmente el programador está solo (aunque hay algunas metodologías en las que participa más de un programador a la vez, “programación en pareja” o “pair-programming” por ejemplo). Durante esas sesiones de escribir código, no hay mucho contacto con otros programadores y puedes sentirte aislado al estar en compañía únicamente de ti mismo. De acuerdo, esta puede ser una sensación agradable (hay momentos en los que realmente disfruto de la soledad junto al ordenador, completamente ocupado y centrado), pero hay otros momentos en los que necesitamos sentir que no estamos solos. Esto es especialmente cierto cuando estamos aprendiendo y adentrándonos en un territorio incómodo. Encontrar a otras personas en situaciones similares nos puede ayudar en nuestro proceso de aprendizaje. Otras personas nos pueden ayudar respondiendo a nuestras preguntas y revisando nuestro progreso. Encontrar una buena comunidad que nos apoye en nuestro aprendizaje es esencial en nuestro viaje en la programación. Cuando tenemos una gran comunidad, tenemos un lugar donde poder aprender y ayudar a que otras personas aprendan. Podemos crecer en la comunidad y encontrar apoyo.
Una buena comunidad es aquella que nos fortalece a nosotros y a quienes nos rodean. Nos nutre y nos proporciona refugio. Es un lugar seguro donde no tenemos que mantener la guardia alta de los ataques a nosotros mismos y a los demás. En ella las personas se rinden cuentas entre sí. Podemos confiar en los miembros de la comunidad y sentir que la confianza es recíproca. Las buenas comunidades existen sin competencia ni ego, donde los miembros pueden expresarse abiertamente y aceptar a los demás tal como son.
Hay un montón de buenas comunidades ahí fuera que están dispuestas a ayudarte a ser un mejor programador, pero ¿cómo encontrarlas?
Esa es una pregunta complicada.
La mayoría de lenguajes de programación tienen algún tipo de comunidad que se ha formado entorno a ellos. Algunas usan las listas de correo u otros canales de comunicación a los que te puedes unir y en los que participar. Desafortunadamente, los lenguajes de programación más populares tienen espacios que son complicados de seguir, especialmente cuando estás tratando de aprender. Lo sé porque me uní al canal principal de comunicación de un lenguaje de programación muy popular y me sentí abrumado por las múltiples conversaciones que se llevaban a cabo a la vez. Las listas de correo diseñadas para ayudar a los principiantes pueden tener una gran cantidad de tráfico de correos y ese tráfico puede ser abrumador si estás tratando de entender los aspectos básicos del lenguaje de programación mientras tratas de estar al día con la avalancha de correos que llegan a tu bandeja de entrada. Leer los correos antiguos en los archivos de las listas de correo o en un chat puede ayudarte a determinar si estás preparado para ese nivel de tráfico y si las conversaciones en la lista son el tipo de conversaciones que te gustan. Recuerda: esto es para ayudarte en el viaje. Lanzarte a una habitación abarrotada, en la que te veas inundado por una gran cantidad de conversaciones y ruido solo hará que te sientas más aislado y sentir que no eres bienvenido.
Algunos lenguajes de programación tienen grupos de usuarios locales. Estos al principio pueden parecen intimidantes, especialmente si el grupo ya tiene un largo recorrido. Lo sé, porque me sentí intimidado antes de asistir a mi primer grupo local de usuarios, por miedo a lo que podría encontrarme allí. Lo que encontré fue un grupo de personas que estaban interesadas en los temas en los que también yo estaba interesado. He hecho amistades duraderas en esos grupos locales de usuarios y te animo a comprobar si también a ti te funciona.
Si no sabes cómo encontrar el grupo adecuado (quizás te encuentres en un área en la que sientes que eres la única persona que comparte tus intereses), podrías considerar iniciar tu propio grupo o formar uno nuevo a partir de un grupo ya existente. Mi amigo Rick y yo abrimos un grupo local llamado Coffee House Coders donde los programadores se reúnen una vez a la semana durante unas horas para sentarse y programar. Todo lo que hicimos fue publicar las horas y los lugares en los que nos íbamos a reunir y les dijimos a las personas que simplemente se presentaran con su portátil para escribir código. Por el camino hemos conocido a algunas personas increíbles y hemos mantenido al grupo en marcha durante muchos años. Empezar un grupo es un acto de valentía. Ha habido muchas noches en las que me he sentado solo en una cafetería esperando a ver si aparecían otras personas. Está bien. La gente está ocupada y los intereses se desvanecen y cambian con el tiempo. Lo importante es crear el espacio para que nosotros y los demás nos sintamos bienvenidos. Para nosotros, eso significaba encontrar una cafetería local que estuviera abierta hasta altas horas de la noche y tuviera un amplio espacio para colocar nuestros portátiles. También ayuda encontrar un lugar en el que haya suficientes tomas de corriente para conectarse a la energía eléctrica, para que la gente pueda cargar las baterías de sus equipos si es necesario.
Hay muchas maneras de ser creativo a la hora de comenzar una comunidad. La llegada de las herramientas en la red permite que puedas construir comunidades con personas de todo el mundo. El acercar esas personas y reunirlas para hablar y discutir ideas y ofrecer ayuda es genial cuando ocurre. A veces, puede ser tan simple como crear una sala de chat sobre intereses comunes. Explora lo que existe ahí fuera y si lo que hay no satisface tus necesidades no dudes en crear una tu mismo.
Reconozco que cualquiera no puede unirse a una comunidad o crear una propia. Los espacios existentes en la red tienen la reputación de no ser lugares acogedores para las personas que llegan y los encuentros en persona pueden agotar tus recursos mentales. Me llevó tiempo encontrar el valor necesario para asistir a mi primer encuentro en persona y tuve una mala experiencia con alguien con el que trabajaba y que pensé que estaría en aquel encuentro. (No estoy seguro si esa persona alguna vez asistió a alguno de aquellos encuentros). Pero estoy muy agradecido de haber asistido a aquellos primeros encuentros. Asistir a esos eventos me trajo amistades, oportunidades y otros “compañeros de viaje” para mi propio viaje. Hizo que cambiara a uno de mis lenguajes de programación favoritos (Python) y me llevó a varios trabajos. También me ayudó a sentir que no estaba solo con mis intereses y me presentó a otras personas en las que podía confiar. Me dio un sentimiento de pertenencia.
Superar el obstáculo inicial es difícil. Nuestro miedo al rechazo y nuestro miedo a hacernos vulnerables a los extraños puede desgastarnos. Superar ese miedo requiere mucha energía mental y puede quitarnos el deseo de ser parte de otra comunidad más. No puedo decir que será fácil, pero puedo señalar algunos de los beneficios que tuvo en mi vida. Espero que tu puedas encontrar también esos beneficios.
Una alternativa a las comunidades en persona son las comunidades en la red. Las comunidades en la red pueden ser una excelente manera de encontrar a otras personas. Reúnen a personas de diferentes países y las reúnen en un área común. Una parte de las razones que hicieron que cambiara a encuentros en persona fue por las buenas experiencias que tuve con estas personas en salas IRC (Internet Relay Chat). Disfruté de la compañía de estas personas a través de interacciones por la red y me sentí cómodo cuando las encontré en persona.
Los bajos requisitos de entrada para muchas comunidades en línea, puede permitirnos ver de qué temas se trata en la comunidad. ¿Cuáles son sus prioridades? ¿Son amables con las personas que están comenzando? ¿Tienen un patrón de conducta de ayuda a personas como nosotros o tienden a ofenderlas? ¿Tienen miembros que nutren a sus compañeros o se están interrumpiendo unos a otros?
Desconozco si hay una estrategia óptima para determinar si una comunidad es útil o dañina. Requiere esfuerzo seguir una comunidad y formarse una idea de quiénes son. Desgasta emocionalmente el ponernos en situaciones donde somos vulnerables, para comprobar si otras personas son respetuosas con nosotros. Las comunidades están formadas por personas y las personas somos criaturas inconstantes e irracionales. Lo que puede ser una gran comunidad para una persona puede ser un entorno tóxico para otra. Aunque no tengo una estrategia, tengo algunas ideas de los elementos clave que forman una comunidad.
Hay una serie de características que yo buscaría en una comunidad. Aunque esta no es una lista definitiva de todas las cosas que hacen una buena comunidad, ofrece un listado de las pautas que creo que son importantes:
Hablaremos más sobre la amabilidad en próximos capítulos.
Estos son solo unos ejemplos de lo que he encontrado en buenas comunidades. No dudes en añadir más a esta lista cuando tu propia experiencia vaya creciendo y házmelo saber, así podré actualizar esta lista para futuros lectores.
Como programadores siempre estamos tratando de encontrar nuevas formas de ser productivos. Hacemos ajustes en los editores de texto, ajustes en la compilación, creamos scripts y automatizamos tareas, la lista se extiende dependiendo de cómo los programadores quieran maximizar la productividad del tiempo que emplean en crear código. También pasamos tiempo haciendo ajustes al resto de nuestras vidas con la creencia de que deberíamos siempre estar haciendo algo relacionado con el código. Cualquier momento que no estamos creando código es un momento en el que nuestros proyectos se retrasan. Y retrasarse con nuestro código puede desencadenar en otros problemas: plazos incumplidos, que otras empresas publiquen su programa en el mercado antes que nosotros, u otros casos en los que perdemos una oportunidad. Estamos constantemente preocupados por no estar haciendo lo suficiente para tener éxito.
Hemos escuchado historias de desarrolladores que se han despertado frente a sus equipos por un extraño pitido provocado porque se han quedado dormidos encima del teclado y la repetición automática de caracteres ya no podía gestionar más texto por que sus caras estaban apoyadas en las teclas. ¿No es así como deberían trabajar los desarrolladores?
Hay una tendencia a creer que como trabajamos con máquinas que no descansan y siempre están preparadas para trabajar más, necesitamos adaptarnos nosotros mismos a esas máquinas. Sentimos la necesidad de estar siempre en marcha y preparados para dar a la máquina más trabajo. La ociosidad se considera una pérdida de tiempo. Tratamos de llegar a ser como la máquina: sin descanso y siempre preparados para más trabajo.
Hay un problema con ese sentimiento de tener que estar siempre en marcha. Cuando sentimos que siempre tenemos que estar en marcha, no nos permitimos a nosotros mismos tener un momento de descanso. No nos permitimos periodos de ocio y descanso. Esto crea un patrón donde nos denegamos los momentos para sentarnos y centrarnos en lo que estamos haciendo. Nos forzamos a seguir en movimiento, a seguir programando sin importar el coste personal. Nuestros cerebros no tienen la habilidad de descansar, relajarse y cargarse de energía. Nuestras mentes están ocupadas y exhaustas para procesar lo que aprendimos y guardar ese conocimiento a largo plazo. Cuando estamos exhaustos empezamos a preocuparnos de que no estamos haciendo todo lo necesario. Esto no nos motiva, en vez de eso crea un círculo vicioso de miedo y pánico. Pasamos nuestro día preocupados porque no estamos haciendo lo necesario mientras que nuestras mentes gritan un “¡suficiente!” de extenuación. Este círculo vicioso de miedo y extenuación puede llevarnos a un vórtice de agotamiento, depresión y el deseo de dejar la programación para siempre.
Hay un delicado equilibrio que debemos lograr, entre nuestros deseos de estar conectados constantemente y nuestras necesidades de relajación y reflexión. Nuestro deseo de un desarrollo invencible e infatigable debe atemperarse con la realidad de que nuestros cuerpos y mentes tienen unos recursos finitos por día que deben asignarse adecuadamente. Piensa en esto, como en el suministro de energía para una máquina compleja (nuestro cuerpo y mente) en la que el fabricante (todavía) no te permite cambiar la batería cuando se agota. Ser consciente de qué procesos se están ejecutando, cuánta energía se está utilizando y cuánta energía queda es vital para garantizar que aún pueda funcionar más, hasta el final del día. Ese es el nivel de conciencia que debemos tener sobre nosotros mismos.
¿Cómo equilibramos esos sentimientos de querer estar conectados todo el tiempo mientras nos permitimos a nosotros mismos el relajarnos y reflexionar en lo que estamos haciendo? ¿Cómo prestamos atención a las necesidades de esta “máquina de programar”?
Primero, debemos ser conscientes de que no podemos estar conectados todo el tiempo. Quizá sabes esto de manera intuitiva y pensamos “claro, por supuesto” pero saber esto no es lo mismo que ponerlo en práctica. Necesitamos periodos donde no estemos programando ni pensando en programar. Deberíamos tener momentos donde poder apagar la parte del programador de nuestra personalidad. Estos periodos de no programación son vitales para nuestro propio bien estar y nos ofrecen oportunidades para explorar el ancho mundo y permitir a nuestras mentes descansar en los tiempos entre las sesiones de programación.
Esto puede ser complicado si sentimos que nos estamos retrasando en nuestro aprendizaje. ¿Cuando se supone que vamos a aprender todas esas cosas nuevas que están ocurriendo cada día? ¿Cuándo se supone que nos pondremos al día con toda esa deuda técnica que hemos ido acumulando a lo largo de los años? ¿Cuándo tendremos tiempo de conocer los entresijos de tecnologías que no forman parte de nuestro trabajo diario pero que nos siguen interesando?
Estos sentimientos que tenemos (que hay que hacer más y que necesitamos pasar cada momento en el que estamos despiertos haciendo cosas que no hagan que nos desfasemos) no son muy útiles cuando nos comparamos con otros programadores que parece que son súper productivos. Estos son los programadores que tienen una idea brillante por la mañana y un prototipo ya funcional por la tarde (mientras siguen gestionando normalmente su rutina de trabajo). Cuando nos comparamos a nosotros mismos con estos programadores nos preguntamos si se toman algún momento libre lejos de sus ordenadores.
Podemos reconocer que tenemos sentimientos de querer esforzarnos para seguir aprendiendo y haciendo cosas. Podemos notar nuestros sentimientos cuando pensamos “solo una línea de código más antes de acostarnos” o convencernos a nosotros mismos pensando: “puedo leer algunos artículos o páginas más o [inserte la forma favorita de consumir más información aquí]”. Podemos hacer una pausa y notar de dónde vienen estos sentimientos y pensamientos y entender por qué incluso nos esforzamos más allá del agotamiento.
Estos sentimientos generalmente provienen de una sensación de insuficiencia. Sentimos que no estamos a la altura de los ideales que tenemos, ya sea porque estos ideales son los que hemos creado o por que han sido creados de manera externa. Estos ideales provienen de analizar a otros programadores (colegas o personas a las que admiramos) y medir nuestro progreso en comparación con su trabajo. También provienen de nuestras propias ideas míticas de lo que hace a un programador perfecto.
De lo que debemos darnos cuenta es que esas ideas de lo que hacen los programadores buenos y perfectos son fantasías. Son una combinación de lo que creemos que debería ser un programador bueno y perfecto. No existen en el mundo real. Es cierto que podemos ver programadores que parecen despertarse con un teclado conectado a sus manos, pasan todo el día creando código y se van a dormir con sueños de formular más código en sus cabezas. Pero debemos darnos cuenta de que solo estamos viendo un lado de sus vidas. No estamos viendo la imagen completa de quiénes son. Necesitamos enfocarnos en nuestros propios cuerpos y mentes y darnos cuenta de cuándo estamos cansados y necesitamos descansar. No podemos convertirnos en otras personas, tenemos que trabajar con quienes somos y lo que somos.
Nuestros cuerpos necesitan tiempos de descanso para poder ser más efectivos. Necesitamos momentos donde podamos apartarnos del teclado y permitirnos a nosotros mismos descansar y relajarnos. Nuestras mentes no están diseñadas para el trabajo constante, especialmente a los niveles que se le requiere a un programador. Cuanto antes nos demos cuenta de que debemos dar un paso atrás y tomar descansos a lo largo del día para recargarnos, más felices (y más productivos) seremos.
Hacer un descanso es algo más que simplemente cambiar a otro programa de tu ordenador. Mi tendencia mientras tomo un descanso es comenzar a revisar mi correo electrónico o abrir alguno de mis diversos programas de chat para ver qué ha pasado desde la última vez que lo abrí (normalmente desde el último descanso que me tomé). Esto realmente no es tomarse un descanso ya que estoy tratando de realizar múltiples tareas sentado en mi mesa. Los verdaderos descansos implican levantarse de delante de la pantalla del ordenador. No es necesario que sea un descanso largo, tomarse un descanso puede ser simplemente salir de la habitación a otra área diferente de donde estés trabajando. Necesitas moverte de delante de tu equipo para obtener un “cambio de contexto”, donde tu mente puede sentir que no está en el mismo lugar donde estaba antes. El cambio de contexto le permite a tu mente cambiar por completo y eliminar el contexto del área en la que se encuentra. Permite que tu mente se concentre en un nuevo contexto y una nueva situación.
Esto puede ser complicado en una oficina donde se espera de manera implícita que las personas deben permanecer en su espacio de trabajo para ser productivas. Y solo existen algunos “descansos biológicos” (descansos que están relacionados con la biología humana, también conocidos como ir al baño) que alguien puede tomarse en tales situaciones. ¿Cómo puedes darte esos cambios de contexto que tu mente necesita en tales situaciones?
También podrías ser capaz de obtener esos cambios de contexto apartando tu vista de la pantalla por unos momentos. Es una buena idea apartar la mirada de la pantalla de vez en cuando para dar a tus ojos un descanso. Dar a tu mente un descanso mientras das un descanso a tus ojos puede ser el incentivo para que realices ambos.
Cambiar de posición de sentado a estar de pie, también puede ser un buen cambio de contexto donde te permites un cambio en tu espacio físico de trabajo. Puede ser tan simple como levantarse y estirarse de vez en cuando, o tan complejo como levantarse y agacharse en tu escritorio. Diciéndote a ti mismo que hay dos contextos en tu escritorio: sentado y de pie, podría ser suficiente para darte un cambio de contexto y el descanso que tu mente necesita.
Si tu lugar de trabajo tiene una cultura en la que se te permite abandonar tu escritorio y cambiar de lugar, eso sería un gran cambio de contexto. El añadir un componente físico (tanto como seas capaz) a tu cambio de contexto puede ayudar a tu mente a relajarse y retomar energías.
Tendrás que experimentar con algunos de estos ejemplos para determinar qué te funciona a ti. Como mínimo querrás que tu mente sienta que no necesita estar alerta todo el tiempo. Quieres que tu mente se tome unos periodos de respiro entre sesiones de escribir código para poder eliminar los restos de esa sesión de tu “caché” mental y almacenarlos en la memoria a largo plazo. Así cuando regreses a tu sesión de crear código, será más probable que recuerdes qué estaba pasando.
También es posible que descubras cuando te alejes de tu equipo por un momento, que olvidarás lo que estabas haciendo previamente. Eso está bien. Lo que recomendaría es mantener un diario o registro de en qué estabas pensando con tanto detalle como necesites. Ya sea escribiéndolo de manera física en un papel o usando un archivo de texto para tener suficientes pistas para continuar el trabajo donde lo dejaste.
Lo siguiente, deberemos darnos cuenta que la productividad no es una constante. Hay días en los que nos encontraremos generando niveles notables de código y código de calidad y días en los que tendremos suerte si podemos unir una cadena coherente de palabras para un comentario en el código. En el mismo día tenemos diferentes niveles disponibles de energía y enfoque mental. Depende de nosotros ser conscientes de estos niveles y comprender cual podría ser nuestra productividad para el día.
Entender estas variaciones de productividad puede permitirnos evaluar si el día nos permitirá o no generar código que necesita ser generado, pero hay un nivel inferior que creo que es importante.
Ponemos mucho énfasis diariamente en completar tareas y cumplir plazos. Este énfasis puede crearnos fuertes vínculos con la terminación de las tareas y los plazos. A veces esto es debido a factores externos (la “ruta crítica” del proyecto requiere que lo hagamos en una fecha y hora determinadas). Pero muchos de nuestros plazos son plazos internos que fueron establecidos por nosotros mismos. Nos marcamos una meta, de que seremos así de productivos al final del día. La condición no declarada de este plazo de productividad interna es que nos sentiremos culpables y avergonzados si no logramos el objetivo. Sentiremos que no estamos a la altura de nuestras expectativas y nos preguntaremos si somos dignos de la tarea que tenemos entre manos. Sentiremos que nuestro día ha sido desperdiciado y nos preguntaremos si somos capaces de hacer algo.
Es mejor para nosotros el eliminar los plazos cuando sea posible. No podremos eliminar los externos en los cuales los compañeros están esperando nuestras contribuciones (aunque es posible volver a negociar estos plazos si no son muy importantes) pero podemos dejar de lado el deseo de conseguir esos niveles arbitrarios de productividad y esos plazos arbitrarios.
Las metas arbitrarias pueden funcionar para algunas tareas. Algunos ejemplos de esto son los concursos de programación de juegos que solo duran una semana, lo que hace que los equipos se centren en las piezas críticas del diseño y la implementación de su juego para lanzarlo en el tiempo asignado. Este puede ser un ejercicio divertido para centrar esfuerzos, pero también conllevan mucho estrés y presión antes del fin de plazo del concurso. Si continuamente te sientes culpable e indigno porque parece que no puedes alcanzar las metas que te propusiste, entonces deberías reconsiderar si es útil usarlas.
Un truco que me ha ayudado es crear pequeños espacios de enfoque concentrado. Este truco se describe en la próxima sección.
Deberíamos reemplazar los plazos que no son estrictos (plazos que no se nos han impuesto de manera externa) con un compromiso de trabajar en un proyecto durante un periodo de tiempo. Un truco que he encontrado útil, es la idea de “contenedor de enfoque cronometrado”. Cuando realizo un contenedor de enfoque cronometrado empiezo escogiendo en qué me centraré durante el tiempo que durará ese contenedor. Una vez que está escogida la tarea a realizar, establezco un cronómetro en mi sitio de trabajo y después me centro en esa tarea con toda mi atención plena durante resto del tiempo que dure el cronómetro. He tenido buenos resultados usando 10 minutos pero sesiones de menos tiempo con 5 minutos o más largas como 30 minutos también pueden ser útiles. La tarea seleccionada al comienzo del contenedor es la única cosa en la que trabajo y trato de hacer lo posible para asegurarme de que no haya interrupciones (ya sean internas o externas) hasta que el contenedor sea completado. Cuando el trabajo se ha realizado finalizo la tarea con lo que sea que haya completado, anotando cualquiera de las siguientes acciones para esa tarea en mi lista de próximas acciones y después me tomo un descanso rápido (unos 5 minutos) antes de comenzar con el siguiente contenedor. El siguiente contenedor puede ser una continuación de la misma tarea o puedo seleccionar otra tarea, pero la idea es simple: solo me centro en la tarea que tengo delante de mí durante el tiempo asignado. Cuando mi mente trata de divagar o tengo la tentación de “únicamente comprobar una cosa”, entonces hago una pausa por un momento y determino si eso es realmente importante. La mayoría de las ocasiones no es tan importante y entonces hago una nota rápida para comprobar lo que sea cuando termine el contenedor.
Podemos utilizar estos contenedores para vencer nuestros deseos de realizar múltiples tareas al mismo tiempo. Solo nos enfocamos en una cosa cada vez. También podemos utilizar contenedores para permitir que la sesión fluya hacia donde quiera llevarnos. Cuando comenzamos un contenedor no lo comenzamos con la idea de finalizar una tarea en particular, en vez de eso vemos hacia dónde la sesión quiere llevarnos. No hay que judgar la calidad del trabajo en el contenedor, solo con la expectación de que trabajaremos durante la duración del contenedor. No hay expectativas por el trabajo que vayamos a realizar, solo que trabajaremos hasta que acabe el contenedor. Si completamos la tarea antes de que acabe el contenedor ¡eso es genial! Así podremos seleccionar la tarea para el siguiente contenedor. Si el contenedor acaba y todavía estamos en medio de una tarea, entonces podemos anotar qué nos queda y qué pasos vamos a dar para llegar allí. Entonces podemos seguir trabajando un poco más o podemos tomarnos un rápido descanso y después regresar al trabajo con un contenedor de enfoque nuevo.
El concepto subyacente del contenedor de enfoque cronometrado, es aceptar trabajar dentro de los límites del contenedor sin juzgar el trabajo realizado o el progreso realizado. Cuando realizamos el trabajo cerramos el contenedor reflejando qué hicimos y dónde necesitamos ir. Nos damos permiso para no preocuparnos en el momento por nuestro progreso, pero nos permitimos momentos donde poder revisar nuestro progreso y anotar cuánto ha progresado nuestro viaje. Nos permitimos la libertad de trabajar simplemente en el momento sin temor a juicios, represalias o auto recriminaciones. El contenedor es un regalo de trabajo ininterrumpido (o al menos todo lo ininterrumpido que podamos gestionar) que nos damos. Nos hacemos un gran favor al cerrar otros programas, desactivar las notificaciones y darle a esta tarea toda la atención que merece.
Te invito a incorporar esta práctica de realizar contenedores focalizados cada día. Creo que son una excelente manera de darnos permiso para enfocarnos en una cosa a la vez sin la necesidad de preocuparnos sobre qué conseguiremos durante la duración del contenedor. Nos permite enfocarnos en una cosa a la vez y hacerlo ofreciendo lo mejor de nuestras habilidades. La limitación de trabajar en una cosa a la vez sin pensar sobre otros aspectos del trabajo que tenemos que hacer puede ser liberadora y espero que trabajar con estos contenedores te pueda dar una sensación de lo que se siente al realizar un trabajo completamente concentrado.
Todo este libro fue creado y editado utilizando esos contenedores de enfoque. Me llevó unos 10 minutos por contenedor escribir el borrador inicial y después utilicé contenedores de 10 minutos para editar el libro. Algunas veces se extendían hasta contenedores de 15 o 20 minutos pero fue porque estaba tan metido en la materia que no quería parar. Esto está en contraste con la forma en la que antes realizaba las tareas. Por lo general, necesito superar el obstáculo inicial de asignar media hora o más a la tarea. Esto significa que necesito sentir que tengo suficiente control sobre mi horario para reservar ese tiempo. Como no tiendo a sentir que tengo ese nivel de control sobre mi horario, tiendo a postergar la tarea. Con un contenedor de enfoque, pienso para mí mismo: “Puedo tomarme 10 minutos para trabajar en esto”, que es el tiempo suficiente para que mi mente no sienta que debería estar haciendo otra cosa. Con cada contenedor vi gradualmente cómo se desarrollaba el progreso de este libro. Eso luego retroalimentó mi deseo de seguir trabajando en este libro, lo que ayudó a reducir la fricción mental para seguir haciendo los contenedores para trabajar en el libro. Creó un ciclo de retroalimentación positiva en el que esperaba con ansias la próxima vez que pudiera hacer el contenedor y trabajar en el libro.
La vida está llena de distracciones. Muchas son las cosas que requieren nuestra atención y muchas de esas distracciones están fuera de nuestro control. Alguien llega a nuestro puesto de trabajo y necesita de nuestra atención en ese momento. Un tema que hemos tratado por correo electrónico que pensábamos que estaba resuelto se convierte en una discusión acalorada y reclama nuestra atención. Algo sucede en casa y ahora nuestra mente se divide entre preocuparnos por nuestras tareas laborales o preocuparnos por lo que sucede en casa. Cualquiera que sea la causa, hay momentos en que nuestra atención no está donde queremos y nos sentimos atraídos en todas direcciones a la vez.
Es aquí cuando los contenedores son más útiles. Si algo interrumpe el contenedor podemos determinar si es más importante que el trabajo que estamos realizando. Si determinamos que es más importante que lo que estamos haciendo en ese momento podemos detener el contenedor con la idea de que regresaremos al trabajo una vez que hayamos resuelto la interrupción. Si la interrupción no es más importante entonces podremos llegar a un acuerdo (ya sea con quien nos haya interrumpido o con nosotros mismos) en el que nuestro enfoque necesita estar aquí en el trabajo hasta que finalice el contenedor. Podremos darle a esa interrupción toda nuestra atención cuando el contenedor haya acabado. No necesitamos dividir nuestra atención entre el trabajo y la interrupción, en vez de eso le daremos a ambos toda nuestra atención a su debido tiempo.
Este método crea una delimitación simple entre nuestro trabajo y el resto del mundo, pero solo porque sea simple no quiere decir que sea sencillo. Mantener esa delimitación entre nuestro trabajo y el mundo que nos rodea puede ser un reto, especialmente si la cultura en la que te mueves es la de resultados inmediatos.
No tengo buenas noticias para ti si la cultura en la que trabajas demanda tu atención todo el tiempo. Lo mejor que puedo ofrecer es un sucedáneo de contenedor que al menos te pueda ofrecer algunos periodos de concentración sin distracciones. Si te sientes siempre en tensión porque algo podría ocurrir en cualquier momento, continuarás siendo menos efectivo a diferencia de si pudieras silenciar el mundo por un momento. También te reto a examinar si esa sensación es realmente cierta ¿estás siendo constantemente siendo acechado por interrupciones? Probar esa teoría puede ser una buena práctica. Mantén un registro (ya sea en una hoja de papel, un archivo de texto, una hoja de cálculo o una base de datos, eso depende de tus gustos) de cuando hiciste un contenedor de atención y si ese contenedor fue interrumpido o no. Si al final encuentras que está siendo más veces interrumpido que no, entonces necesitas determinar qué es lo que está causando las interrupciones y evaluar si es algo que puedes controlar. Hay muchas maneras de manejar y minimizar las distracciones en el lugar de trabajo en las que no voy a entrar aquí, pero ser consciente de las distracciones y determinar de dónde vienen será la clave para saber cómo mitigarlas en el futuro.
Se también consciente de las distracciones auto impuestas que has añadido a tu vida. ¿Necesitas la notificación inmediata de que a alguien le ha gustado algo que compartiste? ¿Es la anécdota tan divertida como para cambiar tu contexto actual para así poder compartirla con tus amigos o colegas? ¿Realmente necesitas algo que emerja de repente en tu campo visual, para saber que tu reproductor de música ha cambiado de canción? ¿Estarías dispuesto a sacrificar tu atención y tu flujo de trabajo en el día a día porque un programa detectó un cambio en tu entorno, independientemente de la importancia de ese cambio?
Añadimos estas distracciones en nuestras vidas porque nos preocupa que nos perdamos algo importante. Los programas también vienen configurados con sus notificaciones activadas, así el usuario puede recordar el estado del programa todo el tiempo. Quizás es útil, pero para mí es muy molesto. En mi vida laboral me he sentado en escritorios de otras personas y me he sorprendido por el número de notificaciones que recibían en el periodo que estuve allí (en un lapso de diez minutos o incluso menos). He visto a personas interrumpir su línea actual de pensamiento porque una notificación de un mensaje de una cosa que nada tenía que ver con la tarea actual que desarrollaban les distraía. ¿Qué pasó con el pensamiento original? Tienen que regresar mentalmente a él y recordar dónde lo habían dejado, normalmente eso conlleva un gran esfuerzo mental.
Te reto a desactivar todas las notificaciones que puedas y disfrutar de la experiencia que es estar sin ellas. Eso puede ser tan simple como cerrar una aplicación cuando has acabado con ella o puede ser tan complejo como cambiar la configuración de una aplicación para que no te notifique cuando llegue un mensaje. Necesitarás probar este método y ver qué es lo que mejor funciona con tus necesidades y concentración. Una buena regla general es “¿qué es lo que comprueba esta cosa que es lo suficientemente importante como para dejar mi importante trabajo y concentrarme en esta cosa?”. Si puedes valorar tus notificaciones para que solo las notificaciones más críticas te lleguen en el momento adecuado entonces disfrutarás de un mayor relax y concentración en tu trabajo. Así no tendrás que analizar la notificación para determinar si lo que estás viendo es importante o no.
Una de las razones que he escuchado de compañeros para mantener activas sus notificaciones es que sienten que podrían recibir algo que requiriera una respuesta inmediata. Hemos creado una cultura donde sentimos la necesidad de responder a los mensajes en el momento que los recibimos. Me atrevería a decir que la mayoría de los mensajes que recibes durante el día no requieren de la atención que les estás dando y seguro que tampoco el nivel de atención que justifique la interrupción que realizas para verlos y responderlos. Sería mejor programar varios periodos del día en el que no hagas otra cosa que comprobar y responder a los mensajes. Organiza esto con la frecuencia más baja como puedas. Algunas personas recomiendan 2 o 3 veces al día, pero incluso estableciendo un límite donde compruebes tus mensajes una vez a la hora, puedes conseguir una gran mejora frente a la cantidad de veces que actualmente compruebas tus mensajes. Necesitarás judgar por ti mismo la frecuencia con la que comprobar tus mensajes basándote en tus necesidades y en tu ambiente de trabajo. También considera la persona a la que estás respondiendo. ¿Tiene sentido darle a esta persona una respuesta rápida y semi-pensada, o este mensaje requiere más tiempo para darle vueltas en tu mente antes de responder? Darte tiempo para pensar en la respuesta puede brindarte información adicional sobre un problema que podría no ser evidente en el momento. Esto podría significar la diferencia entre una respuesta bien pensada frente a una avalancha de tormenta de ideas de ida y vuelta a medio pensar utilizando tu aplicación de mensajería. Responder a todo inmediatamente es muy estresante y requiere una gran cantidad de atención que podría utilizarse mejor en tu trabajo de programación.
Puede parecer desafiante y extraño vivir sin notificaciones y sin la necesidad de responder a cada mensaje y notificación, pero nuestra atención es finita y limitada. Mantener el enfoque a lo largo del día es desafiante y estresante. Si podemos limitar la cantidad de distracciones que recibimos a lo largo del día, nos daremos la libertad de no tener que trabajar tanto para mantener nuestra atención en sintonía con nuestras tareas de programación. Podemos decir “ahora no” a nuestras distracciones y resolverlas en un momento más apropiado.
La única constante en el campo de la programación, es que siempre está en constante cambio. Los lenguajes de programación llegan a tener mucho renombre y después desaparecen con el paso del tiempo. Lo que una vez fue tomado como un hecho ahora está considerado obsoleto (o incluso “considerado dañino” como señalan algunos ensayos).
Cuando me gradué en la universidad, aprendí Pascal, Modula2 y Ada.
Desafortunadamente esos lenguajes empezaron a decaer en popularidad en
favor de C. Cuando comencé en mi primer trabajo de programación como
“profesional”, Perl era el lenguaje de elección (en parte porque Perl
podía ser transformado de manera sencilla en scripts CGI de la época y
era considerado superior a herramientas para realizar scripts como
awk y los tradicionales scripts para la shell). En el
momento de escribir esto estoy utilizando Python como mi lenguaje de
desarrollo principal y preveo que tendré que buscar otros lenguajes de
programación para expandir mi carrera como programador.
Programar requiere flexibilidad. Es difícil aprender solo una manera de hacer las cosas y mantener eso de manera relevante durante 20 años. Recuerda cual era la tecnología actual hace 20 años y no tendrás ninguna duda en darte cuenta que las cosas eran bastante diferentes entonces. Si quieres poner en práctica un ejercicio divertido, busca artículos describiendo la tecnología puntera de hace 20 años y ver en ellos cuanto de aquello reconoces.
Aprender metodologías y tecnologías específicas no es una buena estrategia a largo plazo para los programadores. Es más recomendable si aprendemos a aprender y, lo que es más importante, cómo aprendemos nosotros mismos. Eso suena simple: una vez que hayamos descifrado cómo aprender de manera efectiva, seremos programadores efectivos. Desafortunadamente, no existe una manera infalible de aprender que funcione para todas las personas. Personas diferentes, aprenden de maneras diferentes. Todos tenemos estilos de aprendizaje que funcionan mejor cuando se enfatizan ciertas cosas. Algunas personas aprenden mejor en el aula de una clase, mientras que otras aprenden mejor con el estudio auto dirigido (libros, grabaciones de vídeo, etc.). Algunas pueden leer un libro y entender perfectamente la materia, mientras que otras pueden necesitar enfoques más visuales. Si tienes el lujo de poder probar varias metodologías diferentes para aprender, te animo a que uses todas las que puedas para descubrir cuál funciona mejor en tu caso. Comprender lo que funciona para ti, será clave para ayudarte a progresar y crecer.
He encontrado que algunos principios sencillos funcionan mejor en mi caso. El primero es la repetición. Aprendo mejor cuando hago algo de manera diaria, una y otra vez, en pequeñas dosis. La segunda manera es teniendo una pequeña meta que pueda conseguir. Así que para mí tener una práctica diaria en un proyecto donde pueda trabajar y conseguir un objetivo es lo que mejor me funciona. Cuando estaba aprendiendo Python me uní a la PyWeek, una competición de una semana de duración de programación de un juego, donde el tema a tratar se anuncia al comienzo y toda la programación transcurre en una semana. Durante esa semana entera encontré tiempo para completar mi juego y al final de la semana había aprendido más sobre Pygame (la biblioteca que utilicé para mi juego) y Python que lo que había conseguido en semanas anteriores al PyWeek. Realizar una semana de duración de esta game jam (como lo llaman) es un poco extremista, pero me dio un objetivo claro (un juego funcional completo) y un tiempo dedicado para conseguirlo (una semana). Con el paso del tiempo he aprendido más sobre Python con varios proyectos (tanto profesionales como personales) que tenían una práctica diaria y objetivos claramente definidos.
Necesitarás experimentar para ver qué es lo que mejor funciona en tu caso. El principio que subyace es que el proceso de aprender debería ser algo que tu puedas utilizar para cualquier lenguaje o concepto en programación. También debe ofrecer la menor cantidad de resistencia a su aprendizaje. Tu capacidad para aprender y adaptarte será vital para tu experiencia como programador, así que entender tu propio proceso de aprendizaje y qué funciona mejor en tu caso te ayudará en este proceso.
Como mínimo, reserva 10 minutos al día para un contenedor (consulta el capítulo anterior) para una lectura y el aprendizaje enfocados. Hay mucho que aprender en programación y crear un hábito de aprendizaje te ayudará a mantenerte al día. Recuerda, sin embargo, mantener tu aprendizaje contenido en pequeños fragmentos. Mucha información puede abrumarte y hacerte pensar que no puedes aprenderlo todo. Tienes razón, no puedes aprenderlo todo de una sola vez. Si alguien te dijera que bebieras uno de los Grandes Lagos de una sola vez, sería difícil completar la tarea (nota: ¡no intentes esto!). Sin embargo, si llenaras un vaso de agua varias veces al día de uno de los Grandes Lagos y lo bebieras (10 minutos cada vez), comenzarías a hacer una mella apreciable en la reducción de ese lago a lo largo de tu vida. (Claro, puede que no parezca mucho desde el exterior, pero ese es el cruce donde la realidad y las metáforas se rompen).
Cada día tienes una oportunidad de aprender sobre más sobre ordenadores y su programación. Realizar una pequeña parte cada día para aprender un poco más, te ayudará en tu viaje.
Hay muchas oportunidades para aprender, ya sea mediante libros, tutoriales, vídeos o cursos a distancia con tu ordenador. También hay una gran variedad de temas sobre los que aprender. ¿Cómo decides qué es lo más importante para aprender? ¿Cómo gestionas lo que estás aprendiendo? ¿Cómo conseguir evitar sentirse abrumado con las opciones disponibles?
Esto nos vuelve al tema de centrarse en una cosa cada vez y entender cómo aprendes de una manera eficiente. Esta retroalimentación te ayudará a decidir qué será lo próximo a aprender. Una manera puede ser pensando en las cosas que más te apasionan ahora mismo, ¿qué te motiva en este momento? Si hay algo por lo que estás ansioso por aprender empieza por eso. Si tienes múltiples cosas que te apasionan o te interesan entonces colócalos en una lista y observa si estás más interesado en unos temas que en otros. Si aún tienes problemas para decidir de los temas de la lista entonces escoge uno al azar (lanza un dado o crea un generador de números aleatorios para seleccionar uno, eso podría ser en sí mismo un proyecto).
Si tienes problemas para pensar en algo para aprender y estás luchando para encontrar un elemento que te resulte interesante, entonces date permiso para navegar por la red y encontrar qué hay disponible. Observa las conversaciones de otros programadores y descubre de qué están hablando. Acude a una reunión de programadores para seguir las discusiones de lo que están hablando. O, si realmente estás atascado, explora algunas listas de ofertas de trabajos para averiguar qué es lo que buscan las personas que ofrecen trabajo y observa si algo de eso te despierta algún interés.
Esto no trata de escoger lo más útil o la cosa más importante, aunque tu situación actual puede hacer que algunos temas tengan más relevancia sobre otros, se trata de averiguar qué capta tu atención y dónde enfocarte. No te preocupes con realizar la elección perfecta que te proporcionará tu siguiente trabajo o impulsará tu carrera. Este ejercicio trata sobre hacer una elección para aprender algo interesante y que te enganche el tiempo suficiente para aprender más sobre ello.
Una vez que hayas escogido qué quieres aprender es el momento de centrarte en aprenderlo. Si tienes una metodología preferida (libros, vídeos, tutoriales, clases, etc) entonces dedica un tiempo (no más de una hora) a buscar qué recursos hay disponibles. Algunos temas tienen recursos disponibles para los principiantes que enumeran las cosas que la comunidad cree que son útiles para los programadores que están empezando, mientras que para otros puede ser necesario preguntar a la comunidad por dónde comenzar. A menudo algo tan simple como un tutorial puede ser una buena manera de comenzar con este ejercicio.
¡Si puedes encontrar algunos recursos en un corto periodo de tiempo será genial! Comienza tu proceso de aprendizaje con esos recursos. No te preocupes si son los recursos adecuados o quizás te lleven por un camino equivocado, simplemente comienza con ellos y ya los evaluarás más tarde. Por ahora es más interesante simplemente comenzar.
Una de las trampas en la que soy culpable de caer, es en tratar de encontrar los mejores recursos para aprender un tema. Paso horas buscando el libro perfecto, los vídeos adecuados, los cursos idóneos, lo que sea, trato de encontrar los mejores materiales disponibles. Quiero reducir la cantidad de comienzos en falso cuando aprendo de un tema. Esto que parece una una búsqueda correcta (después de todo, ¿por qué no ibas a querer los mejores materiales que haya disponibles?) es una trampa que puede llevarte a pasar más tiempo buscando sobre cómo estás aprendiendo en vez de estar ya aprendiendo. Incluso peor, si el material comienza a confundirte (lo que es altamente probable cuando estás aprendiendo algo nuevo) pasarás tu tiempo de aprendizaje pensando si escogiste la decisión adecuada escogiendo este material. Te preguntarás si escogiste el material idóneo y continuarás buscando el mejor material (quizás esas buenas y excelentes críticas realmente no sabían después de todo de lo que estaban hablando). Esto disminuye tu habilidad para aprende sobre el tema porque estás más enfocado en tratar de discernir la calidad de lo enseñado y no en dedicar tiempo en la enseñanza actual.
Después de unos días de sesiones prácticas date la oportunidad de comprobar y ver cómo estás aprendiendo. ¿Te sientes atraído o no estás disfrutando de esto? Si no te sientes atraído (el material no está organizado, el instructor es confuso, los ejemplos no funcionan, el material asume que ya estás familiarizado con otro tema, etc) entonces date permiso para buscar un material mejor o un tema diferente que te interese más. Incluso si la experiencia de aprendizaje no fue óptima, tendrás una mejor idea de lo que buscar cuando escojas algo nuevo. Tendrás un conocimiento de cuales son tus lagunas con este tema y tendrás un mejor conocimiento de lo que estás buscando en los materiales de aprendizaje.
Si encuentras que el tema que estás tratando de aprender ya no te interesa, date un momento para reflexionar sobre el motivo de esto. ¿Es un tema complicado? ¿Te sientes preparado para ese tema? ¿Estás actualmente sobrecargado con otros proyectos y te sientes cansado para abordar este tema? A veces creemos que estamos preparados para aprender sobre un tema, solo para darnos cuenta que hay algo más que necesitamos saber antes de poder entender por completo ese tema. Está bien buscar recursos adicionales y enfocarte en ellos antes de abordar este tema. Simplemente se consciente de tus luchas y tu diálogo interno. Se honesto contigo mismo sobre el motivo por el que quieres cambiar a algo diferente. Obsérvate en la dificultad y se consciente si estás queriendo huir porque es difícil o si realmente no estás preparado para ello o no estás interesado en este tema. Observa si puedes ahondar más con la dificultad y siente cuándo comienzas a sentirte sobrepasado por ella. Date permiso para apegarte a la dificultad tanto como puedas y presta atención a tus sentimientos e impulsos mientras practicas con ella.
Trata tu aprendizaje como un proceso iterativo, con periodos regulares en los que comprobar tu progreso. Piensa en cómo te sientes cuando estás aprendiendo. ¿Te sientes emocionado y comprometido o te sientes cansado y retraído? ¿Procrastinas cuando piensas en este tema? ¿Cuando te centras en tu aprendizaje tu mente divaga? Se consciente de estos sentimientos a medida que ocurren durante la sesión centrada y reflexiona sobre ellos cuando pienses en tu proceso de aprendizaje. Más tarde puedes reflexionar sobre estos sentimientos y ver los patrones en tu proceso de aprendizaje. Si te sientes cansado mientras estás aprendiendo podrías intentar cambiar cuando realizas tus sesiones de aprendizaje. Quizás necesites dormir más o necesites encontrar otros materiales que sean más estimulantes. Si te sientes abrumado quizás necesites empezar con algo más básico antes de afrontar este proyecto más difícil. Si estás confundido quizás haya alguien a quien puedas plantearle preguntas para obtener más claridad sobre el tema. Estas respuestas pueden no ser evidentes mientras estás en viviendo ese momento (quizás estás muy ocupado sintiéndote frustrado para entender de dónde viene esa frustración), pero con la práctica tendrás más recursos para observar tus sentimientos. Cuando eres consciente de estos sentimientos podrás usarlos para aprender cómo funciona tu mente y entender qué necesita para mantenerte comprometido con tu aprendizaje.
Cada vez que aprendemos cosas nuevas nos colocamos en un lugar vulnerable e incómodo. Tomamos las cosas con las que estamos familiarizados y las aplicamos a medida que nos adentramos en nuevos territorios. Nos volvemos inseguros con el resultado, ¿será un éxito o será un fracaso? ¿Será este tema difícil de aprender? ¿Nos ayudará o nos perjudicará? ¿Hemos escogido la opción equivocada para aprender y eso nos costará oportunidades a largo plazo?
La incomodidad y la incertidumbre son sin duda una parte del aprendizaje, pero en vez de pensar en ellas como algo a ser evitado pensemos en ellas como faros. Unas balizas que nos indica el camino y nos iluminan cuando estamos en territorios desconocidos. Cuando nos sentimos inseguros sobre lo que estamos haciendo, ese sentimiento significa que estamos entrando en un nuevo territorio. En vez de evitarlo o desear comodidad, podemos disfrutar por estar en un territorio desconocido y sentir esas breves punzadas de miedo y duda. Podemos decir: “Voy a aprender algo nuevo. Estoy asustado y no sé dónde me llevará esto, pero está bien. Estoy dispuesto a ver a dónde lleva esto y disfrutar del viaje.”
Estamos condicionados a pensar en lo desconocido como algo a lo que temer. Estas emociones nos han sido útiles. Nos han impedido aventurarnos demasiado de nuestra zona de confort y explorar lo desconocido. Cuando vives en un bosque o en cuevas, lo desconocido puede albergar todo tipo de peligros. Tiene sentido no provocar esos peligros apareciendo delante de sus puertas. Pero programar no es lo mismo que aventurarse en un bosque oscuro o asomarse a una cueva húmeda, programar apenas conlleva la cantidad de peligro que le otorgamos. En vez de eso, debemos darnos cuenta que no estamos en ningún peligro mortal. Nuestros miedos simplemente nos están haciendo saber que estamos aventurándonos en los territorios inexplorados de la ignorancia. Depende de nosotros dar a conocer a nuestros miedos que esto está bien y que al explorar estos territorios solo encontraremos conocimiento.
Steven Pressfield en La guerra del arte denominó a estos sentimientos como “Resistencia”. Considera la Resistencia como una especie de ser mitológico que vive en cada uno de nosotros para frustrar los actos creativos. A medida que el trabajo progresa la Resistencia aumenta la presión para detenernos introduciendo los sentimientos de miedo y ansiedad que he mencionado anteriormente. Pienso en la Resistencia como algo que también ocurre cuando estamos aprendiendo, especialmente si estamos aprendiendo sobre herramientas que nos ayudan en nuestras actividades creativas. Pressfield limitó su definición a las personas creativas que estaban trabajando para finalizar un trabajo creativo (libros, pinturas, juegos, etc.) pero yo estoy expandiendo su definición al propio proceso de aprendizaje. En nuestro caso la Resistencia aparece cuando estamos aprendiendo las herramientas que nos ayudarán a ser más creativos. La Resistencia es lo que nos dice que no somos suficientemente buenos para aprender esas cosas, o cuando estamos inseguros sobre los beneficios que nos acarreará. Trata de mantenernos seguros con lo que ya conocemos.
Este es el motivo por lo que el “contenedor focalizado” es tan importante: nos da pequeñas dosis de incomodidad y dificultad en porciones manejables. Podemos guiarnos a través de pequeñas cantidades de incomodidad diarias y seguir aprendiendo a pesar de nuestra incomodidad. Nos ayuda a trabajar a pesar de nuestra tendencia a evitar y ocultar situaciones difíciles. Si nos centramos en una sola cosa cada vez podemos mantenernos apartados de las distracciones sobre si esta es o no la cosa en la que deberíamos estar trabajando. Lo que sea en lo que estemos trabajando en este momento es exactamente en lo que deberíamos estar trabajando. Cualquiera que sea el material de aprendizaje que tengamos delante es lo que deberíamos estar aprendiendo. Podemos estar seguros de saber que todo lo que estamos haciendo durante la duración del contenedor es exactamente lo que debería de ser. Cuando finalice el contenedor podemos volver a evaluar cómo fue y qué retos se presentan por delante.
A medida que progresas en tu proceso de aprendizaje empezarás a ver que muchas de las cosas que llamamos programación están interconectadas. Los lenguajes de programación se prestan muchas cosas unos a otros y las ideas que parecían nuevas e innovadoras tienen sus raíces en conceptos que se remontan a los orígenes de la computación. En vez de disuadirnos, esto debería animarnos a abrir las puertas de la programación aprendiendo conceptos simples y transferibles. La pregunta es ¿cuales son?
La respuesta más simple es “todos ellos”, pero eso es difícil de satisfacer o imposible. Una respuesta menos descarada sería “los suficientes para empezar a ver cómo surgen patrones” pero eso suena más a una idea de perogrullo que a algo que podamos utilizar para comenzar a realizar nuestras metas a largo plazo para el aprendizaje.
En vez de darte un consejo específico sobre qué conceptos te serán más útiles en tu búsqueda de llegar a ser un programador mejor, voy a sugerirte una técnica que podría ayudarte a identificar lo que podría ayudarte.
Los lenguajes de programación mencionarán conceptos que comparten. Cada vez que estés aprendiendo y veas una mención a alguno de estos conceptos, haz una nota de ello y siguen enfocado en lo que estás aprendiendo ahora. Cuando hayas completado el periodo de aprendizaje diario, revisa la lista de estos otros conceptos y haz una búsqueda para ver qué muestran. Si hay otras cosas que aparecen entonces escríbelas en tu lista. Estos conceptos podrían no tener sentido en el momento pero tener una lista disponible y a los que se refieran podría ayudarte a hacer conexiones sobre programación que podrías no haber notado de otra manera.
Cuando aprendí JavaScript me dí cuenta que alguien mencionaba que JavaScript derivaba de otros lenguajes como Scheme. Scheme es un lenguaje funcional basado en Lisp y que fue creado como lenguaje de enseñanza para programación funcional y recursividad. Así que tomé un pequeño rodeo para aprender Scheme, personalmente porque me era más interesante que JavaScript. Llámalo “procrastinación activa”, si te sientes benévolo. Lo que aprendí mientras aprendí Scheme, motivó mi interés en otros lenguajes funcionales y la programación funcional. Esto a cambio me ayudó a entender algunos paradigmas de la programación funcional que se estaban convirtiendo muy populares en Python (listas de comprensiones, lambdas, etc). Al tomar un breve rodeo en mi aprendizaje de JavaScript aprendí más sobre toda una familia de lenguajes y ahora siento que entiendo JavaScript y Python con una mayor claridad que cuando empecé.
No estoy sugiriendo que todo el mundo debería seguir los pasos de la “procrastinación activa” como hice yo (mientras escribo esto, todavía estoy en el proceso de aprender JavaScript), pero ayuda el realizar notas de los conceptos que vas encontrando y ahondar un poco más en ellos.
Esta es una manera de trazar los objetivos del aprendizaje (darse cuenta de las otras conexiones que aparecen mientras estás aprendiendo y ser curioso sobre cómo interactúan entre ellas), pero quizás necesitas una técnica diferente. Quizás estás bajo presión para aprender algo que te mantenga en el mercado laboral o necesites adquirir algún conocimiento para tu trabajo que necesita ser aprendido rápidamente. ¿Cómo trazas esas metas?
La presión de aprender rápidamente puede hacer que cualquier tarea parezca insuperable, especialmente si no sabes cuál es la mejor manera de proceder. Es posible que sientas la tentación de apresurarte en este proceso y confiar en retener el conocimiento que has aprendido. Este enfoque no conduce a la comprensión, conduce al estrés y al agotamiento. El enfoque que estoy esbozando está diseñado para ayudarte a aprender cómo aprender. La mejor forma de aprender algo rápidamente es entender cómo encajan otros conceptos con lo que estás aprendiendo. Esto es genial cuando tienes experiencia con muchos lenguajes y conceptos diferentes, pero para aquellos que aún no tienen mucha experiencia, se sentirán como si estuvieran tratando de empujar un elefante a través de un pequeño embudo. Aquí es donde te ayudará practicar el aprendizaje todos los días. Te ayudará a dividir los objetivos de aprendizaje más grandes en partes más pequeñas y te ayudará a reconocer el miedo y la incomodidad por lo que realmente son: el reconocimiento de que estás expandiendo tus habilidades a un nuevo territorio.
Las metas a largo plazo son simplemente metas que deben ser divididas en metas a corto plazo. Enfocarse en metas a corto plazo y permitirte corregir el rumbo y seguir algunas conexiones cuando sea necesario.
Una de las cosas a las que tememos cuando estamos aprendiendo, es al fracaso. Nos preocupamos porque no aprender el tema rápidamente o al completo. Escogemos material que comienza de manera simple pero luego se vuelve muy complejo, y luchamos por mantener el ritmo. Intentamos escribir código de ejemplo en nuestros editores y nos encontramos necesitando ayuda para que funcionen. No logramos comprender el material y nos preguntamos si alguna vez aprenderemos lo que estamos tratando de aprender.
El fracaso es parte del aprendizaje. Si ya conocieras la materia no estarías aprendiendo.
Una de las razones para aprender practicando utilizando los contenedores, es porque así nos damos esos breves momentos de fracaso y repetición. La repetición es como mejoramos en cualquier cosa que estemos aprendiendo. El fracaso nos permite corregir el curso de nuestro aprendizaje para que podamos determinar la mejor manera de abordar esto la próxima vez que hagamos un intento.
A menudo sentimos que el fracaso es algo que debemos evitar, pero mientras estamos aprendiendo es inevitable. Nuestro proceso de aprendizaje requiere que fallemos para mejorar en lo que estamos aprendiendo. Ese es el objetivo del aprendizaje: volver a moldear nuestros cerebros para que finalmente puedan comprender los conceptos que estamos tratando de aprender.
Parte del aprendizaje es tener la mentalidad correcta para aprender. En lugar de sentir que estás constantemente fallando y luchando por mantenerte al día, es posible que desees abordarlo con una perspectiva diferente. En lugar de pensar “No puedo hacer esto. Es demasiado difícil”, acércate a ello con una mirada más curiosa “Todo esto es nuevo para mí. Es por eso que estoy practicando para aprender esto”. Darte una mentalidad más positiva te ayudará a evitar que te rindas cuando tengas problemas con el material.
A veces nos encontraremos a nosotros mismos aprendiendo algo que es un callejón sin salida. Observamos nuestro progreso y no vemos una mejora real. No encontramos el tema tan atractivo o excitante como habíamos imaginado. Nos damos cuenta que lo que estamos aprendiendo es un callejón sin salida evolutivo en el campo de la programación. ¿Ahora qué?
Parte de nuestro proceso de aprendizaje es entender que nuestras expectativas sobre cómo algo evolucionará pueden ser completamente diferentes a cómo las cosas evolucionan de verdad. Visionamos toda clase de recompensas y clichés que nunca llegan. ¿Significa eso que estamos en un callejón sin salida? Yo creo que no. Podría suceder que lo que esperábamos que íbamos a hacer con nuestro recién adquirido conocimiento no está funcionando. Podríamos encontrar que nuestras expectativas sobre lo rápido que íbamos a aprender el tema no se están cumpliendo. También incluso podríamos esperar que nuestra carrera profesional se iba a ver respaldada por el tema de aprendizaje, pero el mercado de trabajo aún no ha reconocido nuestras recién adquiridas habilidades con ofertas de trabajo o más dinero.
Nuestro compromiso está relacionado con nuestras expectativas. La programación requiere una cierta cantidad de diversión y recompensa y si no encontramos la experiencia divertida y gratificante entonces es poco probable que queramos continuando seguir aprendiendo sobre ese tema. Nuestras mentes están esperando algo más que nos atraiga y comenzamos a anhelar cualquier otra cosa en vez de continuar con el proceso de aprendizaje. Después de todo ¿no deberíamos estar disfrutando de esto? Si no hay compromiso y no disfrutamos, entonces el aprendizaje se convierte en una losa. Nos distraemos más fácilmente mientras estamos intentando aprender y nuestras mentes se dispersan en vez de enfocarse en nuestra experiencia de aprendizaje.
También está el problema de aprender sobre temas que son callejones sin salida evolutivos. El mundo de la informática está lleno de restos de tecnologías y metodologías que ya no son relevantes o están consideradas “pasadas de moda”. Lo que una vez fue algo vanguardista ahora está considerado moribundo y la comunidad creada alrededor de esa tecnología o metodología se pasa a nuevas tecnologías o metodologías y abandona su trabajo previo como un pueblo fantasma tecnológico. Cuando mencionamos que estamos aprendiendo sobre esos temas, caen sobre nosotros miradas curiosas de otros desarrolladores: “¿Por qué aprender sobre eso? Hemos cambiado a esta otra cosa”. Es como si hubiéramos oído que hay una fiesta y cuando llegamos a la fiesta, solo vemos a las personas que están recogiendo la basura y desmontando la mesa y las sillas. Nos sentimos como si nos hubiéramos perdido la mejor parte y nos preguntamos si tiene sentido seguir hacia adelante o encontrar otro tema.
Todo esto puede plantear sus propios problemas para aprender, pero depende de nosotros tener una visión más crítica de por qué empezamos todo este proceso de aprendizaje. ¿Qué nos trajo hasta aquí?
En cada uno de estos casos trajimos nuestras expectativas de cómo progresaría el aprendizaje. Trajimos la expectativa de que siempre sería divertido, atractivo y relevante. A veces nuestras expectativas de aprendizaje se cumplen, pero cuando no lo hacen nos sentimos sin ánimos y decepcionados.
En vez de sentirnos incómodos sobre cómo nuestras expectativas de aprendizaje con esta tecnología o metodología no se están cumpliendo, podemos adoptar un enfoque más consciente. Nos podemos observar a nosotros mismos en nuestros momentos de aprendizaje y notar si estamos tratando de aportar más que únicamente una atención focalizada al contenedor de aprendizaje. Podemos ser conscientes de que aprender está relacionado con cambiarnos a nosotros mismos y el cambio no siempre es divertido, atrayente o placentero. Podemos dejar a un lado nuestras expectativas y concentrarnos en el propio aprendizaje.
Eso no significa que no debamos ser conscientes de nuestros sentimientos. Sin duda deberíamos reconocer sentimientos como aburrimiento, ansiedad, desilusión, etc. Pero también deberíamos ser conscientes de dónde se originan esos sentimientos. ¿Estamos realmente aburridos o es solo nuestra mente tratando de decir que debemos parar para así poder hacer algo más divertido? ¿No nos apasiona este material porque no lo encontramos relevante o nos estamos simplemente distrayendo? ¿Es esto realmente un callejón sin salida en nuestro aprendizaje o simplemente nos estamos sintiendo atascados? Identifica cuándo aparece el sentimiento y se curioso sobre lo que originó el sentimiento. Nota cuándo obtienes ese sentimiento y dónde lo sientes más en tu cuerpo. Permanece con ese sentimiento durante unos segundos y sigue sintiéndolo. Después, continua tu trabajo. Mientra estás trabajando sigue notando todos esos sentimientos que estás teniendo y repite el proceso de permanecer y notar tus sentimientos. Cuando acabes puedes reflexionar más sobre esos sentimientos y determinar qué indican esos sentimientos. A través de este proceso puedes determinar qué está causando estos sentimientos y notar si son solo una resistencia a aprender nuevo material o un deseo de escaparse a las distracciones o a algo más familiar.
Sin embargo, si te das cuenta que realmente no estás disfrutando mientras estás aprendiendo sobre ese tema, si sientes que estás invirtiendo más tiempo en auto convencerte de aprender que realmente aprender, entonces necesitarás tener una discusión honesta contigo mismo sobre porque estás aprendiendo sobre este tema. ¿Es el tema todavía relevante para ti o el tema se ha vuelto irrelevante? ¿Estás aprendiendo sobre esto por una obligación auto impuesta o impuesta por otras personas y esa obligación todavía está presente? ¿Estás tratando de aprender lo que sea porque estás preocupado por quedarte desfasado personal o profesionalmente? Reflexiona sobre lo que te indujo a comenzar a aprender sobre ese tema y determina si la situación ha cambiado. Si alguien se te acercara y te preguntara si te gustaría aprender sobre ese tema en los próximos días ¿lo considerarías?
Necesitarás reconsiderar tus verdaderas motivaciones para aprender sobre el tema y ver si todavía encajan con lo que quieres hacer con tu profesión como programador. También necesitas ser honesto contigo mismo sobre el motivo por el que estás aprendiendo este tema y por qué es importante para ti. Hay muchas cosas para aprender que son grandes salidas profesionales, pero si no tienes interés sobre el tema o solo estás aprendiendo “para que te contraten”, entonces tendrás más dificultades para aprender el tema que si lo hubieras escogido por un interés genuino por él. También tendrás que determinar si esto es simplemente una resistencia al aprendizaje. Tu reto será determinar tus verdaderos sentimientos sobre el tema y descubrir si verdaderamente has perdido el interés o simplemente estás luchando contra él.
Ha habido muchos temas en mi carrera profesional que he tratado de aprender, pero han sido muchos más sobre los que no he aprendido. Parte de los motivos por los que no los he aprendido es porque el panorama informático cambió mientras los estaba aprendiendo. En la escuela aprendí el lenguaje Pascal. Era razonablemente bueno en ello, pero con el tiempo mis conocimientos de Pascal fueron desapareciendo. Ahora mismo existe una escasa demanda de programadores competentes de Pascal, así que haber continuado desarrollando mis conocimientos de Pascal hubiera sido simplemente para mi propio disfrute. Encuentro que hay otros temas relacionados con la informática más interesantes, así que mis conocimientos sobre Pascal permanecen inactivos. Si Pascal emergiera de su estado moribundo, podría volver a retomar la decisión de reforzar mis conocimientos sobre Pascal, pero por ahora estoy contento por haber tomado la decisión correcta. En un punto de mi carrera profesional el lenguaje Java saltó a la fama. Pasé muchas sesiones aprendiendo Java hasta que me dí cuenta que no me gustaba el lenguaje. Me pareció muy engorroso y las direcciones que tomó no fueron las que quería seguir. Así que después de algunas reflexiones abandoné el aprendizaje de Java. ¿Fue todo esto tiempo perdido? Durante mis sesiones aprendí más sobre la Programación Orientada a Objetos y cómo los objetos encajan entre ellos. Aprendí más sobre recursividad mientras estaba tratando de resolver un problema para uno de mis proyectos. Estos conocimientos trascienden a Java, así que cuando empecé con Python fui capaz de transferir mis conocimientos sobre cómo funcionan los objetos de Java a Pytnon. Utilicé ese conocimiento para entender qué estaba haciendo Python y cómo era de diferente respecto a Java. Si surge la necesidad puedo repensar mi decisión de dejar de aprender Java y ver si esto me interesa otra vez.
Está bien renunciar a aprender algo. Depende de ti determinar qué quieres aprender y durante cuanto tiempo. Somos seres complejos y nuestros intereses se transforman y cambian. También estamos en una industria compleja de caprichos y tecnologías cambiantes. Lo que era interesante y necesario al comienzo del año, podría convertirse en algo carente de interés o innecesario al final del año. No debemos sentirnos presionados para aprender sobre algo solo porque otras personas lo estén aprendiendo o porque el mercado de trabajo parezca que lo requiera. Date permiso para escuchar tus propios deseos. Si estos coinciden con lo que quiere esta industria voluble ¡entonces genial! Ve y aprende todo lo que puedas. Pero si no coinciden y te encuentras a ti mismo pasando semanas tratando de encontrar la motivación necesaria para aprender sobre el tema, entonces estás haciendo un flaco favor tanto a ti mismo como a tu oficio. Deja que el tema repose inactivo durante un tiempo y date tiempo para aprender sobre otra cosa. No tiene mucho sentido el sentirte miserable por complacer a otras personas.
Si sientes la necesidad de retomar el tema más adelante entonces permítete el regresar de nuevo a él. También deberías permitirte regresar a ese tema sin el bagaje y las expectativas de los intentos anteriores. El decir “ya intenté esto antes, así que veamos si funciona esta vez” pone a tu mente a la expectativa de que volver a abandonar de nuevo. Date permiso para acercarte a este tema como si estuvieras experimentando la experiencia por primera vez, sin expectativas sobre cómo resultará. Se amable contigo mismo y experimenta el tema de nuevo pero desde tu perspectiva actual.
Cuando eramos principiantes nos acercamos a las computadoras con curiosidad y entusiasmo. No sabíamos qué esperar y no teníamos ni idea del tiempo que iba a llevar. Simplemente aprendimos tanto como pudimos y tomamos todo al pie de la letra. A medida que continuamos aprendiendo cambiamos nuestra curiosidad por certezas y nuestro entusiasmo por expectativas. La emoción que sentíamos al aprender se convirtió en un sentimiento de monotonía al sentir que siempre deberíamos estar aprendiendo. Podemos volver a capturar aquel espíritu del principiante viendo cada oportunidad de aprender como una nueva experiencia. Podemos dejar de lado nuestras expectativas sobre cómo progresará nuestro aprendizaje y en vez de eso acercarnos a cada sesión de aprendizaje con curiosidad por lo que aprenderemos durante la sesión. Podemos reavivar la llama que teníamos cuando eramos principiantes con infinitas posibilidades. Esa llama nos guiará cuando atravesemos periodos de incertidumbre.
Podemos volver a sentir pasión por aprender. Con cada contenedor de enfoque podemos acercarnos a nuestro aprendizaje de una manera fresca, sin nociones preconcebidas de cómo y cuándo acabará, y ser curiosos por aquello que encontraremos cuando ahondemos más y más en lo que estamos aprendiendo. Cada sesión nos acerca un paso más en nuestro viaje por cerrar las lagunas de conocimiento. Hay mucho que explorar en nuestro campo. Espero que siempre encuentres algo nuevo y excitante que te ayude en tu viaje.
Existe el estereotipo del programador sin emociones sentado frente a su equipo. El programador estereotipo se sienta, introduce líneas de código de manera silenciosa, como si las transcribiera desde su memoria. Si eres programador o has tenido contacto con programadores entonces deberías saber que el estereotipo debería ser el de un compositor frustrado. Por supuesto, nos sentamos delante de nuestros ordenadores en largos periodos en silencio y concentrados, pero estamos muy lejos de no tener emociones. Disfrutamos de las glorias de un código que funciona a la perfección la primera vez. Fruncimos el ceño cuando el código funciona mal. Pasamos de alegrarnos por la victoria a maldecir y amenazar a la máquina con los puños apretados. Apretamos nuestros dientes cuando los errores del código asoman. Pasamos de una emoción a otra: exuberancia, alegría, miedo, furia, resentimiento, tristeza, soledad, culpa o vergüenza.
No es extraño que al final del día estemos exhaustos.
Programar es un proceso agotador. No solo necesitamos mantener un modelo mental del software en el que estamos trabajando, también tenemos que mantener un modelo mental de cómo se debería comportar el software. Creamos una historia de cómo funcionará este software y componemos una imagen mental de cómo nos sentiremos cuando todo funcione como hemos lo hemos imaginado. Creamos un vínculo emocional con el software. Nuestro estado emocional puede reflejar lo que sentimos cuando estamos creando: excitados, aburridos o estancados. Mantener una actitud positiva respecto al software que no está a la altura de nuestras expectativas es agotador. Esto combinado con nuestras propias inseguridades, miedos y dudas nos da indicios cuando vemos que los programadores tienden a agotarse: es una combinación de estrés y nuestra reacción emocional a ese estrés.
Hay muchos factores que pueden causarnos altibajos emocionales mientras estamos programando. Estos son algunos que he anotado, tanto en mi propio proceso de programación como hablando con otras personas sobre su programación.
Si vemos con claridad dónde y cómo este código será útil, podemos tener una idea de la motivación y el propósito. ¡Estamos trabajando en algo que beneficiará a personas! Sabemos que las personas dependen de nosotros, así que hacemos todo lo que este en nuestra mano para hacer que el código funcione sin importar las trampas que nos esperen. Aprovechamos los picos emocionales de autoestima y determinación para ayudarnos a llegar a la culminación.
Lo opuesto también es cierto, por supuesto si no vemos el propósito entonces nuestro trabajo parecerá sin sentido y en vano. Nos esforzaremos para cumplir los plazos y sentiremos una sensación de vacío en nuestros objetivos. A veces se trata de un proyecto que no está en consonancia con nuestros propios propósitos y metas. Puede tratarse de un proyecto mal gestionado en el que estamos forzados a trabajar debido a presiones externas. Podríamos vernos obligados a cumplir plazos arbitrarios que nunca acordamos cumplir. Podemos sentirnos frustrados si no entendemos el fin último de cualquier proyecto en el que estemos trabajando.
Ya hemos experimentado diferentes capas de motivación con nuestra programación. Esos son los proyectos en los que no sentimos que sean una tarea mientras estamos trabajando en ellos. Sentimos que estamos aprendiendo algo en cada paso del camino. El mundo exterior desaparece mientras estamos trabajando inmersos por completo en ese enfoque. Perdemos la noción del tiempo y nos sentimos tanto desorientados como renovados cuando el trabajo está completo.
Desafortunadamente lo más probable es que tengamos más experiencias con lo opuesto a la motivación: el aburrimiento. El código base no nos motiva en absoluto. El tema que estamos aprendiendo o en el que estamos trabajando es simplemente una repetición de algo que ya sabíamos. Es un suplicio comenzar. Todo lo que nos rodea en el mundo parece más interesante y el tiempo parece ir más despacio durante todo el proceso.
El sueño es un factor que influye mucho en cómo percibimos el mundo. Dormir lo suficiente nos permite sentirnos renovados, despiertos e inspirados. Necesitamos tener reservas de energía para enfrentarnos a cualquier reto que se nos presente. Cuando no tenemos una calidad óptima del sueño nos volvemos irritables y menos dispuestos a la participación. Conservamos nuestros recursos lo mejor que podemos para que no se gasten demasiado rápido. Buscamos estimulantes (café, distracciones y similares) para mantenernos ocupados a lo largo del día.
Uso el término “estado mental” en un sentido amplio para cubrir cualquiera de nuestros sentimientos existentes y de bienestar mental actual. Estos pueden variar desde sentimientos temporales de infelicidad o melancolía a sentimientos complejos y serios como la depresión clínica o trastorno de estrés postraumático. Nuestras mentes son máquinas complejas que hacen lo que pueden para adaptarse a las diferentes situaciones y entornos que se les presentan. En ocasiones esta adaptación puede chocar con nuestros deseos de ser productivos y la lucha que se produce entre nuestro estado mental y nuestros deseos puede causar más desgaste emocional, incomodidad o desesperación.
Hay más motivos que pueden afectar a nuestras emociones pero estos son en los que me gustaría centrarme ya que cubren un amplio espectro de lo que acarrea dedicarnos a las tareas de aprendizaje y programación.
Ser conscientes de nuestro estado emocional (lo que estamos sintiendo ahora mismo) nos da nuestra ubicación emocional actual. Podemos ubicarnos dónde estamos y entender lo que nuestra mente nos está diciendo. El darnos unos instantes para sentir verdaderamente en qué estado emocional se encuentra nuestra mente nos ayudará a seguir adelante.
Ten en cuenta que no estamos tratando de cambiar nuestro estado emocional. No nos estamos intentando forzar a ser algo que no somos. Si realmente estamos insatisfechos sobre dónde estamos o lo que estamos haciendo, es más útil entender qué está causando esa infelicidad en vez de tratar de disimular y prevenir esas emociones. Observar nuestras emociones de manera clara nos permite reconocer qué las está causando. Estar presente con esas emociones nos permite entender mejor nuestro estado mental y de lo que somos capaces en el momento.
Puedes realizar esto dentro de un contexto de meditación de atención plena, incluso mientras estás sentado en tu escritorio pensar: “durante uno o dos minutos voy a estar sentado aquí y voy a explorar mi estado emocional” debería ser suficiente. Ser conscientes de nuestras emociones, entender qué son y profundizar en ellas hasta encontrar qué las está causando puede ayudarnos a entender qué estamos sintiendo.
Quizás ya sabes qué está causando esas emociones y ese estado mental y tienes miedo de explorarlas. Algunas emociones pueden sobrepasarnos y hacernos sentir de formas que no queremos sentirnos. Esto es especialmente cierto con emociones relacionadas con la ansiedad y el trastorno de estrés postraumático. Realiza toda la exploración e introspección que seas capaz, y se amable contigo mismo. Recuerda, no estás tratando de cambiar las emociones, solo estás siendo consciente de ellas. Es posible que descubras que tu insistencia amable en estas emociones pueda llevarte a entenderlas mejor. Se tan osado como puedas con estas emociones y si empiezan a abrumarte, entonces retrocede y deja que desaparezcan los residuos de esas emociones antes de continuar.
Cada uno de nosotros tenemos una historia que nos contamos a nosotros mismos. Estas historias conforman nuestra percepción del mundo. Nos contamos historias de cómo transcurrirá el día y cómo nos enfrentaremos a el. Creamos un mundo a través de nuestras historias en el que somos el protagonista central de la historia. Nos contamos historias como “el trabajo que voy a comenzar será increíble” o “voy a trabajar en este problema y cuando termine obtendré una solución genial”. Eso ocurre si estamos siendo positivos con nosotros mismos. Cuando estamos siendo negativos, nuestras historias tratan sobre que no somos lo suficientemente buenos en lo que estamos haciendo y que seguramente fallarás en el intento. Estas historias crean una trama compleja de lucha, dolor y miseria donde todo lo malo del mundo es el resultado directo de nuestras acciones.
Nuestras emociones ayudan a dar forma al tipo de historia que contamos. Si nos sentimos muy bien, nos diremos a nosotros mismos que lo que está por venir también será genial. Si nos sentimos deprimidos y derrotados, nuestras historias reflejarán ese tono derrotado.
La verdad es que nuestra historia es simplemente eso: una historia. Nuestras historias no son una garantía de cómo va a transcurrir el día. Podemos contarnos una historia sobre que hoy será un día increíble y ver con horror que cada interacción hace que nuestro día sea de todo menos increíble. Por el contrario, nuestra historia podría ser que hoy será un día terrible y que no conseguiremos nada, pero en vez de eso experimentamos un día muy completo y productivo. La historia solo acentúa lo que estamos experimentando, pero no puede predecir lo que experimentaremos.
En vez de apegarnos a estas grandes historias podemos centrarnos más en las cosas que amamos del momento presente. En vez de una historia en la que vas a tener un día excepcional podrías centrarte en aspectos de tu proyecto que te atraigan y esperar en que puedas pronto trabajar en ellos. En vez de llenar tu día con historias de terror y fatalidad te puedes centrar en las pequeñas victorias que ocurren a lo largo del día. Incluso algo tan simple como “mi ordenador ha arrancado sin fallar” puede ser una victoria. Una de esas pequeñas victorias podría ser el establecer una intención en permanecer centrados y curiosos en los próximos 10 minutos (el contenedor de enfoque de los capítulos anteriores) y celebrarlos cuando logres esa intención. Puedes tener más pequeñas victorias si te mantienes trabajando con esa intencionalidad a lo largo del día. Nuestras pequeñas victorias no serán perfectas (quizás tu ordenador está hoy insoportable), pero podemos usarlas para recalibrar nuestro día en los próximos 10 minutos y seguir usándolas para recalibrar durante todo el día, como cada contenedor focalizado se convierte en otra pequeña victoria.
Darnos a nosotros mismos la capacidad de centrarnos más en el presente y los próximos pasos que estamos a punto de dar nos brinda una forma consciente de comprobarnos a nosotros mismos y nuestro progreso. Podemos centrarnos en los aspectos positivos de lo que estamos haciendo en vez de preocuparnos sobre cómo la realidad difiere de nuestras propias historias. Podemos corregir el rumbo a lo largo del día y mantener la tendencia hacia un día más positivo y productivo en vez de preocuparnos sobre lo distantes que nos encontramos de nuestro día ideal.
Esto requerirá práctica. Estamos acostumbrados a permitir que nuestras historias dirijan nuestro día, pero con el paso del tiempo seremos capaces de dividir nuestro días en partes más pequeñas donde podamos ser plenamente conscientes de las historias que nos contamos a nosotros mismos.
Vamos a suponer por un momento que es un día normal para nosotros. Hoy nos sentimos ansiosos. Hemos recibido un informe de un error que está relacionado con algo en lo que hemos estado trabajando. En informe de error indica que el código que enviamos al proyecto a principios de año no está funcionando y quizás nunca funcionó de la manera que pensamos que funcionaba. Mientras leemos el informe de error nuestros niveles de ansiedad se incrementan. Nuestro monólogo interior entra en acción y empezamos a decirnos a nosotros mismos que nunca hemos estado cerca de ser tan buenos como creíamos. No somos perfectos. Apestamos. No hemos dormido la suficiente la noche anterior así que nuestras emociones están a flor de piel. Nuestra mente se acelera y proyecta imágenes pasadas de otras veces donde también cometimos fallos. Mientras seguimos leyendo aflora nuestra sensación de temor. Nuestro monólogo interno se convierte en una charla frenética: “¿Qué van a pensar ahora de mí? ¿Qué piensan de mí ahora mismo? ¿Perderé mi trabajo por esto?
Antes de que hayamos acabado de leer el informe de error ya hemos creado una historia. La historia comienza con nuestra propia ansiedad por lo que pasará a lo largo del día. Entonces ocurre lo peor: obtenemos algo que confirma nuestros miedos. La historias después nos presenta con un montaje de nuestros fallos pasados y a eso añade este último informe de error como punto culminante del montaje. Nuestra historia entonces aumenta la presión por el aumento de la importancia de este informe de error: no solo debemos solucionar lo que sea que esté roto, ahora tendremos que limpiar nuestra reputación y comenzar a buscar trabajo. A medida que la historia progresa en nuestras mentes, nos preguntamos si volveremos a trabajar como programador de nuevo y sentimos cómo nuestra carrera profesional como programador está acabada.
La historia que hemos creado es una historia terrible, pero estoy seguro que te ves identificado con los factores que genera. Es una historia que se basa en lo más profundo de nuestros propios sentimientos de insuficiencia e inseguridad. Está alimentado por el miedo: el miedo a arruinar tu reputación, miedo a que no confíen en ti y miedo al fracaso.
El miedo es una de las emociones más poderosas que tenemos, pero no es la única. Leer ese informe de error también puede hacer surgir otras emociones como el dolor (pensamos que el código era bueno y ahora ese sentimiento se ha esfumado). Incertidumbre (¿cómo vamos a solucionar el problema?) y la ira (¿cómo hemos podido habernos engañado pesando que esto funcionaba?) También podemos tener otros sentimientos: tristeza, soledad y abandono. Nuestra autoestima podría verse afectada y podríamos sentirnos desconectados de aquellas personas para las que trabajamos y las personas con las que trabajamos.
Estar al tanto de estos sentimientos puede ayudarnos a analizar la historia que nos estamos contando y cómo no coincidía con la realidad. Estos sentimientos y la historia que nos contamos nos dan una retroalimentación de cómo percibimos el mundo y el mundo que estamos construyendo. Hacer una pausa por un momento para reconocer nuestros sentimientos y entender de donde proceden nos da un entendimiento de lo que nuestras emociones están tratando de decirnos.
Ahora te puedes relajar. El informe de error de este libro no es real, pero tómate un momento para reconocer los sentimientos que sientes cuando lees la sección anterior y nota dónde ha ido tu mente. Este es el tipo de conciencia que estamos buscando tener.
Nuestros sentimientos se manifiestan en nuestros cuerpos de muchas maneras diferentes. El miedo puede sentirse como un nudo en el estómago o una tensión en nuestro pecho. La ira puede hacer que apretemos las mandíbulas o sentir nuestra cabeza más caliente de lo normal. La tristeza la podemos sentir como un peso sobre nuestros hombros o hacernos sentir cansados. Cuando notamos estos sentimientos podemos hacer una pausa por un momento y simplemente sentarnos con nuestros sentimientos mientras lo seguimos sintiendo.
Piensa en este ejercicio como si estuvieras escaneando tu cuerpo en busca de la fuente de los sentimientos que estás sintiendo. Fíjate hacia donde es atraída tu mente: opresión en el pecho, una opresión en tu estómago, las mandíbulas apretadas o cualquier otro sentimiento que estés sintiendo. Nota la sensación de ese sentimiento. Puedes ahondar más y tratar de encontrar la causa primigenia del sentimiento pero por ahora simplemente siente que existe. Siéntate por un momento y se más curioso sobre cómo te sientes. Trata de notar otros atributos de ese sentimiento: color, textura, intensidad o cualquier otro atributo que estés experimentando. Deja que ese sentimiento exista, se amable con el. Permite que exista sin juzgarlo. Dale espacio. Sobre todo no trates de luchar contra el sentimiento o desees que termine, simplemente siéntelo. De manera eventual puede que el sentimiento vaya disminuyendo, pero por ahora solo ten conciencia de que tienes ese sentimiento y que vas a ser curioso sobre él.
Algunos sentimientos y emociones son más dolorosas o traumáticas que otras. Dales espacio y permítete tener curiosidad sobre ellas mientras puedas. Si notas que tu mente empieza a sentir pánico u otra sensación que te desborde debido a este sentimiento, entonces deberías dejar de notarlos antes de que te superen. Recuerda que esto son emociones y que esas emociones son parte de ti. Tanto tu como tus emociones trabajáis juntos para ayudarte. Ambos estáis en el mismo equipo.
Con este ejercicio no se trata de que te acoses o te castigues con tus propios sentimientos. Es solo el acto de notar que estos sentimientos te causan un dolor físico o emocional, es posible que necesites ayuda profesional o un grupo de apoyo para guiarte a entender estos sentimientos y descubrir de dónde vienen. La ayuda profesional o el grupo de apoyo pueden ayudarte a tener estos sentimientos sin que estos te sobrepasen. No debe provocarte vergüenza el buscar ayuda en otras personas para que te ayuden en tu viaje.
Uno de nuestros comportamientos aprendidos respecto de nuestros sentimientos es tratar de huir de ellos o de reprimirlos. Hacemos todo lo posible para evitar sentimientos que nos provocan infelicidad o incomodidad. También tratamos de no exagerar nuestros sentimientos positivos para no mostrar demasiada exuberancia. Esto nos puede llevar a sentirnos confusos o en conflicto sobre qué estamos sintiendo y por qué nos sentimos de esa manera. Al sentarnos con nuestros sentimientos y emociones y entendiendo de dónde proceden podemos formarnos una idea clara de qué está pensando nuestra mente y la historia que nos estamos contando a nosotros mismos.
Piensa en esta práctica como una separación y clasificación emocional. Con suerte nunca has tenido que acudir a una sala de emergencias de un hospital, pero si lo has hecho, verías a todo el personal médico que están entrenados en diagnosticar a quien acaba de entrar por la puerta y determinar la gravedad del problema. Cuando reconocemos y reflexionamos sobre nuestras emociones también estamos diagnosticando qué emociones estamos teniendo y la gravedad de esas emociones. Tomamos esos momentos cuando estamos experimentando las emociones para poder determinar qué emociones son y qué las ha desencadenado. Mientras revisamos nuestras emociones somos cordiales con ellas y las reconocemos por lo que son. Un buen profesional médico no impone sus propios deseos al paciente, simplemente aceptan a los pacientes por lo que son, diagnostica lo que está experimentando el paciente y actúa en consecuencia. Cuando reconocemos nuestras emociones por lo que son y determinamos de dónde proceden, podemos comprender mejor a lo que nos estamos enfrentando.
Cuanto más hagamos esta práctica, mucho mejor seremos capaces de reconocer nuestras emociones y por qué las estamos teniendo. Seremos más capaces de notar qué estamos sintiendo y entender el motivo de estar sintiéndonos de esa manera. Cuando sentimos ansiedad, podemos reconocer que podría ser causada por explorar un área de programación que no entendemos por completo. Podemos sentir esa ansiedad durante un instante (no trates de ahuyentarla) y en ese momento piensa sobre lo que estás trabajando y cómo poder explorar esas áreas que son nuevas. Podemos tomar una nota mental o escrita (mejor si es en un diario) así cuando completemos lo que estamos realizando, podremos revisar las áreas que nos están causando ansiedad.
Esta práctica puede convertir nuestras emociones en algo que nos dirija o guíe. Podemos utilizar nuestras emociones como herramientas para calibrar mejor nuestras historias internas. Podemos recomponer esas historias sobre cómo no nos merecemos que nos llamen programadores y en vez de eso darnos la intención de que pasaremos los próximos 10 minutos explorando este área de nuestro trabajo y encontrar dónde están las lagunas de conocimiento. Podemos establecer una intención de ser curiosos sobre a dónde nos llevarán los próximos 10 minutos de exploración. Mientras continuamos explorando ese tema notaremos nuestras emociones y usaremos esas emociones para permitirnos conocer dónde necesitamos mejorar y adaptarnos. Esto nos permitirá cambiar nuestros planes cuando sea necesario y abordar aquellas áreas donde creamos que tenemos carencias o necesitan mejorar. Este ciclo continúa en cada contenedor que practiquemos, con nuestras emociones actuando como un barómetro de nuestro nivel de comodidad con el tema en cuestión y ayudándonos a esbozar una hoja de ruta sobre la mejor manera de proceder. Transformamos nuestra incomodidad y ansiedad de cosas que obstaculizan nuestro progreso en indicadores de dónde sentimos que tenemos que enfocar nuestra atención.
Una de las cosas que nuestra separación emocional puede ayudarnos a diagnosticar es el sentimiento de agotamiento. El agotamiento es un compendio de emociones unidas a una extenuación emocional y física. El agotamiento puede ser algo simple como estar cansado o tener exceso de trabajo, pero también puede ser un signo de algo más serio. Puede llevar a complicaciones físicas o mentales si no tenemos cuidado. Podemos trabajar con preocupantes niveles de extenuación y engañarnos a nosotros mismos creyendo que esto es parte del coste por ser un buen programador.
El agotamiento se manifiesta de diferentes maneras. Para algunas personas puede ser un sentimiento de pavor mientras trabaja en un proyecto. Se sienten como si no fueran efectivos al hacer cualquier cambio. Para otras personas el agotamiento puede ser un sentimiento de extenuación. Se sienten como si estuvieran en una rueda de hamster que no parará nunca. Incluso puede ser mucho peor, quieren que la rueda se hubiera parado hace ya mucho tiempo. El agotamiento también puede manifestarse en una sequía creativa, donde imaginar un futuro diferente es difícil y las cosas que una vez fueron inspiradoras o interesantes ya hace tiempo que no generan esa chispa.
El agotamiento es complicado de auto diagnosticar debido a que es un conjunto de emociones aparentemente no relacionadas entre sí. Nuestro sentimientos de aburrimiento, miedo y ansiedad pueden tener todos una causa raíz diferente, pero cuando combinamos estos sentimientos con un horario de trabajo implacable y la pérdida de control, amplificamos esos sentimientos. Si no los controlamos, nos pueden llevar a tratar de silenciar o dormir esos sentimientos. Nos encontraremos con que no queremos programar nunca más y nos enfadaremos con nosotros mismos por habernos metido en la programación. Podemos causarnos más sufrimiento no deseado simplemente “superándolo”, lo que puede llevarnos a agravar y complicar aún más nuestro estado emocional.
Hay algunas cosas que podemos hacer para entender y ayudar a aliviar ese agotamiento:
Al entender que estamos dirigiéndonos hacia el agotamiento (o que ya estamos en él) podemos tomar medidas para corregir el rumbo, para poder así realizar nuestra programación disfrutando y con alegría. A veces dar un paso atrás y volver a evaluar lo que estamos haciendo nos puede ayudar a no instalarnos en bucles constantes de frustración, ira y culpa. Cambiar nuestra historia para que se ajuste mejor a la realidad puede evitar que intentemos alcanzar un sueño imposible.
Antes mencioné la posibilidad de volver a negociar los compromisos. A menudo estamos involucrados en situaciones donde tenemos muchas más tareas que hacer que lo que es físicamente posible, incluso bajo las circunstancias más óptimas. Esto puede ser causado en parte porque hemos dicho “sí” a demasiadas cosas, o porque estamos abrumados por compromisos laborales, como un importante proyecto de alta prioridad o varios proyectos más pequeños que necesitan atención urgente. La mejor manera de volver a negociar tu carga de trabajo es revisando esa carga de trabajo y anotar qué tareas son “urgentes” y qué tareas son “importantes”. Las tareas “urgentes” son las que sientes que hay que realizarlas de manera inmediata. Puede que no sean tareas “importantes”, pero tienen un sentido de urgencia. Las tareas “importantes” son las que de alguna forma te beneficiarán a ti o a otras personas. Estas tareas tienen un valor significativo cuando se finalizan, ya sea monetario o por lo que significa acabar dichas tareas. Toma una hoja de papel o abre un documento de texto y crea dos categorías: “urgente” e “importante”. Haz una lista con las tareas que debes completar y clasifícalas bajo una de las dos categorías. A continuación marca la fecha de finalización (lo más aproximada que puedas) de cada una de estas tareas. Si tienes más de tres tareas urgentes o importantes y todas ellas finalizan en la misma semana es probable que tenga exceso de trabajo y necesitarás volver a negociar esos compromisos. Puede que te sientas capaz de hacer todas esas cosas pero si ya te sientes estresado, cansado y agotado, al tratar de cumplir esos plazos solo aumentarás esos sentimientos. Si es posible, trata de mover algunos de esos plazos para la próxima semana o comprueba si tus clientes creen que esas tareas son tan urgentes o importantes como tu creías que eran. Si realmente son urgentes o importantes, entonces trata de que tus superiores te ayuden con recursos o para ver si esas personas pueden intervenir para volver a negociar los plazos y las prioridades. Si estás atascado sin salida (tus responsables no va a interceder y los clientes no van a volver a negociar los compromisos) entonces tendrás que tomar algunas decisiones sobre cómo son de importantes esas prioridades frente a tus propias prioridades (esas tareas ayudan a tus ingresos, lo que contribuye a continuar con tu estilo de vida), pero tu propia salud y tu propio bienestar debería tener más peso en la toma de tu decisión que sus prioridades o sus plazos de entrega. Quizás puedas negociar algo de tiempo libre o vacaciones después de ese periodo para poder descansar, relajarte y recuperar tu fortaleza y agudeza mental antes de volver a pasar por una situación parecida.
Aprender a decir “no” es una capacidad muy importante como programador. A menudo nos vemos a nosotros mismos como seres extraordinarios que pueden hacer cualquier cosa que se propongan, en parte porque los equipos informáticos con los que trabajamos parece que pueden hacer cualquier cosa. Desafortunadamente, tenemos unos recursos físicos y emocionales finitos, así que aprender a escoger y elegir los proyectos que son más importantes para nosotros (dependiendo de nuestro propio criterio) nos ayudará a mantenernos a medida que vamos avanzando en nuestra carrera profesional como programadores. Si decimos que “sí” a todo lo que alguien escoge por nosotros entonces tendremos menos tiempo para trabajar en las cosas que realmente nos importan. Estaremos a merced de personas cuyas prioridades y deseos no coinciden con los nuestros. La forma más efectiva de agotarse es gastar toda tu energía trabajando en proyectos que no encajan con tus prioridades y deseos.
Experimentarás periodos de agotamiento en tu carrera profesional como programador. Te encontrarás con cosas que sobrepasarán tu capacidad para hacerles frente. Te verás atrapado en bucles en los que te preguntarás si esto es realmente lo que deberías estar haciendo. Comprender lo que estás sintiendo y reconocer que esos sentimientos son válidos es el primer paso para cambiar tu trayectoria del agotamiento y el estrés. La programación no debería ser una tarea tediosa (ningún trabajo de valor debería serlo). Debería haber algo en tu día a día como programador que te mantuviera motivado y te ayudara a aumentar tus conocimientos. Añadir pizcas de conocimiento, disfrute y asombro, junto con periodos de inactividad, te ayudará a mantenerte a salvo en la turbulencia emocional que te espera. Y reconocer cuando estás agotado y volver a negociar tus compromisos contigo mismo y con otras personas puede ayudarte a revitalizar tus deseos de continuar programando.
Me gustaría enfatizar el hecho de que está bien el pedir ayuda a otras personas. Personalmente me ha costado pedir ayuda. Parte de mi reticencia a la hora de pedir ayuda estaba provocada por que cada vez que hacía una pregunta obtenía la temida respuesta de “eso ya deberías saberlo”. Otras veces creía que al pedir ayuda, eso de alguna manera haría mermar mi reputación. Me considerarían un fraude o un impostor. Las personas se preguntarían por qué habrían confiado en mí al principio. Pero cuando finalmente pedí ayuda, las respuestas no fueron “¿por qué no sabes sobre eso?” si no que fueron “¿por qué no has pedido ayuda antes?” Claro que hubo ocasiones donde alguien se habría sorprendido de que no supiera algo, o que recibiría críticas por mi ignorancia, pero encontré que los beneficios de preguntar superan con creces cualquier efecto negativo.
Pedir ayuda no está limitado únicamente a temas técnicos, hay muchas otras maneras en las que podríamos necesitar ayuda. Podríamos preguntar a colegas que nos ayudasen durante un periodo difícil de nuestras vidas. Podríamos necesitar ayuda de nuestros superiores cuando estamos luchando de alguna manera ya sea personal o profesionalmente. Podríamos incluso necesitar diferentes tipos de ayuda de diferentes profesionales (doctores, terapeutas, etc). Involucrar a otras personas en nuestros problemas puede ser desalentador (o incluso abrumador) pero obtener ayuda de manera temprana puede ayudarnos a prevenir formas más graves de agotamiento o estrés.
La razón más común de nuestra reticencia a la hora de pedir ayuda es nuestro deseo de confort. Pedir ayuda significa el ponernos a nosotros mismos en un estado de vulnerabilidad y esperar que las personas a las que pedimos ayuda nos traten con amabilidad, respeto y dignidad. Esta vulnerabilidad puede verse amplificada si no conocemos a la persona a la que pedimos ayuda o si esa persona es un profesional médico. Pero es necesario el colocarnos en esa situación de vulnerabilidad, especialmente si los problemas o situaciones a las que nos enfrentamos están fuera de nuestro control o exceden nuestra experiencia. Si estamos a punto de sentirnos agotados (o estamos inmersos en un proceso de agotamiento) podremos necesitar la ayuda de un doctor o terapeuta para tratar de la mejor manera la situación que estamos experimentando. Si nuestro trabajo nos causa estrés o tensión, quizás necesitemos hablar con otras personas de nuestro entorno para descubrir si también otras personas están experimentando estos sentimientos. Incluso un simple acto de compasión con nuestros compañeros puede ayudarnos a darnos cuenta que no estamos solos enfrentándonos a estos problemas y puede ayudarnos a encontrar mejores formas de gestionar nuestra carga de trabajo o estrés. A veces no nos damos cuenta de cuando nuestros trabajos o relaciones han pasado a ser de respetuosas y beneficiosas a ser algo que nos provoca más daños que algo positivo.
“No hay que sentir vergüenza en pedir ayuda” es una frase demasiado utilizada, pero pedir ayuda no es un acto vergonzoso. Necesitamos ayuda de otras personas. Incluso simplemente alguien que diga “siento que tengas que tratar con eso” puede ser una conexión con otra persona que simpatiza con lo que estamos pasando. Encontrar a otras personas que estén dispuestas a escuchar, empatizar y compadecerse puede ser la diferencia entre sentirse parte de una comunidad o sentir que hemos sido abandonados en nuestra profesión.
También necesitamos reconocer cuando nuestros sistemas de apoyo no nos están siendo de ayuda. Si vemos que hablar con alguien más no nos está ayudando a resolver los problemas, quizás necesitamos encontrar otras vías de ayuda. Quizás nos demos cuenta que necesitamos ayuda extra.
Darse cuenta de la necesidad de apoyo adicional puede ser difícil, pero una vez que hayas llegado a la conclusión, te animo a que actúes para conseguir esa ayuda extra. Esto requiere de auto conciencia y honestidad con lo que estás sintiendo. Solo tu conoces tu situación y si estás siendo honesto contigo mismo. Si no estás siendo honesto contigo, entonces solo tu puedes darte cuenta de eso y puedes tomar la iniciativa para buscar la ayuda que necesites. Nadie mejor que tu conoce tus propios mecanismos internos.
Pedir y recibir ayuda es una habilidad y como cualquier otra habilidad requiere práctica. Cuando éramos niños, teníamos medios muy simples para pedir ayuda (llorar, señalar algo, etc). Estas habilidades están grabadas en nosotros como parte de nuestros mecanismos de supervivencia, pero a medida que crecemos nuestro mundo se vuelve más complejo. Nuestros métodos de pedir ayuda tienen que madurar igual que nosotros mismos vamos madurando. Esto no es algo que surja de manera natural en ninguno de nosotros. Nos resistiremos a pedir ayuda y nos resistiremos cuando estemos recibiendo ayuda de otras personas. La repetición y una práctica cuidadosa nos ayudará a mejorar nuestra habilidad de pedir ayuda. Mejorar esas habilidades nos ayudará a sobreponernos a los obstáculos a los que nos enfrentamos en nuestro día a día. Esa mejora nos ayudará a ser no solo mejores programadores si no también a mejorar cómo gestionamos los retos que la vida nos ofrece.
A los programadores no les gusta pensar en darse por vencidos. ¿Cuantas veces hemos pedido a otras personas que tengan paciencia mientras intentábamos solucionar algo que no estaba funcionando? (“Déjame unos minutos más, por favor, ¡de verdad!”) Trabajamos con máquinas que parece que no tienen límites en sus posibilidades. Como programadores nos sentimos obligados a explorar esas posibilidades, pero a veces no queremos hacer esa exploración. A veces echamos un vistazo a la lista de cosas que deberíamos aprender y nos preguntamos si merece la pena el esfuerzo. Miramos las ofertas de empleo relacionadas con nuestras habilidades y no encontramos mas que trabajos sin sentido. Los nuevos programadores nos preguntan qué es ser un programador y nos preguntamos si deberíamos advertirles sobre los peligros de escoger una profesión que nos ha llevado a ser infelices y sentirnos insatisfechos. La alegría que sentíamos mientras aprendíamos el oficio va desapareciendo y luchamos contra el miedo de nunca volver a sentir ese sentimiento de nuevo.
La programación no es para todo el mundo. Ha habido momentos donde me he preguntado si debería continuar trabajando como programador. Estoy frustrado porque no puedo aprender todo lo que quiero saber. Me preocupa que lo que estoy aprendiendo siga siendo relevante cuando haya acabado. Siento ansiedad por no se capaz de competir en un mercado laboral donde todos los demás parecen tener ventaja. Lucho por conseguir un puesto de trabajo que ofrece un puesto que no creo que vaya a ser relevante dentro de seis meses, y ya no digamos 10 o 100 años. Siento que el futuro de la computación que me prometieron ha sido corrompido y todos nosotros estamos atrapados en un mundo donde los ordenadores no son más que simples palancas para que las empresas abran las carteras de sus clientes.
Es fácil volverse fatalista sobre la práctica de la programación, pero me he dado cuenta de que hay más en la informática y la programación que lo que el mercado laboral ofrece.
Parte del placer de programar es la curiosidad. Si podemos alimentar nuestra curiosidad mientras programamos, entonces tenemos muchas vías por explorar. Siempre hay otras ideas y otros temas por descubrir, como el desarrollo de juegos, lenguajes de programación “esotéricos” u otros paradigmas de programación. El mercado laboral utiliza una fracción de las ideas de programación que están esperando a ser exploradas. También hay muchos emuladores y equipos antiguos disponibles con buena documentación y comunidades vibrantes. Un área que me ha intrigado, es aprender cómo funcionan las computadoras más antiguas. Las computadoras más antiguas son simples y se pueden entender con paciencia y la mentalidad adecuada. Estas máquinas son bien conocidas y la mayoría de estos programas más antiguos fueron elaborados por un solo programador. Constituyen excelente espacio para aprender no solo cómo funcionaban las máquinas más antiguas, sino también muchos de los conceptos que aún impregnan nuestras máquinas modernas.
¿Qué ocurre cuando nos damos cuenta de que no quedan en nosotros ganas de disfrutar al programar? ¿Qué hacemos cuando la idea de programar ya no nos emociona? ¿Cómo continuamos cuando la simple idea de probar algo nuevo nos llena de terror? ¿Entonces qué?
Si no encontramos ninguna diversión en programar, entonces necesitamos entender por qué nos estamos sintiendo de esta manera. Quizás estamos cansados después de un proyecto muy duro que ha agotado en nosotros toda la diversión y la emoción de programar. Quizás las comunidades a las que nos hemos unido, ya sea en nuestra ciudad o por la red son hostiles o poco acogedoras. Quizás pensemos que programar sería más divertido pero cada vez que empezamos, desearíamos estar haciendo algo / cualquier cosa en su lugar.
Programar es lo mejor cuando de verdad quieres hacerlo. No es para cualquiera. Si estás estancado en una situación en la que no quieres programar nunca más, entonces el mejor rumbo que puedes tomar es dejar de ser programador. No tiene que ser vergonzoso dejar de programar, muchos programadores han perdido la chispa de la ilusión y el deseo de programar y se han cambiado a otros campos. Está bien dejar el campo de la programación y hacer otra cosa.
La programación solo es una faceta de nuestras vidas. Cierto, puede ser una faceta muy grande de nuestras vidas y puede dar miedo el abandonar algo en lo que hemos trabajado tan duro para conseguir. Pero si nos damos cuenta que únicamente seguimos los movimientos por inercia y ya no experimentamos ningún disfrute cuando estamos programando, entonces es tiempo de pensar sobre qué más podemos hacer con nuestras vidas fuera de la programación. Se nos concede una cantidad limitada de tiempo para vivir nuestras vidas. Hacer algo con lo que no disfrutamos nos impide vivir una vida más significativa.
Renunciar no debe ser una experiencia negativa. No hay vergüenza en quitarle tiempo a ser programador. Muchos programadores se han dado un “año sabático” de la programación para explorar otros intereses y recargarse de energía. Romper bucles de experiencias negativas en la programación puede ayudarnos a identificar lo que queremos de la programación y de la profesión de programador. Puede ayudarnos a encontrar y confirmar nuestros sentimientos más íntimos sobre la programación y ver si todavía estamos destinados a seguir por este camino.
Hay varios miedos que pueden impedirnos hacer esta ruptura con la programación. El primer temor se conoce con el elegante nombre de “falacia de la inversión irrecuperable”. La falacia de la inversión irrecuperable es la creencia de que el tiempo y el esfuerzo que dedicamos a aprender y programar es una inversión, y esa inversión se desperdiciará si renunciamos. Por lo tanto, para preservar nuestra inversión debemos seguir programando. El problema con esta falacia es que supone que aún no hemos recibido el beneficio de ese tiempo y esfuerzo. Yo diría que aprender cualquier tipo de programación no es una habilidad desperdiciada. La programación se puede aplicar en muchas facetas de nuestras vidas, como simplificar tareas dividiéndolas en porciones más manejables, aplicar el pensamiento estructurado y comprender la lógica booleana básica. Muchos otros campos también han adoptado las computadoras, por lo que tener habilidades informáticas puede ser útil para ti o para otras personas. El conocimiento que tienes no se desperdiciará.
El segundo miedo es el miedo a defraudar a nuestros compañeros programadores y a otras personas de nuestra organización si abandonamos la programación. Esto es complicado. Es complicado porque incluye a otras personas en nuestro proceso de toma de decisiones. Es posible que estemos en una organización que tiene una carga sustancial de tareas para completar, y nuestra decisión de renunciar significará que estas tareas no se completarán de la manera en que deseamos que se completen. No es difícil imaginar que nuestra ausencia cause daño a toda la organización y resulte en su eventual colapso. ¿Es cierto este escenario? Depende de nosotros determinar si nuestra ausencia realmente decepcionará a todos en nuestra organización. Esto nos pone en una situación en la que nuestro miedo nos mantiene sintiéndonos “acorralados”. Nos sentimos “acorralados” porque nuestro miedo ha creado una situación en la que estamos eligiendo entre nuestro propio bienestar o el bienestar de los demás. Esta es una falsa dicotomía. Nuestra ausencia podría ser el catalizador para que alguien más retome nuestras tareas y trabaje en ellas, y posiblemente las complete de manera más efectiva que nosotros en nuestro estado actual. Necesitamos determinar si somos realmente insustituibles o si alguien más podría tomar nuestro lugar. La respuesta podría ser “soy insustituible, pero necesito salir de esta situación o me haré daño a mí mismo y a los demás si esto continúa”. Depende de nosotros revisar si nos estamos ayudando a nosotros mismos y a las organizaciones a las que servimos, o si los estamos perjudicando a ellos y a nosotros mismos al engañarnos pensando que esto está funcionando.
El tercer miedo tiene que ver con nuestro propio concepto personal de identidad y la memoria de nuestra comunidad. Si decidimos dejar de ser programadores, ¿borrará eso de alguna manera una parte de nuestra identidad? ¿Nuestra comunidad dejará de identificarnos como programadores y perderemos contacto con personas que se han convertido en amigos y colegas? Una vez más, este miedo es difícil de superar porque la programación puede ser una parte importante de nuestra identidad. Dejar de lado la programación nos puede llevar a sentir que nos estamos desprendiendo de una parte de nosotros mismos y de nuestra identidad. También existe el temor de que la gente deje de llamarnos para trabajos u otros proyectos de programación si decidimos tomarnos un descanso temporal. Si el descanso es temporal, ¿la gente recordará nuestras habilidades en programación cuando decidamos regresar?
Cada uno de estos miedos y preocupaciones son perfectamente válidos, pero pueden no ser ciertos. Podemos sentir miedo de que estamos malgastando nuestro tiempo como programador, pero la verdad es que cualquier proceso de aprendizaje no es en absoluto un esfuerzo malgastado. Podemos preocuparnos de cómo otras personas nos perciben o de cómo la empresa de la que formábamos parte continuará sin nosotros, pero la verdad es que no podemos controlar sus percepciones ni sus acciones. Lo que podemos controlar es nuestra participación en cada una de esas comunidades y nuestra propia percepción del tiempo y esfuerzo invertidos. Podemos determinar si una ruptura profunda de la programación sería mejor que una salida gradual de nuestros compromisos. Podemos aclarar con las demás personas cual es nuestro estado actual como programador y determinar si este estado es temporal o permanente. La cuestión más importante es no permitir a los demás que nos convenzan de hacer algo que no queremos o que es perjudicial para nosotros. Si necesitamos parar nuestra actividad en programación porque estamos emocionalmente exhaustos y agotados, entonces debemos dejarlo claro a los demás que les estaremos perjudicando a ellos y a nosotros mismos si continuamos.
Las comunidades más maduras entenderán la necesidad de tomar un descanso y dejar de programar. Entenderán que tu bienestar mental y emocional es más importante que sus necesidad de que continúes y serán capaces de realizar lo que se necesite hacer y subsanar tu ausencia. Es normal y natural en las personas el cambiar de empresas y perseguir otras prioridades.
Lo más importante para recordar, es que es correcto el apagar esa parte de tu ser y dejar de ser programador. Si haces o no que un cambio permanente depende de ti y de tus deseos. Sentirse emocionalmente exhausto, sin inspiración y agotado es contraproducente para la práctica de programación: la programación es una tarea bastante difícil. Tomarse un descanso de la programación para explorar otros intereses es natural y no significa que seas menos programador por querer hacer algo diferente para recargarte de energía. Si descubres que eres más feliz cuando no estás programando, busca cualquier otra cosa que llame tu atención con todas tus ganas. Si decides volver a la programación después de estar fuera durante un tiempo, puedes regresar y retomar tu práctica de aprendizaje. Recuerda: nuestras vidas toman muchos giros y caminos diferentes. El mejor camino para ti es el que haces tú mismo, sin importar a dónde te lleve.
Es un estereotipo para un autor el decir que el libro que ha escrito es el que le hubiera gustado leer cuando se enfrentó a los temas presentados en el libro. Quizás es un estereotipo porque es cierto: este libro contiene los consejos que me habrían ayudado cuando comencé este viaje. Con demasiada frecuencia me he preguntado si he estado a la altura de los niveles que he creado para representar al programador ideal. Muchas veces he visto el éxito de mis compañeros y me pregunto si yo soy un programador ineficaz o deficiente en mi aprendizaje. ¿Qué estaba haciendo mal que otras personas hacen bien?
He llegado a la conclusión que el viaje de cada programador es único. Tu viajes te llevará por direcciones que serán diferentes a las que me llevó mi viaje. Tendrás experiencias que yo no puedo compartir y yo he tenido experiencias que difícilmente tu podrás replicarlas a menos que tengas una máquina del tiempo. Ninguna de nuestras experiencias es menos válida que las del otro, ni son más o menos válidas que las experiencias de otros programadores. Estas son nuestras experiencias. Las áreas de nuestro conocimiento son solo las áreas que hemos explorado hasta ahora. Siempre habrá brechas, pero podemos definir esas brechas como las áreas que aún no hemos explorado. Siempre hay más para explorar, y esa exploración es la parte divertida del viaje.
Ningún viajero puede estar en todos los lugares en todo momento. Deben viajar a cada destino tan rápido o tan despacio como sus medios de transporte les permitan y permanecer allí tanto como puedan antes de viajar a su siguiente destino. Viajan con los compañeros que encuentren en cada comunidad que puedan crear. Construyen relaciones y confían en ellos mismos y en los demás. Utilizan sus puntos fuertes para ayudar a otras personas y explorar y mejoran sus debilidades. Cada día continúan adelante. Como el viajero, a menudo debemos escoger nuestros destinos y compañeros. Podemos encontrar a aquellos, que como nosotros, están viajando por el mismo camino y que nos pueden ayudar en nuestro viaje. Podemos intercambiar historias sobre nuestros éxitos y fracasos y experimentar cada día como otra etapa más en nuestro viaje.
Continuo mi viaje cada día y espero que como programador tu continúes tu viaje cada día mientras seas capaz. Puede que no estemos exactamente juntos en el mismo camino, pero tenemos la misma meta: hacer lo mejor que sabemos hacer en cada momento.
Te deseo lo mejor en todos tus viajes y espero volver a escuchar las historias de tus viajes cuando nos encontremos de nuevo.
Este libro no existiría sin las personas que me han acompañado en mi viaje, tanto docentes como colegas. Mi agradecimiento y aprecio a todos mis docentes en mis años de formación por brindarme sus mejores esfuerzos para enseñarme programación en sus diversas formas. Estoy en deuda con todos mis colegas y amigos programadores a lo largo de los años que compartieron sus conocimientos conmigo y confiaron en mí lo suficiente como para ayudarlos en el camino. También tengo la suerte de tener muchas comunidades que me ayudan a mantenerme, incluidas Michigan!/usr/group, PyOhio, Coffee House Coders y Ubuntu Michigan Loco. También a los que no encajan en estas categorías. Sepa que si hemos pasado algún tiempo discutiendo la programación u otros asuntos, nuestras discusiones son apreciadas profundamente.
También agradezco el trabajo de Leo Babauta de Zen Habits que me proporcionó las ideas de mindfulness y contenedores de atención focalizada. Han sido transformadoras en mi propio trabajo, como lo demuestra este libro. Me comprometí a pasar al menos 10 minutos cada mañana escribiendo cada sección, y los resultados son el trabajo que ves ante ti.
Gracias a los que me ayudaron directamente con este proyecto. Gracias a mi madre, Sharon Maloney, por ayudarme en la edición de este libro. Cualquier eerrorr que quede es responsabilidad del autor. Gracias a Beau Sheldon por revisar el capítulo sobre salud mental y por ayudarme a comprenderlo mejor y resaltar las áreas en las que lucha la gente. Gracias a mi amigo, David Revoy, por su increíble portada y por su inspiración durante todo el proyecto. Gracias a Esteban Manchado Velázquez por agregar CSS y limpiar la versión HTML del texto. Gracias a los lectores beta por sus valiosos comentarios y opiniones en repositorio git en Framagit, incluidos (en orden alfabético por identificador o nombre): Brendan Kidwell, D. Joe Anderson, David Revoy, Eric Hallam, Jer Lance, Matthew Piccinato, Matthew Balch, Midgard, Nicholas Guarracino, RJ Quiralta, Valvin y Wilhelm Fitzpatrick. Gracias a Paco Esteban por los arreglos de edición.
Mi más profunda gratitud es para mi mujer JoDee y mis padres por su apoyo y por creer en mí. Las palabras no pueden expresar el amor y el agradecimiento que tengo por ellos.
Mi viaje como programador comenzó cuando estaba en la escuela primaria. Me interesé en las computadoras después de leer sobre ellas en la World Book Encyclopedia y esperaba trabajar con ellas algún día. Lo que no me di cuenta fue que esas enciclopedias estaban desactualizadas y solo mostraban las computadoras centrales y las minicomputadoras más grandes y costosas de la década de 1960 y no las microcomputadoras más modernas que se introdujeron a fines de la década de 1970. Cuando me di cuenta de que una Apple era una microcomputadora y que estaba diseñada para el mercado doméstico, comencé mi búsqueda para obtener una computadora propia (es decir: comencé a dar pistas no muy sutiles a mis padres de que quería una computadora). Revisé revistas como Popular Computing y Byte Magazine en busca de la computadora adecuada, desde el Commodore VIC-20 y el Sinclair ZX-80 hasta el Radio Shack TRS-80 Model III (incluso el Rockwell AIM-65 o el Heathkit H89 habrían servido. Por aquel entonces no era quisquilloso). Mi padre me llevó a tiendas donde las vendían y me maravillé de la variedad de máquinas que había allí (y probablemente puse nerviosos a algunos vendedores mientras tecleaba y tocaba las máquinas nuevas y bastante caras). Finalmente, mi padre compró una computadora Atari 400 con unidad de cinta y comencé a aprender programación BASIC en serio. Casi al mismo tiempo, mi escuela abrió un “laboratorio de computación” con tres máquinas Commodore PET 4032 (completas con unidades de disquete), y me encontré pasando cada momento que podía con esas máquinas. En la escuela secundaria tomé dos cursos de programación, uno en BASIC y el otro en Pascal (que fue mi primera exposición a los lenguajes de procedimiento y los conceptos básicos de la informática). En la universidad me especialicé en Ciencias de la Computación con una Licenciatura en Ciencias e hice todo lo posible para mantenerme al día con todas las cosas que intentaron enseñarme. Desafortunadamente, no era un gran estudiante (especialmente en matemáticas). Luché y luego abandoné mi clase de compiladores, y sentí que me estaba quedando atrás en comparación con otros estudiantes que tenían éxito. La mayoría de nuestras clases usaban Pascal, con el que me estaba familiarizando, pero había algunas clases que usaban COBOL, Ada, SNOBOL, C y lenguaje ensamblador. Me gradué con notas modestas y regresé a casa.
A lo largo de mi carrera, he cruzado la brecha entre la administración de sistemas y la programación. Linux era similar a las máquinas SunOS que admiraba en la universidad, así que pasé a usar eso como mi sistema operativo principal alrededor de 1995. En mis primeros trabajos me encargaron el mantenimiento de varios tipos de computadoras: PC de escritorio, máquinas basadas en UNIX y de manera ocasional de las copias de seguridad de las máquinas VAX. No fue hasta que uno de mis puestos necesitaba un sitio web que agregué más programación a mi currículum. La programación de sitios web en la década de 1990 fue donde realmente comencé a aprender y comprender Perl, SQL, bases de datos relacionales y HTML. La web era tan nueva en la década de 1990 que todas las personas en nuestros proyectos estaban aprendiendo al mismo tiempo. Aproveché mi conocimiento de Perl en algunos otros trabajos y proyectos haciendo programación basada en web. Perl en la década de 1990 era un lenguaje donde los conceptos básicos eran simples de aprender pero el lenguaje podía manejar ideas y estructuras de datos realmente complejas. Perl y CGI facilitaron la incorporación en una página web de algo que tuviera un poco de interactividad. Donde Perl se vuelve complejo es la sintaxis de cosas como las expresiones regulares y la tendencia de los programadores de Perl a valorar el código que realiza múltiples acciones en la misma línea. La comunidad de Perl también valora el código inteligente, lo que me llevó a preguntarme en varias ocasiones si era lo suficientemente inteligente como para ser un programador de Perl.
Una de las empresas en las que trabajé decidió migrar un sistema Perl
a un entorno basado en Java. Analizaron las habilidades del equipo de
desarrollo existente y decidieron que necesitaban externalizar el
proyecto a otra empresa. Esta era una tendencia común a principios de la
década de 2000 por razones que están fuera del alcance de este libro.
Esto me dio un primer contacto como líder de un equipo. Sé que muchos
programadores migran a roles administrativos, pero en ese momento sentí
que no había explorado completamente mi potencial de programación. Me
senté en varias ocasiones e intenté aprender Java, pero nunca me llamó
la atención. El desarrollo web Java siempre lo sentí más engorroso que
los scripts CGI de Perl que creé. Tampoco ayudó que enviáramos archivos
.war a un sistema Tomcat, que parecía estar compuesto por
una gran cantidad de metadatos de configuración y muy poco código. Esto
es a lo que me refería cuando hablé de estar bien con renunciar a
aprender algo, a veces lo que tratamos de aprender es más una tarea
rutinaria. Tener algo que es una tarea rutinaria no va a proporcionar
una buena experiencia de aprendizaje.
Fue en ese momento cuando comencé a aprender Python por mi cuenta usando Pygame. Me lancé al participar en mi primera competición Pyweek. Pyweek es una competición de una semana en la que la gente crea un juego completo desde cero. Fue un desafío, pero también fue una de las experiencias más gratificantes que he tenido en la programación. Creé un juego llamado “Busy Busy Bugs” que se podía jugar en un momento en que realmente no sabía lo que estaba haciendo. En muchos sentidos, estaba aprendiendo a nadar arrojándome al proverbial fondo profundo. No estaba en peligro, pero el deseo de hacer algo al final de la semana me guió de maneras que no creía que fueran posibles.
A medida que la posición de líder técnico continuaba, me encontré con ganas de hacer otra cosa. Me entrevisté en varios lugares y fui contratado en Sourceforge como miembro del Grupo de Operaciones de Sistemas. Sourceforge fue una experiencia increíble para mí. Soñaba con trabajar para una empresa de código abierto, y pocas empresas de código abierto eran tan bien consideradas como Sourceforge y Slashdot en la comunidad de código abierto, pero mis inseguridades y el “síndrome del impostor” entraron en acción. ¿Sería capaz de cortarlo? ¿Me contratarían solo para darse cuenta de que habían cometido un error y que no era tan bueno como decía ser? Yo era amigo y había ido a la escuela con varias de las personas que trabajaban en Sourceforge/Slashdot, así que me preguntaba cuales eran sus motivaciones para contratarme. ¿Me contrataron como una broma elaborada o me contrataron porque varias personas en la empresa me conocían? Todos estos pensamientos pasaron por mi cabeza mientras trabajaba allí. No ayudó que mi posición fuera principalmente administración de sistemas a un nivel en el que no tenía experiencia. También había un componente de programación en el puesto, pero constantemente sentía que estaba muy por encima de mi cabeza. Vivía con el temor constante de que me descubrieran y de que el trabajo que quería ya no estuviera disponible para mí. De acuerdo, aprendí mucho y tuve unos jefes muy amables en Sourceforge, pero vivía con pavor cada vez que mi gerente me consultaba, porque temía que la conversación solo resaltara que se suponía que yo no debía estar allí.
Me encantaría decir que tuvo un final feliz y que mis temores eran infundados, pero lamentablemente me despidieron de ese puesto debido a restricciones presupuestarias. Estoy agradecido por las oportunidades que tuve allí, los amigos que hice y las experiencias que tuve, pero estaría mintiendo si no dijera que el despido vino con una mezcla de tristeza y alivio. Tristeza por no poder volver a tener un trabajo genial como ese y alivio por poder dejar de lado por el momento esos sentimientos del síndrome del impostor. En muchos sentidos, crecí a partir de la experiencia de trabajar en Sourceforge y aprendí mucho sobre mí y mis capacidades mientras trabajé allí, pero también fue el puesto en el que sentí mi síndrome del impostor en su máxima expresión.
Más tarde me contrataron para un puesto a tiempo completo haciendo programación Python. Este empleo me permitió fortalecer mi oficio como desarrollador de Python. Allí creé muchos proyectos interesantes y seguí aprendiendo más sobre Python. Me ayudó a recuperarme y ampliar mis habilidades. La gente en este trabajo fue muy comprensiva y amable. Hubo momentos en los que se volvió estresante (todos los trabajos parecen tener estrés), pero en general fue una experiencia positiva.
Lamentablemente, también me despidieron de ese puesto (el dinero apesta, ¿sabes?).
Empecé mi búsqueda de trabajo en serio y fui a un montón de entrevistas. Si bien todas las personas en las entrevistas parecían impresionadas con mis habilidades y mi carrera, caí en una de dos categorías: no encajaba bien en el puesto o no tenía suficientes conocimientos en las áreas que buscaban. Me encontré haciendo pruebas cronometradas de escribir código que parecían estar probando si me estresaba fácilmente en lugar de las habilidades de de escribir código que pudiera tener. Me senté en sesiones en las que escribía código con figuras sombrías que gritaban comandos y requisitos mientras hacía todo lo posible por seguirlos. Hice acertijos de matemáticas y problemas de lógica (lo cual es horrible si no eres bueno ni en matemáticas ni en problemas de lógica). Los primeros indicios prometedores se convirtieron más tarde en cartas de rechazo (suponiendo que me respondieran), y la desesperación se apoderó de mí cuando me enfrenté a la perspectiva real de que tendría que dejar la programación si quería ganarme la vida. Las visiones de regresar a los comienzos de mi carrera me llenaron de pavor. Parecía que ya nadie quería arriesgarse conmigo y no podía competir con tantos programadores nuevos que no habían cometido los errores que yo había cometido en mi carrera.
Durante ese periodo registré el dominio web themediocreprogrammer.com. Si yo iba a ser un desastre entonces podría aceptarlo.
Afortunadamente, he tenido una comunidad de amigos y compañeros programadores que me han ayudado. En mi trabajo actual estoy contratado por uno de estos amigos al que ayudo con las tareas de programación. Ese puesto surgió al asistir a PyOhio (una conferencia de programación) que se celebra todos los años. En todas mis luchas, he tenido la suerte de tener allí a una comunidad que me ha ayudado. Es por eso que creo que las comunidades son tan geniales: nos brindan una red de personas que de otra manera no tendríamos, y nos ayudan a superar nuestros triunfos y nuestras luchas.
Soy una colección de todas estas experiencias. Todas ellas me hacen quien soy. A veces me pregunto si debería haber tomado un camino diferente o haber hecho algo diferente, pero ese es un ejercicio inútil. Lo mejor que puedo hacer con estas experiencias es aprender de ellas y seguir adelante. Cada día trabajo para mejorar y superarme. Cada día cometo nuevos errores, pero todo eso es parte del proceso de aprendizaje.
Mi viaje continua.