Ask HN: What is your learning strategy?

I can tell you only a couple of things. See, It can get overwhelming very quickly and it expands in deep as much as deep you go in technology.

You should rather focus on what you NEED to learn, don't get caught in imposter syndrome. Because you mentioned you have a full-time job already, You only have a limited time. Juggling and switching into lot of things will affect your productivity.

For me, I evaluate first what I want to do and then search the technology available around it. Then, I make a list of what I need to learn and I start with one, gradually.

Start building the things that you want to build, and you'll learn what you need to along the way. This is the strategy that has brought me the most joy and, not coincidentally, it has also been the most effective by far.

I too am in the same boat. I too am overwhelmed by the amount of information out there. Currently what I do is, I make content, and to make content, I need to learn. Also, If I take up any online class, I make sure there is a certification awarded. Another thing I do is always try to do something that adds the green square in my github profile.

In short, if you produce more, you will automatically learn more.

Now, what to learn depends entirely on your choice, also for me, I am Ok to quitting if I don't like any course.

It’s amazing how much you can learn from casual friends. Find a person at the office who knows things and offer to buy them a beer. Likely you will gather more from that exchange than if you had spent that same time studying.

> On the other hand, as far as I see, I am supposed to know many of them.

Why do you think of that? were you hired as the person that knows all of them?

Remember that as software engineers, our job is to solve problems. It doesn't matter what technology, language, or framework as long as you bring value on the table.

The question is what is it that you want to learn? based on that you will figure out what you need to learn and how you will be providing value to future employers.

Personally, I'm heading for a senior position. As a senior (in my current company, may vary from company to company) is to enable others, unblock from potential issues and mentor them on best practices and core values. Based on that, I choose where to focus my learning and what to read/research next.

Of course, I am still a software engineer and still need to learn new technologies maybe or refresh my current knowledge. I do that by reading newsletters, blogs and spending time outside my working hours to those. I will choose to go deeper into a particular technology if I think that it will bring value to our current stack. That's not required though and you can demand from your employee to provide that time for you. I'm doing it because it's my choice to do so.

Work gives you good opportunity to develop deep knowledge in a subject, but to stand out you also need broad knowledge, years of work experience can give you this, but your own time can speed this up.

I find that programming at work and home all the time is a recipe for burnout, but if you use leisure time for reading docs, blogs, watching videos etc (and a perhaps a little programming) this can be refreshing, particularly if it gives you broader knowledge for your current role - use your k8 experience to read up on docker and other systems. What are the alternatives to AWS you are using and other AWS Systems that may be appropriate for your work Etc.

Concentrating on the interesting things around your current role will be good for your career now.

I watched a talk: How to learn anything fast[1], and it really shaped my learning strategy, what I do (or at least try to do) is to focus on one thing I want to learn, if I want to learn many things (which is almost always the case), I often choose the one I feel will give me the more return in the long run, and I apply the tips discussed in the talk.

1: https://youtube.com/watch?v=EtJy69cEOtQ

I like to dig in a bit more and learn the fundamentals underpinning things. If you understand the http protocol, then any web server you encounter is easier to understand, for example.

To me it seems ridiculous that employers can require such an amount of breadth and depth of knowledge. I think this is a fascinating question regarding the pursuit of software engineering. But to hold yourself to the standard of having this in order for career advancement, I think there are easier ways.

Maybe that, or I am simply naive.

As my distributed systems teacher used to say: don't be scared by new terms of concepts in computer science. When you think fundamentally about what things are, you will realize that, most of the time, it's a concept that is similar to something you have learned before, if not entirely the same.

Just build things, by doing so, you start connecting things you never thought possible.

I’ve found it useful to know the underlying principles for a lot of things, but the details for a few. For instance,

Understanding b-trees and log based data systems helps with most database systems - I look up the SQL syntax, Postgres and MySQL functions just in time, and I understand why Aurora is worth it.

Understanding how some container or faas systems work (instead of their API) is h enough to understand most of them.

Understanding how some distributed noSQL systems work is enough to understand whats capabilities most of them will have, and their limitations.

Basically, if I understand the fundamentals of why and how something is built, it’s easy to guess the APIs abc capabilities of it and any comparable system, so you’re learning compressed patterns instead of lots of transient details.

My learning strategy has a few parts:

(1) Projects as the top-level structure. [Lookup: Ultralearning - a book/website (get the book). It covers designing learning projects.] This is the backbone of how to learn anything technical - you have to build using it.

