Tienes tu propia historia única de cómo has llegado aquí como programador. Es posible que te hayas enterado de qué era eso de la programación caundo eras un niño curioso que quería ver lo que podía hacer la computadora. O quizás es posible que hallas llegado como un adulto que escuchó sobre estas cosas llamadas computadoras que puedes programar. Cualquiera que sea el caso, has tenido un viaje para llegar a 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 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.
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 su 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 volviera un poco y ahora no eres digno de ser llamado programador a menos que fueras 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 fines 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 breca 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 externas.
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 cambios que nos llegan: cabios 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. Nuestra comunidad de programadores y usuarios pueden 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 circulo 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 parche 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. Es software que utilizamos podría tener una razón muy válida para ese cambio. Las nuevas funcionalidades que deben ser añadidas requieren nuevas formas de pensar nuestro código. Las soluciones a problemas de seguridad podrían significar que nuestros sistemas ahora serán más eficientes frente a ataques externos, pero requieren diferentes formas de utilizar ese sistema. Optimizaciones nuevas y mejores 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. El volver a escribir una API puede llevarnos a interactuar con nuestros sistemas de una manera más limpia y concisa, pero deberemos incluir cambios que lo hacen incompatible 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.
I'd love to tell you that there's a way to close the gap; a way to say you've learned it all and can feel confident that you have mastered the totality of programming.
Sadly, I haven't found a way to close all of the gaps.
You can keep learning everything there is to know about whatever topic you've chosen to learn. You can take every course available. You can attend every talk and colloquium, read papers about the subject, and even do your own research, and you can still feel like you haven't closed the gap.
So if there's no way to completely close the gap what can you do?
There are three options available to you:
The first option is not to try. Realize there will always be more to learn. Why bother? It's easier to tell yourself you'll never be able to close the gaps in your knowledge. The best option, you tell yourself, is to stick with what you know and ride that out as long as you can.
The second option is to try to do everything at once. You grab every book, blog post, paper, video, or what-have-you to try to learn the topic. Next, you realize that you only have a finite amount of time to learn the topic, and that you can't use all of that material at once. You look over your progress and despair that your learning is not progressing as quickly as you would like. You blame the materials for your lack of progress and look for something else that will help you better learn the topic. Frustration sets in as you blame yourself for not starting earlier to close this gap.
The third option is the more measured approach. You start small with small tasks and work your way toward the goal. Rather than look at the gap as something to be closed, you realize that you can't know the totality of whatever topic you're learning. You enjoy the knowledge you receive in the pursuit of learning the topic. You keep a steady pace toward learning as much as you can. Instead of lamenting that you didn't start sooner you're grateful that you started at all.
Of these three options the first and third are the ones where you'll find the most contentment. The first option (not trying) allows you to sit with the knowledge you have. But there's a downside to just staying in place. Our industry is constantly changing and technology continues to move. What used to be the norm becomes legacy and what was just around the corner becomes the thing that is in demand.
One of the most useful skills of a programmer is the ability to adapt to new technology. As our technological environment changes, our ability to adapt to those changes allows us to continue on as programmers. Faster machines, different technologies, different devices, different requirements; each of these brings us exciting challenges if we recognize them. But they also take time to learn and create gaps in our knowledge. Relying on our previous knowledge to carry us through these changes isn't going to be enough. We're challenged to adapt to the new surroundings.
The second option (trying to cram and becoming frustrated) is the least optimal path. Trying to learn by grabbing every available resource and jamming it into our brains is a path to frustration, fatigue, and burnout. Many developers try this because they feel the need to adapt to the new environment, but it's difficult to make sweeping changes all at once. It's like trying to evolve wings because you're late for an appointment: you'll be frustrated with your inability to grow wings and still be late for your appointment. The second option also measures your progress by how much further you feel you need to go. It discounts the progress you've made, and creates an endless cycle of running toward a moving finish line.
Of the three options it's the third option that makes the most sense. Taking a measured approach in closing the gaps of our knowledge allows us more joy in our learning process. By breaking down each of the steps on our journey we give ourselves little wins along the way. Instead of expecting a grand transformation we allow ourselves gradual changes and mutations to adapt to our environment.
With this measured and gradual approach we also gain the wisdom that we don't have to close all of the gaps. We can allow ourselves to keep learning in the areas that we need to and gradually build up our skills.
We also can realize that closing the gap is an illusion. As long as we're alive there will always be gaps; new things are created every day. We can choose how far we want to go to become more expert in whatever topic we chose to learn. We can still strive to learn as much as we can, but we do so with a sense of joy in the learning process, not from some perverse need to try to collect the totality of computing knowledge into our heads.
## The Journey is the Reward
The secret to moving forward in our journey as programmers and developers is realizing that each step we take along that path is valuable and worthy of our attention. Just because we haven't learned the latest technology in a fortnight doesn't mean we should give up trying. Nor does learning a technology only to watch it become overshadowed by something else mean that our learning time was wasted. Every challenge we face, every technology we learn, and every hour we spend coding is another step on our journey to becoming better programmers. Each mistake and wrong turn introduces us to opportunities to learn from those mistakes and grow as programmers and developers. There is no perfect path toward becoming better at this. Even if there were I'm sure we could point to any point in our past and say that it was less than perfect. Carving the perfect path from where we are to where we wish to be is not possible. Worse, it is an illusion that keeps us from moving forward in our daily practice of programming and developing. It may seem trite to say "the journey is the reward" but every day we work as a programmer and developer is one day closer to shoring up those gaps in our knowledge and becoming more content with how our skills are growing.
