Technology, especially something as abstract as software, is constantly evolving. Your skills of yesterday will be seen as liabilities on your resume tomorrow.

There are (at least) two challenges to constantly learning: 1) finding time to learn; and 2) choosing what to learn.

Notice what’s not on there: resources. In this day and age, we have incredible amount of learning material, often free or cheap, to choose from. But that makes choosing what to learn that much harder. Whether you’re a beginner or an expert in one specific domain, there are so many topics to choose from. As an Android developer, for example, I can choose to learn more about web development, iOS, Flutter, backend, AWS, docker, kubernetes, machine learning, CI/CD, devops, different languages and paradigms, architectures, design patterns, and on and on. And even specific to Android, even within this small niche, there’s so much to learn, with Kotlin, architecture components, coroutines, jetpack, dagger, rxjava, retrofit, okhttp, gradle, etc. etc. that seem to be industry standards.

On top of that, a lot of us just don’t have the time to learn these things. “I’m so busy,” you say, “and I don’t have time outside of work to learn.” Depending on where you are in your life and career, maybe the time at work is all you have to grow as a software developer. Or, maybe you’re trying to pick this up in your spare time. Maybe all the time you have is couple of hours every night after a long day at work and putting your kids to bed.

So here’s the trick (and this applies whether you have a job as a developer or you’re learning as a hobby or in preparation to a career switch): 1) Learn during the down times built into software development. 2) Learn what’s tangential to what you do; and

...

Let’s talk about the down times first. There are invariably down times during software development. Is your machine compiling? Is a remote machine building? Waiting for a quick code review? Learn!

Do you feel like you’re in a lot of meetings? In some of the meetings, you might feel like you really shouldn’t be there, as your input isn’t needed most of the time. The first step would be to try to get out of meetings. Failing that, take your laptop and treat these meetings as down times. Learn while you half pay attention to the meeting at hand.

But what if you aren’t a programmer for your day job? If you’re learning at home, try creating something instead of learning. Go ahead and do couple of tutorials and samples just to get started, but then take the plunge and create something. That will create this rhythm of learning, creating, and down times, which you can use effectively to feed into a virtuous cycle of more learning and more creating. If you only have an hour or two every day, learn just enough to start creating. That will help you to focus on what you should learn in order to create the next feature or start the next project.

...

So we’ve established when you can learn (even if you don’t have time), but what should you learn? After all, even if in the aggregate, down times can be an hour or two everyday, it’s spread out and hard to have sequential, linear time dedicated to learning. And context switching is mentally painful!

So my tip here would be to learn something that’s tangential to what you’re waiting for during the down time. For instance, maybe while you’re waiting for a remote CI like Jenkins to finish a build or a smoke test, you can look up how to run a specific unit test on your machine. Or, you can google problems related to the one you’re solving while your code is being compiled.

If all else fails, you can always learn about how to improve your development environment to make you more productive. Since you’re looking at your IDE/terminal/some sort of rendering engine/etc., looking for ways to improve it won’t be that big of a context switch!

...

Your down times may seem inconsequential and these small improvements might seem minor. But over time, they will add up! The small skills and tools you accumulate will in time allow you to work more effectively or tackle problems that seem insurmountable. Become comfortable using the terminal / command line. Add aliases or paths. From there, learn more about the build system that your project uses, like gradle. Customize your build system. Learn different git options. Find different ways to run specific tasks or make compilation faster. Google a different way to setup your IDE. Find out about the library that you’re using and see if there are different ways to set it up. Find out whether there are similar libraries. All these small incremental improvements may not seem like much, but they will add up over time and help you become a much more productive and valuable developer.

However you decide to use your time at work or at home, whatever you decide to learn, make the most of your time. Don’t waste your potential for growth. Always learn!