(2) An Injest Feed - When you read something, put together a process to preserve and organize what you take in: (a) Organize the information against some current or future learning project. Direct your learning with intention. (b) Capture the interesting parts for later study. One direct output of reading should be notes and review cards.

(3) A Review Process - I use a combination of Anki and Readwise. To review them later.

(4) Personal Tooling - I do not try to keep it all in my brain. The review process is to keep things fairly fresh, but I'm only keeping the big points and indices in-core. The rest is out in my tools. Evernote, readwise, and anki are basic elements.

Then I set up software for specific tasks. I don't have to do much: just organize what I can get off-the-shelf and then organize it, with little bits of glue to do what I need. E.g., org-mode for writing and planning (I'm currently experimenting with integrating taskjuggler), calibre for book management, polar for injesting papers, etc.

--

For your list of topics, it sounds like you need to build a small go app to run on AWS, perhaps on minikube. That's all fine. Now put it together with a subproblem you want to actually solve. Say a prototype of something you think you should build at work, or just a toy you want to make for fun, or a startup idea.

I've focused on a process for learning instead of strategy because I've done this stuff for decades. You have to be efficient, strategic, and retain what you've learned. You need to have enough of it out of your head -- into text you can review and think about -- that you can continue to update your strategy as you go into the project. It's too easy to get flooded with technical minutiae if you don't keep the top-level objectives in front of your face. Keeping notes will prevent you from dumbly reading forum posts late at night, because you know there's no useful notes to be made from them.

Doing a few of these projects and not retaining their output is demoralizing. In absence of an intentional retainment plan, you'll remember whatever obstacles you hit more than the things you wanted to learn. Those will be muscle memory and feel good for a little while, but that memory will whither 2 projects later, and you've lost the point.

The feeling of heavy work and little work can burn you out. This is a marathon, not a race. Get your form right, take each step easy, and keep your eyes forward.

I've found it helps to watch 'state of x in 2020' type videos to get a broad overview, and weekly email newsletters can help stay on top of a particular area.

Apart from that the skill is in knowing what you need to know about something. For example I don't need to know the details of the latest .NET syntax to know that .NET Core runs on Linux, which was a pretty big shift in that world. But to a certain extent there's no alternative to putting in the hours. Reading different sources, practice, repetition, flash-card software are the keys for me.

Make a list of what you need to learn, do you’re best to to weight the list towards things that will save you time at work (so you have more time to learn new things again) and then make a study plan and execute daily. Even if it’s only 20 minutes a day, just make it happen.

Also the comment about learning fundamentals is invaluable advice. I’m going to learn more about b-trees now

My learning strategy involves three steps: consume, produce, and engage. Though they are self-explanatory, let me explain how I practice these.

When I decide to learn something new, I look for the best articles, books, videos on the topic. Google helps me out here. I devour them as quickly as I can.

Consuming gives you the illusion of understanding. I make those concepts my own by producing something. A blog post, a slide deck, an illustration helps me to contextualize what I learned.

Consuming and producing is like four blind men trying to grasp what an elephant is. Each has his model of the elephant, which is not a comprehensive picture. I share whatever I produced with others and seek their feedback. I triangulate my opinion. With the comments given by others, I can make a complete picture, at least closer to it.

I go deeper into this in a series of articles here: https://jjude.com/sdl/

From what I understand, you asked four questions in one: 1. how do you learn, 2. How do you decide what to learn, 3. How do you manage your learning time and 4. How do you handle the pressure of that huge mountain of stuff you don't know. I will try to break it down a little. My Job requires me to rapidly understand fields I've never worked in and try to understand as much as possible in very little time, so I feel like I can contribute to answering it. I am not saying my thoughts to this topic are the best TM, or particularly well thought through, but it works for me.

1. How do you learn: My learning strategy might seem a little weird but I'll explain it anyway. For me the first part about learning is about familiarity. If your brain sees to many words it does not know it subconsciously shuts down and you get frustrated/demotivated (at least for me). So you have to iterate over a topic in order to feel familiar with it's vocabulary. Just think of those Wikipedia rampages where you go deeper and deeper down certain words until you don't know where you originated from: that's because you are not familiar with the vocabulary of the field. So my first step is to learn the vocabulary of the topic by 1: reading a short book about the basics (or the first 100 pages or something) and 2: I find a place (online) where people working in this field hang out (e.g Reddit, HN etc.) and just read what kind of problems they have, which kind of words and tools they are using which kind of projects they work on. I do this daily, multiple times, and follow on things that really spark my interest and try to understand as much as possible. My brain works very interest based. I try to answer simple questions in forums, and try to get involved but only in simple stuff (since obviously I am just learning). At this point I try to apply the very basic things i've learned and iterate myself further by asking basic questions about stuff I don't understand etc. After having reached a certain familiarity with vocabulary and basics I try to explain why does tool X exist, what problem does it solve, what pros and cons exist. I think about how I would explain the necessity of X to someone who is not in the field. After that in the second phase I learn mostly like everybody else from books, online resources and just doing what I learn. But now I can read books a lot faster and with much fewer frustration because my brain is familiar with it, knows why X exists and which cool projects X is applied to. Thinking about it, my strategy is mostly tricking my brain into not being bored or overwhelmed.

