Software engineering is a discipline that requires constant learning “by design”. As new frameworks are released and adopted, as the reliable, old and tried technologies get new releases that introduce major changes and completely new APIs, the only way to not fall behind* is to keep learning, or, at the very least, to be able to learn on-demand, only what is needed, when it is needed.

The best way to do this is to first make up your mind and commit to only learn what is needed, when it truly is needed. This is very important because the pace of change of the software landscape surrounding your company and your direct team(s) is usually faster than the pace of change of a certain product off of which the company you’re employed for is making money, i.e. a product can exist over, say, 15 years, having its’ core code left untouched for a decade. It’s almost like a code freeze. There can be many satellite changes around such core area of the codebase, there can even be several complete re-architecturings over that period of time that can have a big impact into onboarding new colleagues, support growing team(s), new deployment strategies, you name it.

However, chances are, for your daily work you will be focusing on either maintaining existing code, fixing bugs or extending it with new capabilities. And, in such situations, consistency is king, and the best way to do things is to follow in line with the patterns that are already in place, which can mean, sometimes, to do things in a way that is not the newest, shiniest way, but, it’s the best way to ensure correctness and reliability of the work done.

Eventually, though, a time will come when you will either face an architectural decision that will force you (or your team) to learn something new, or, a completely new greenfield project needs to be deployed and tested in a special way, and, you need for example to learn Docker. You’ve never done it before, but, it seems like it’s the chosen way forward. What to do now?

Learning at work

The best approach you can take is to learn the new things you need, in the context of your job. In the context of your codebase, of your ticket and of your team.

While it can be harder to do it, because you have to embed completely new knowledge into an already existing, large and complex system that needs to stay working, this hurdle can actually be seen as a lifeline. The constraints of the environment can make you look at the new thing you’re trying to learn with a laser-like focus and that will push you to both stay focused on the fundamentals of the new tool and to learn the bare minimum to get a working solution within your ecosystem. This, in turn, will give you confidence in your capabilities to learn the new thing and you now have a solid foundation from which you can start expanding your knowledge. In fact, learning at work is not only required, but, it’s desirable:

• laser-like focus: the environment in which you are operating is more constrained and sensitive than if you’d be working on a side-project specifically conceived to learn Docker. By needing to integrate with a real system that needs to remain working, you can be more pragmatic in your learning;

• using it in a production context: there’s a difference between working on side projects or shipping code at your day job that will be bringing value to clients. If you work with a new technology directly “in production”, you will learn much faster and your learnings will be more relevant;

• solid foundations: the “mettle” you will gain while struggling with the fundamentals of the new tool you’re trying to leverage can actually help you in exercising traversal skills like Google searching, reading official documentation, prefering bare-bones approaches and expanding, and these types of skills are skills that can serve you as an engineer in a myriad of other contexts, so, they’re definitely worth exploring and developing;

So, keep in mind, next time you need to do or learn something new: do it at work! Your colleagues and team will benefit and so will you!

(*) - obviously, the term falling behind is a bit too strong here, after all, there are endless developers who stick with older technologies due to their area of work who have and lead amazing careers and hone their skills to the best of their abilities. To each its own.