Al Idian

Learning What to Learn


Working as a software developer, I am often reminded it is simply impossible to learn it all. There is always an established tool I wish I knew more about or a trendy new language to take for a spin. Adding to the noise is the siren-call of tech marketing that promises products that increase developer enjoyment or productivity — often years before they are actually ready for production use.

Even committed learners (especially them) can sometimes feel they are running inside a hamster wheel of tech education — there is just no way to keep up!

Many times after having spent a few nights fixated on an interesting study topic, I have wondered whether I will ever actually use my newfound skill. Eventually, I realised that not all learning is equal. As such, it is worth thinking not only about how to learn — but also what to learn. This is the key idea behind selective learning.

Selective learners are not only free to devote more time and energy into the most impactful areas of study, they can also keep up better with key developments in those areas. This is of course nothing new — the narrower the focus, the greater the effectiveness.

In practice, one way I have tried to become a more selective learner is simply to ask whether what I am learning meets the following criteria:

Given two interesting technologies that are likely to become part of my future tech stack, the method above prioritizes the one that is immediately useful to me. By modifying the criteria to one’s own situation, it is easy to see how the method can be helpful in making the important choice of what to learn.

Having a system (even a rough one like above) of assigning value to potential areas of study can help in deciding which areas of study to pursue. And carefully selecting where to invest one’s study time can have a large impact on a developer’s productivity and enjoyment.