How do you decide what to learn next?

#career #learning

Disclaimer: this is not professional career advice and should not be treated as such.

One question I've been thinking a lot about these days is “how do you decide what to learn next”? There are multiple aspects to this, and to be honest my head is all over the place on this one. This post will basically be a brain dump, and may or may not lead to a conclusive result.

To start with, I feel we can divide this question into two more specific ones -

  1. How do you decide what to learn as a beginner?
  2. How do you decide what to learn next?

I've talked to a lot of people who have been starting out with programming, and one question I get asked a lot is - “what should I learn”. Not everyone asks this, but I've had enough people ask me this question for me to start thinking it might just be a common theme.

On the other hand, people who have already been programming for a while may at some point feel the need to do something else. We are all wired differently, but common reasons include (but are not limited to) -

  1. getting too comfortable with the current set of technologies at $WORK
  2. struggling to separate the hype from what's real (speaking from personal experiences, this is easy to dismiss but can be quite a struggle)
  3. the need to try something “new”
  4. fear of missing out or being left behind

Without knowing a definitive answer or claiming that I know of a bullet-proof approach to be able to answer questions along similar lines, I feel one can apply a few different approaches here to reach a slightly less confused state.

What do I want to optimize for?

One approach is to take a step back completely, and try to ask instead the question “what do I want to optimize for”? A common piece of advice in the software industry is to "optimize for learning". Vague as it may be, it's an interesting approach nevertheless.

Once you ask this question, your mind starts giving you all these "meta" responses. It might tell you that you want to optimize for learning how to build low latency web services, or data science, or functional programming, or whatever. You can then take the answer to this question, which should give you a few pointers on how to answer your original question.

What skillset is kind-of sort-of adjacent to my current one?

Another relatively common piece of advice is to learn something that's different enough from your current skillset. The idea is that if you learn something that's too similar, you won't really be learning anything. But if you pick up something completely orthogonal, you would probably just get discouraged quickly, foiling the entire plan.

This also seems to confirm the theory that our brains feel the most productive when they're working slightly outside their comfort zones, but not too much. I can't find the source right now, but spending some time on a good search engine should help.

One example would be that if you're a backend developer, you could look into improving your CSS skills. Not sure if this is a good example, but you get the idea.

What skillset would augment my current one?

We don't have to always think in terms of writing code. There are plenty of non-programming skills that can help you become a better software developer.

For example, being able to write well is something that goes a long way in helping you communicate your thoughts to others. Software development is a team activity, so if you're able to write well, you'll be able to (as a team) develop better software.

Another example is having good communication skills. A lot of my non-tech friends laugh about how difficult it is to communicate with developers, and how only a special kind of person can do something like that. We laugh it out and it makes for a good conversation and everything, but at the back of my mind I'm thinking “you know what, this is actually not funny”. Think about how much it'll improve your career if you could translate developer-speak to other-people-at-the-company-speak. Not only is this one of the core attributes of being a good engineering manager (if that's a direction you'd like to take), improving your communication skills in general helps you become a well-rounded person.

Personal anecdote: I've been the person who stands in the corner nursing his beer at a party, and I've also been the person who makes an actual effort at communicating with other people and succeeds, and every single day I prefer being the second version.

Programming is just a means to an end anyway.

One school of thought which many subscribe to is to consider programming as a tool supposed to solve problems. Code is not useful by itself, unless it's solving somebody else's problem.

So all the beauty and elegance that one might optimize for when writing software doesn't really matter, because your users won't see/understand it anyway. Your job is just to take what your users want, and figure out a way to solve their problems using the minimal set of resources in the fastest possible time producing the most reliable result.

When I think of producing something reliable quickly using the least possible set of resources, I have the feeling this is kind of like saying “use the right tool for the job”TM.

So depending on who your users are and what their problem is, it should be possible to find the technology you should be learning as opposed to certain other ones, which is kind-of the answer we were looking for?

Or in other words, find a problem to solve, which then tells you what technology to pick, and then go ahead and learn it.

Would it increase my chances of finding a job?

We all want to find a way to earn money with our skills so we can provide for ourselves and our loved ones. So optimizing for being employable is not necessarily wrong. The problem, in my experience, comes from decision paralysis.

There are a ton of software companies building different kinds of software. And the ones who have a strong online presence swear by the technologies that they're using. So when we're trying to optimize for employability, we basically have to sift through all this noise and identify the technologies that would increase our chances of getting a job in the industry. Besides, some languages/frameworks are pushed more than the others, which only adds to the confusion.

Another problem here is that more often than not, the market is driven by hype. Millions of VC dollars being poured into companies who are riding on the hype train is enough to make anyone confused as to what's real and what's not. Unless you have good experience/intuition on how to distinguish hype from substance, this decision can require a lot of willpower and can be extremely tricky.

What feels fun to me?

A lot of us program because it's just fun. We started back in high school, wrote small scripts here and there, picked up new things which we found interesting, just for the heck of it. We code because we like writing code.

The approach here would be to activate kid-mode, and make a decision without giving any thought to whether or not it's the optimal one. Sometimes it's also OK to decide without having any ultimate goals in mind.

If you're capable of ignoring the grown-up-voice in your head that's questioning your decision and is instead asking you to make one that's more “informed”, you can get to an answer pretty quickly following this approach.

What are my values?

This is something slightly more involved. If you can figure out your core values

For instance, if you really value privacy, there are plenty of developments happening on the web that can provide you with exciting opportunities on what to work on next (and ergo, what to learn next). Or if you really value correctness, formal methods might be something you could consider.

This can require a little bit of soul-searching. I recommend sitting down in a quiet room with a pen and paper, without any electronic devices, and just start writing your thoughts down. It may take a while before you get some clarity, but it'll be worth it.

I'm pretty sure there are more mental models that one can use to answer questions along similar lines. As mentioned right at the beginning, this blog post does not provide a conclusive answer, but I feel that the approaches listed out here should provide a good starting point to get to where you want to be.

The most important thing out of all this, though, is that irrespective of the decision you make or the approach you use, it's important to stick to your decision. We often have the tendency to leave things halfway because of reasonsTM. Well, at least I do. This is plain counter-productive. I've learned this the hard way, and would like to help as many people as possible avoid falling into that trap.

Good luck!