In the first part of this series on always learning as a software developer, I suggested learning about:

1) something that’s tangential to what you’re working on; 2) or some tool that will improve your development environment or process.

The rationale was to minimize the mental overhead caused by context switching, thereby making constant incremental improvements.

But there are downsides to this approach:

  • This approach won’t allow you to learn something that’s completely different from what you already know.
  • This approach may keep you in a niche which over time turns out to be not as lucrative or financially viable.

To avoid these potential downsides, we have to tweak our formula here on ‘what’ we should learn.

...

The opposite of taking a small incremental step is to take a huge one. If you’re stuck in a local maximum, you need to take a giant step in some direction. But in which direction?

Choosing a direction can be scary, at least it is scary for me. There are two reasons to be scared (and these reasons are related to the downsides of the tangential approach above).

  • There’s always a cost to learning something new. The cost isn’t just measured by time, effort, resources, and opportunity cost, but also by the magnitude of the step, as in how big of a conceptual gap exists between what you already know vs. what you’re trying to learn.
  • There’s always a risk that what you learn may turn out to be not very beneficial or marketable. A library may stop being maintained. A framework may become outdated. A language may fall off the TIOBE index. When that happens, you’re going to feel like you’ve wasted a lot of time for nothing.

For these reasons, it can be daunting deciding what to learn.

...

So here are some heuristics that I’ve used when to decide whether to learn something that required significant investment.

  1. Maturity & Future Viability

    Don’t be the first one in the pool. Don’t be the second, either. Be about the third, and make sure there are big players who rely on the said pool and have incentives to keep the pool well-maintained. (There are other reasons to jump in first, such as name recognition, or you may want to write or give a conference talk about the pool). Okay, so I’m stretching the analogy a bit here, but you get the idea. Assess the maturity and future viability of whatever you might learn. There are tools online that help with this, like ThoughtWorks technology radar.

  2. A Clear Destination & Potential Exits

    I got back into programming because I thought I had a killer app idea. Turns out my idea was too hard for me to execute, but along the way I picked up some skills that made me employable. As I took these huge, costly steps, I learned & published smaller apps that would build up my resume, and hence make me more employable. After about a year, even though I had barely started on my killer app idea, I was able to fill out my resume with my other, smaller projects that were published on the Google play store. As a bonus, I monetized these smaller apps. Another option would have been to open source them.

    In short, lay out a clear end-product of what you want to build, and what you need to learn to build it. Have some timeline of how long you would spend in the ‘learning’ phase, with side roads and potential exits along the way.

  3. Same Mountain, Different Paths

    Rewriting old software can be a good way to decide on what to learn. It’s tangential not in the tech stack that you know, but in terms of domain knowledge you already have. Because you know what to build already, you can invest more in how to rebuild it. The familiar mountain terrain may be easier to navigate, the trees and the slopes guiding you to the summit, even as you chart a new path.

  4. “TOO COOL!!”

    We’re geeks. Sometimes the more you hear about a new language or library, etc, the more you want to learn how to use it. “For Jacob loved Rebecca, and seven years seemed like days.” Then use it! Don’t think about whether you’re wasting your time learning, or whether you’re monetizing it properly. As long as you’re enjoying the learning process, you’ll most likely learn some new concept or idea.

That’s it for now! Hope this helps you, dear reader, in deciding what grand adventures you will take on next! (Along with the tangential improvements, of course!)