2. How do you decide what to learn: I learn because my job requires me to be familiar with Y. That's one part, can't really change much about that. The second part, for me personally is purely interest based. I always try to learn concepts/methods instead of tools. Don't care if it is useful or you will ever really apply it, BUT: if I learned a useful concept instead of a tool, I will always be ready to apply it somewhere else. We humans are masters in generalizing things and applying concepts we have seen somewhere else.

Since you asked about HYPE-TECH-A vs something that truly interests you: I always in my life picked my interests not the hype, and it always worked out. If you are motivated to learn something you can gain knowledge several times faster compared to force feeding yourself something that you might apply maybe somewhere in the future.

4. How do you handle the pressure of that huge mountain of stuff you don't know:

Just have a good mental health. Be aware that staring to long into the abyss of stuff you don't know will never lead to anything good. You have to be aware of the things that you don't know, but let it give you a joyful humbleness instead of fear. Just think about it this way: you will never run out of interesting things to learn. The joy of learning will always be available. Your mind is not a commodity of your future employer, instead learning n...

If it's a tool, I find a book packed with practical examples, follow it for a few chapters to get the gist of it, and then build something with the tool. I toss the book away at that stage and look at online resources that would help me in a real-world scenario. Then I usually return to the book because later in the book you usually find best practices and similar. At the end, I improve those things I've built with best practices I've learned.

If it's something theoretical, I write down notes with it in a Q&A format, and then test myself by answering those questions using spaced repetition (at the time I wrote them, a few days later, a week or two later, and a month or two later).

> How do you pick a subject or tool to learn?

I have a list of tools I'd like to learn and then I tackle whichever one seems most relevant to me from the list. Currently on top of it is tmux, which I have a practical use case for. AWS is somewhere at the bottom of such list, because I can't think of a project that would benefit from knowing it.

I think one of the best way to learn something is by using it at work. That's it.

If learning is so important to you, for whatever reason, you should get a job that will let you use new technology to gain experience.

I just don't think it's possible to get to know everything in your spare time. Spend that time on something you actually enjoy or you will burn out sooner or later.

Unemployment.

I use 3-pass learning strategy: Mark, Drill, and Sweep.

Mark: Quick overview of the landscape marking key ideas/sub-topics.

Drill: Map task at hand to a sub-topic, drill as deep as needed to finish that task.

Sweep: If needed, systematically study the subject.

It is rare that I get to do sweep. It is "eventually" achieved through a lot of need based drilling.

I don't learn by studying (I'm just too lazy). What I do instead, is come up with a fun project that uses the technologies I need and work on that. Sort of like living in France for a while instead of hitting the books.

Currently, I need to learn HTML, JavaScript and Node.js. I've come up with project that uses a little computer (ESP32) to serve up a web page that controls a mechanical finger.

You won’t, can’t , and really don’t need to know everything perfectly. Just start with the thing that looks the most interesting / accessible to you. go down the rabbit hole. Come back up, go down another. When you start getting bored, start producing some stuff. there will always be opportunity costs no matter what you chose to do. Just try to enjoy what you are doing. Another trick is to copy someone you respect. Try to learn what they know. And when you know more than them, find someone else to copy. One day people will start emulating you.

1. Key ideas: I basically skim through blog posts and videos from conferences to be aware of key ideas in Machine Learning

2. Fundamentals: Parallelly, I take MOOC course every once in a while to learn fundamental concepts from first principles

3. Implementation: I either use the ideas I learned from (1) and (2) in a work project or write a blog post to make it concrete on my personal blog: https://amitness.com/

I get an idea, try to build it, Google anything I don't know how to do, launch it as soon as possible, usually get loads of users until everything breaks down, try to fix it, Google anyth.. etc.

It's completely reactive but it forces me to learn by doing.