Ask HN: What is your learning strategy? | Hacker News Reader

Ask HN: What is your learning strategy?

234 pointserkanerol99 comments

Hi all,

I am a software developer and I have been a part of the software industry for almost 5 years. I have trouble developing a learning strategy.

In the beginning, it was easy. I needed to learn the basics of things. How to write object-oriented code in Java, how to build a docker image, how https works, basic Unix commands, etc.

However, now, I feel that I need to know a lot of things. When I check my current skills, future goals, and job descriptions, the list of stuff I must learn is extremely long. AWS, advanced stuff in Go, distributed system theory, databases, queue systems, Istio, other fancy CNCF tools, networking in Linux, k8s controller patterns, oncall stuff, gRPC, authentication/authorization mechanisms, managing a REST API, scaling something with zero downtime, observability etc. I am already using some of these tools/techniques in my full-time job but it is impossible to experience all of them in a position. On the other hand, as far as I see, I am supposed to know many of them.

I am aware that my choices are going to deeply affect my path/opportunities in the future. For example, k8s controllers are a very niche field whereas being a skillful Go developer comes with more and more opportunities. To learn the theory of fundamentals is a relatively long-term investment.

Additionally, my time is limited. I am already spending some part of my weekends and nights to learn something new but it is very exhausting. I literally love developing software but it doesn't seem sustainable to me in the long run if I cannot develop an efficient/focused learning strategy. I'm afraid to fall behind the industry.

So, what is your learning strategy? How do you plan your time to learn something new? How do you pick a subject or tool to learn?

p.s. I am aware that having a full-time job that teaches you a lot is the most critical part of this strategy.

View on HN

The tech list you describe usually is handled by a whole team (or multiple teams), not by a single Jack-of-all-trades person. For that amount of learning material you must be a superhuman to retain that knowledge. Here comes the other problem: unless you are working on that tech stack actively, you cannot remember it all. You may learn it for a certain period of time, but will eventually forget it in a while. Even if you successfully manage to keep that info “fresh” in your mind, the hype train moves so fast that “the new cool thing” will render your knowledge obsolete. You learned Docker? Sorry, the world is moving to WASM containers now. Learn fundamentals. Learn only things based on YOUR needs. The interviewing process is broken. You cannot “hack” it by doing everything they require. Or: learn a laundry list of tech only to realise the company requiring them uses Angular 0.5 and some nightmarish practices. I remember top engineer in a high profile company saying how he would not pass the current hiring process.

P.S.: My company is looking for experienced Deno developer, min 5 years of production experience. Unpaid internship position.

5 years experience for an unpaid internship? Did you omit the /s?

Did you read his job opening? There's absolutely no part of it that's not sarcasm

Ironically, you're assuming that he knows what Deno is and how recent it is.

Deno is something in javascript-land that just popped up (I'm not sure what exactly what it is, since I haven't keep up about JS ecosystem since friday and everything has changed), so yeah it's a joke that they require 5 years of experience in it.

Unless they're trying to catch a time-traveler.

IIRC Deno is a new JS runtime built by the creator of Node and written in Rust that pledges to resolve some of the hairier issues with Node. It’s actually one of the JS projects I’m most looking forward to maturing.

sometimes sarcasm is like well written code self explaining :-)

Having gone through interviews for 100+ employee companies, I was expected to know it all. Haven’t done SQL in years? Got nailed. 10+ years of JS experience but barely any in React? Got nailed. Haven’t reviewed that one algorithm used in the interview? Got nailed. That’s just a few examples.

Interviews aren’t totally reflective of the job but one‘s got to pass the interview before getting to the job.

I believe lying to some degree must be done in order to meet the challenge of the modern tech job posting. Interviews do not reflect reality. I think we just need to demonstrate competency of core concepts, get the job, and then rise to the occasion as fast as possible.

If an industry demands the impossible, let's pretend we can do the impossible as well, and let reality be somewhere in-between the two. Being honest here only allows for the dishonest to succeed, so let's join them in mass self-deception.

This only works if you're ready to "download" the information you need once you're given the job though!

> The interviewing process is broken.

Bingo to this. The sad part of the engineering world is that most companies are looking for that unicorn developer that just so happens to have used their exact tech stack. Oh and they also need to be able to optimally solve CS problems on the spot in a high pressure, time crunch situation.

And most fail to realize that if I was a unicorn, I would likely be working at one of 200 or so companies or my own gig..

So anecdote time. This is my one experience talking to management all the way up to the core "founding" members of a company I worked at once. They were trying to hire rapidly during a heavy scaling period of the company. However, the skill set they needed (actually required in this case) to run their new locations was indeed looking for unicorns. These people existed (I was one of them), but the ones they managed to find who also passed their interview process declined offers. I understood why - the market had shifted a lot and even with a subset of the required skills, these people could find higher paying, less stressful work. The value prop of the potential options also had significantly fallen.

I had multiple conversations where I brought this up, yet for some reason, those in the founding group simply did not believe me. Who would turn down the chance to work at a hot startup? They had joined for far less and during far more stressful conditions. What's being offered now should be more than enough, right?

I came away from those meetings and that company learning that some founders don't realize that unicorns, like themselves, are often the type to do exactly what you said rather than join them.

>They had joined for far less and during far more stressful conditions.

The classic chicken & pig scenario.

Your company executives are retarded.

Please don't post unsubstantive comments here.

https://news.ycombinator.com/newsguidelines.html

Unpaid internship... That's bullshit in 2020.

Edit: I missed the sarcasm. My bad. It's not possible to have 5 years experience with Deno. Leaving this here ...

I think you missed the Sarcasm. Deno 1.0 was released last week. Nobody has 5 years experience.

Wtf. Didn't a stable release of Deno just come out this month?

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.

How do you make sure you aren't hitting a local optimum of sorts where you implement a solution that has terrible side effects you simply aren't aware of (yet)? This seems to happen when you 'learn along the way' rather than start with a deeper learning upfront?

By deliberately selecting your objectives and evaluating possible solutions based on those objectives. If the objectives are unclear when you start (e.g. your objective is achieve a certain level of perfomance but you don't know enough to know what you can adjust, or how you can measure, or what delivers the most gain for least effort), I just get started and revisit it once I have something basic going.

Often, a basic, naive solution will give you the understanding and domain knowledge you need to be able to read what others have said about the same problem.

It also allows you to more easily dive into the solution as implemented by popular open source projects. Even if they don't write about it, you can often learn a lot from the code -- even more if the rationale is written in comments in the code.

For example, let's say you're contemplating how to implement an audit log for your product. You've never done this before, but you're experienced enough to know that you might hit unexpected hurdles (such as features that are difficult to implement) well into development, or maybe after deployment. Something you might do is research commercial open source products which have an audit log, and read their code to understand how they did it and perhaps why. Another way you can figure out the rationale is by looking at their full set of features and asking yourself how might each feature be implemented in an alternative implementation. If alternative implementations don't work well with this feature, this could provide an answer for why they chose this implementation over the other. And then finally, you can ask yourself if you need these features, which brings you answers to the original question of what are your objectives.

Or the short version: there are indirect ways to learn from the experience of others. Looking at a battle-tested implementation of a feature you want to add is one -- and it's perhaps even better (= more enlightening) than reading some blog posts you might find.

Anything you can come up with is a local optimum if you zoom out enough. If it gets the job done, no need to worry about that. If it doesn't, refactoring it will be a good learning experience.

Yes, when you're leaning something you have to constantly refactor. It's part of the fun. You don't have hard deadlines so you don't have to get it right at the first time.

I do that partially by focusing explicitly on a single objective like performance or test coverage.

In reality you need to compromise, but by keeping the scope of learning projects artificially small you learn a lot about that one aspect and the trade offs involved.

For example when I wanted to learn more about testing for front end applications in Angular, I wrote all types of different tests for a small sample project. By doing that and reflecting on how I could incorporate all those tests at work, I learned a lot about structuring my code to be more testable, when and how to use mocks, Angulars built-in testing utilities and much more.

By going very narrow it's easier to go deep. You won't learn about all the side effects and interactions with decisions in other areas, but at least you know more options and can try to find a better optimum.

Yes, by always working on the most interesting problem available to you, you have an endless fountain of your most valuable resource: motivation. A sufficiently motivated problem is sure to be solved because there is no incentive to quit. All of the greatest insights come from sufficiently motivated problems. There is no great science without a fire.

"I have no special talents. I am only passionately curious."

I think this is a big part of it. At work, I am coding to one platform.

For my personal projects - I set up the Linux server, I set up the MySQL/MariaDB instance, I design the database schema which follows first normal form, second normal form. I design the REST API in Python, then I get to my normal job of coding an app for one platform. Plus I do the graphics, which normally the design group does. I also do the advertisement on Google Ads etc., I pay the bills and do the accounting and so on. So it goes beyond even tech skills.

Thomas Huxley said a good liberal education is to know something about everything and everything about something. I am not an expert in creating ads on Google, Twitter etc., but I have done it and know something of it. Same with sizing or dropping graphical icons. Or designing a database schema. Or figuring out my side project cash flow, profit and loss, having my accountant help me set up an S corporation. This is all the knowing a little something about everything.

In my day job I primarily use one programming language to target one platform. In this subject I go deep and really try to learn as much as I can. This is what my main focus is on, learning the language well, and learning the platform well.

I should also point out, the smaller a company is, the more hats you will wear. I worked at a small company where I wore not only a programmer hat but a devops hat. I set up Google Cloud, Firebase Firestone, Apache web server, and wrote and modified Python scripts. At a larger company (where I am now), 99% of the time I do none of these things (actually they like I have these skills and can interact with our devops team). It doesn't take long for specialization to kick in either, by the time of the second tech hire you're already dividing up work. It is important to know your main focus well on job interviews though.

I have a strategy. I call it "Engine vs Power-ups".

The "engine" is very core, broadly useful things you learn (or in this case do) that will help you not only now but over the long term. In terms of learning this would be things like mathematics, a foreign language, sales, writing, interpersonal skills, CS, etc, which will still be valuable in 50 years. In terms of your tech stack choices, this would mean technologies that will be easier to maintain, require fewer updates in the future and have a sufficient level of performance.

In contrast, "power-ups" are extremely useful right now, but not so broadly applicable or evergreen. In terms of learning, this means things like the knowledge of the hottest social media growth channel of the moment, frequently changing JavaScript frameworks, popular 3rd-party tools and platforms (i.e. Firebase APIs, Auth0, various "back-end as a service" offerings, etc).

Keep in mind, the "engine" vs "power-up" concept is more of a spectrum than a dichotomy. Learning a programming language, an OS or an open source protocol is somewhere in the middle. The knowledge is probably good for 5 years, but maybe not 30.

The strategy I try to use is to spend most of my time working on the engine, but at key times when there's an opportunity, I go all-in on power-ups.

https://alchemist.camp/learning-machine/engines-powerups

That's neat -- since it's pretty much the same way I think of self-learning.

Sometimes you need to just go read up on discrete math, or theoretical stats, or algorithms in order to level up your fundamentals. Then you get to go 'spend' that on cool shit.

I finally started learning tensorflow the other day, after ~3 years of studying math/stats (while working full time) so that I could actually reason about tensorflow (note: I'm using TF for specific purposes, for something like computer vision the level of stats I studied isn't necessary)

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/

This is for tech skills -- my learning strategy differs greatly for other types of skills.

> So, what is your learning strategy? How do you plan your time to learn something new? How do you pick a subject or tool to learn?

To the last 2 questions: I don't really.

But to the first question: I read widely, but I also add an accelerant to the process -- Pluralsight. (or, insert your favorite screencast/tech pedagogy site here)

Pluralsight has videos that are of high pedagogical quality -- low or variable quality sites are a waste of time -- because instructors are curated (and I hear, auditioned). Sometimes I just want to see how something is done by an expert. I hate to admit it but I'm partial to learning by mimicry (at least at first).

Docs are good as a reference, but it's tedious and slow to mentally parse step-by-step instructions and scaffolding code in docs -- there's just too much context switching for my liking. Much easier to watch a video at 1.5x speed, where someone is doing it and explaining at the same time.

For instance, I tried learning K8S by reading blogs and docs but didn't really see how everything fit together until I watched some videos of an expert actually explaining and assembling stuff starting from zilch all the way to a working setup.

Downside: these sites only cover established technologies. If you're learning cutting edge stuff, then they're no help.

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.

How do you balance learning something new with picking the right tech and making a mess of tech debt.

That's what I struggle with.

I'd say that most of time this is inevitable. It's hard to get something right the first time, because getting it wrong is part of the learning process.

That's why I suggested to find a company that will help you get an experience. Chance is that you're gonna work with people more experienced or smarter than you and they will support you.

So like I said, nothing wrong with tech debt, it's a byproduct in our industry that we just have to accept and deal with.

100% this. I have a decent resume and it’s from building stuff at work. Some of that is luck. Some of that is impressing managers and getting handed opportunities.

But a lot of it is just trying to solve problems around me without asking permission. A lot of people seem to start by asking for help. That is not how you get deep and broad learning.

My learning strategy is continually ask questions and never be satisfied with the status quo. Surely there is tech at your job that you could learn better. If you’ve mastered everything than it’s time for a chat with your manager or time to look for other opportunities. Nothing forces learning like being dunked in the deep end at a new job!

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.

I agree with this. I would add that if you are looking at the description of the next level up, that most of what is listed is excessive. If I look at my current job description, half of it is either not necessary or it's only necessary to understand the concept.

One other thing that I realized after being in the field for 8 years is that it is becoming more difficult for me to learn in general. When I first started, I could repeat almost all key pieces of information from a meeting verbatim.

I keep a running Google doc consisting of Things I've Learned, and append to it whenever something interesting or insight-generating happens in life or work (even if trivial, eg "it's really important that we review Product PRDs the same way we'd code review a pull request, I should write that down").

I review my now-very-long doc every few quarters and it's an easy way to reinforce core concepts that I'll want to share later via writing, mentoring, advising, etc. This question seems more technically focused, but this has been a great way to learn and internalize experiences. Granted, it's probably a better system for gaining "wisdom" as opposed to hard technical knowledge.

That's a good idea, better than just throwing random knowledge into Evernote.

Yeah it's worked really well I recommend it! One other note: the company I work at won the startup lottery and has grown very fast for the last 5 years, which allowed me to see multiple company stages and roles. I break down my notes by what I've learned by company stage and role as well (eg right now when I learn something about Marketing, it goes into the Marketing section of my Growth Stage "chapter"). My doc is ~50 pages so far and I honestly view it as a secret part of my resume at this point.

I also keep a list of blog/Quora/HN/Reddit posts that I've found helpful and timeless in a separate doc. This second doc is also useful, but a mess :-)

You don't need to be good at all the things you listed. As a human you can't be good at everything. You always need to balance between being average in a lot of topics and good in a few topics.

If you are able to land a job, it is means that you know enough as a software engineer.

If you want to learn new things, because they will help you build things for yourself, or are necessary to apply to a new position. Then think about a side project that would use those knowledge and build it, you will learn all what you need along the way.

For example I'm creating a jobboard now, I learnt how to build an efficient crawler, how to scale a db, regex performance, NLP PoS, NLP classification ... tons of topics I didn't know anything about before

> 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.

Mmm. And in concrete terms; put about half your efforts into learning soft skills (problem identification, how to give feedback without putting noses out of joint, how to listen effectively).

Mastering the black art of literally repeating what people say back to them is worth a bit more than any single technical skill.

"Mastering the black art of literally repeating what people say back to them is worth a bit more than any single technical skill."

As someone with 35 years of experience, this is the voice of wisdom.

Can someone expand on this? What is the value of repeating what people say back to them? Is it to show them that you understand what they are saying, or is it to allow the person to think about what they just said so that they might reevaluate it?

1. Show them you heard and understood.

2. Give them an opportunity to clarify if you didn't quite understand.

> 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.

What I observe in the industry is different. The market is so fierce and competitive and many companies (especially non-enterprise, medium-sized startups) are looking for people who perfectly fit their positions. Tools, domain, methodologies, etc.

oh yes of course my point wasn't that you could target companies with totally different requirements just because you think you can bring value.

But it's exactly what you said: because the market is so competitive you are far likely to get a job even by just focusing on the technology you are really interested in.

You might find this useful:

https://www.coursera.org/learn/learning-how-to-learn

Personally, I usually try to get a job where they use the thing I want to learn.

Two years ago I landed a job in a company that was using Vue.js and Vuetify.

Recently just started in a company that's doing Elixir and Phoenix. I've been trying to get into this tech stack for a long time.

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.

Now that you mention it, becoming friends with amazing programmers helps as well. I have one friend who complains about low latency and C++ programming all the time. By simply caring about him and listening to his frustrations, I am learning.

To pull this type of advice off consciously though seems to be quite tough, but it might serve as some guideline.

So true...there's a ton of 'tribal knowledge' locked up in all our heads ready to be released at any time...

100% A lot of the valuable knowledge isn’t written down somewhere and it doesn’t have an easy “key” for you to index it with. Shared learning is powerful

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.

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 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.

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.

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

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.

Let me give an example. If you want to learn React, don't try to go through the whole docs or tutorial. Search for "react basics", learn what props and state are and start implementing a simple to-do or a counter right away. You should complete this in a day. This will keep you interested.

Now, think of something more complicated - say connecting to a API and displaying the results in a table, just look into axios, copy paste whatever you can and get it running. Don't be bogged down by styling (CSS) or performance or anything. Just get it running.

Now, go through the official docs some more. You will be able to breeze through the whole docs in a couple of days. Always do the read->implement->learn->read cycle.

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.

> To me it seems ridiculous that employers can require such an amount of breadth and depth of knowledge.

To be quite honest, those are generally nice-to-haves instead of must-haves.

Yet, if within a pool of 20 candidates there are 2 or 3 which fulfill the nice-to-haves, obviously they are going to stand out among their competitors.

If you need to fill in positions and you stumble on a candidate that meets all your requirements, are you going to pass him over to pick the inexperienced candidate who has zero experience with your tech stack?

You could go even further and list things outside of the programming world which you would like to learn.

Maybe take a step back and consider that one of the useful outcomes of learning is maintaining neuro-plasticity, which may allow you to continue to learn with easy. This is why you may benefit more from learning some skill further from your existing set.

In terms of the learning useful skills, I wouldn't lean to heavily on job description, they are more like a companies wishlist. Occasionally, you can tick all the boxes, but that is not indicative of job performance or productivity.

Happy learning

It is fine to be interested in many things and to not to know everything about those things deeply. It is a matter of time. It is highly likely that if you put in another 10 years in this industry you will know far more about most things in your list.

It is a sign of open-mindedness to be interested in many things. It is a sign of maturity to narrow that list down to pursue them a bit more deeply, then discard what turned out to be not so interesting and pick new ones. The idea is to remember nothing is a waste of time - worst-case, you learn something about yourself while you were pursuing what turned out to be uninteresting for you.

I think of knowledge in terms of concentric circles, rings on a tree if you will. You start from the core and every month or <pick your own timescale>, you keep strengthening that foundation on topics you chose. You might choose an end-to-end project: data in a nosql db, expose that with a rest service, write a react frontend to consume that data. You can do this superficially without knowing what is REST or deeply about React. But if these topics interested you after the first project, you can do the same project in a better way the second time and so on...

Again, many things are a matter of time and if you try to rush them and try to be an amazing engineer in a very short time, it might lead to exhaustion. Reading Hacker News might make you feel people are doing amazing things - but remember at some point in time, those amazing people chose something, one thing, and pursued it. And for every person that's doing an amazing thing, there are ten who are in the process of slowly making progress.

As you and others point out well, nobody can know it all. My own solution to this is to (try to) spend some regular time learning, maybe keep a prioritized lists of possible future topics, and just try to prioritize tasks for the rest of the time in ways that will hopefully involve technologies with less churn to them.

But long-term, I have ideas for a generalized system of maturity models and known best practices, where a community can make interlinked lists of things to learn, that tracks prerequisites, and the best order to learn them in, with suggestions on what comes ~"next" at any given time, toward a specific learning goal. So, someone doesn't ever feel a need to stay up with everything, because knowledge is growing so fast anyway, just what comes "next" at any given time. With anki-like features built in. Something like wikipedia plus low-level computability of all the info stored. I haven't been getting as much done lately on it, (though I use it daily as a personal organizer), but I hope to in the future sometime. More on it at http://onemodel.org .

Two parts of my learning strategy are thorough learning and reflection. Thorough learning meaning, for important things I try to understand the system end to end by reading unabridged and quality documentation, taking the time to comprehend along the way, realizing that this is a slow process but in the long run worthwhile. Reflection meaning that after a learning period I'll take time to reflect, on the meta level, how things are going and what I could do to improve. I reflect by keeping a log, with an entry for "thoughts" and an entry for "lessons". In the thoughts section I just freeform write whatever I felt about the recent learning period and in the lessons section I summarize any actionable things from my thoughts, if any (and I don't force myself to come up with lessons if there aren't any). Generally, if I struggled a lot with something I'll pull lessons out and if it was easy I may not have anything in the lessons section.

For example, last year I started using python more at work. I've known python in the sense that I could write scripts in it and generally understand it, but my knowledge was mainly based on having seen python scripts, intuition, and Google searches - and mostly python2.

Putting my first principle into play, I looked at the python documentation and read it end to end. I tried to read one section a day, though some sections are more or less dense so that was very flexible. As I read I had a Jupyter Notebook open and played around with every concept the documentation described. When I was done reading I would spend a few minutes writing my notes as described above.

This took maybe 30 minutes a day, most days, for a little less than a month. On top of this I would randomly do leetcode problems in python and write python scripts at work, but at the end I felt I understood what I was writing and why in python much better.

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’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.

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

Build stuff. Pick out ideas and just build them to build them.

Everything I've learned came from trying to figure out how to implement something and then how to improve that implementation.

Rinse and repeat for a few years and you naturally improve.

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/

whats your objective in learning all those things?

> I'm afraid to fall behind the industry.

Do you mean you are worried about not being able to pickup another job if you lose your current one?

>whats your objective in learning all those things?

being a world-class software engineer

>Do you mean you are worried about not being able to pick up another job if you lose your current one?

no for the short term but yes for the long term. also, for me, having "a" job is not enough. I want to have a job that satisfies my intellectual curiosity and career goals.

Very simple. Whatever I learn, I share on my blog. The advantages are multi folds: first, you are making your self accountable in front of others by sharing your knowledge, which makes you to go a bit deep while learning. Second, you will be considered authority, even if you are not. Third, you are helping others to get out of the situation you faced earlier and last but not least, you get jobs and gigs.

I got what all I mentioned above.

Learn to learn. Step 1: learn self-hypnosis.

You brain is the most sophisticated information processor in the known universe but it doesn't come with a manual. Some manuals have been developed and published.

(At one point I was using RSVP (Rapid Serial Visual Presentation) to read 800-1000 words-per-minute (reading faster than my internal voice can speak/think) with comprehension and retention.)

How does self-hypnosis work/help?

All by itself it won't really do anything. You combine it with a story to achieve some specific result.

One metaphor for trance is that it puts you into a "debug mode" where you can patch your software easily.

One concrete technique that I've heard of (but not tried personally) is to go into a trance and practice some skill for many (imaginary) hours. This works to advance in skill without spending the hours in realtime.

Once you have general aptitude your ability to learn e.g. martial arts or playing a musical instrument is greatly accelerated.

A person I know had learned the Ukulele and someone asked them about playing left-handed (this person is right-handed). He turned the ukulele over, closed his eyes for a few moments, opened them and played left-handed. He remapped the motions during those few seconds and didn't have to practice at all.

"Pretty neat." Eh?

Indubitably neat. What are some resources?

My college did a school wide seminar on RSVP. I remember we did a before and after reading speed test where the presenter had everyone raise thier hand and then lower it as he read said thier reading speed. I was in one the earlier batches of people to put thier hand down (the slowest readers)

After the RSVP training we checked improvement. I was also in the slowest batch. By myself. It turns out that if you have certain underlying learning disabilities then RSVP is ineffective. Huge let down, because I love reading and would love to read substantially faster.

Moral of the story- RSVP works for many, does not for a few, but don't get discouraged because I'm still happy and successful in my own terms.

You say "at one point" - why no more?

It's sounds crazy but I learned everything I needed to know.

22 days ago you asked HN how to learn Japanese.

My recent interest in learning Japanese doesn't contradict the fact that I stopped using RSVP years ago because I didn't need to inhale information that way anymore.

FWIW, I may well use RSVP as part of a trance-assisted program of learning Japanese in the future. The simplest method of learning a foreign language is to age-regress to a pre-linguistic age and then grow up again in a community of speakers over a period of a few days. Obviously you want to be selective of the parts of your psyche you regress (so e.g. no one has to change your diapers.) If you can't get a community of speakers willing to help you you can do things like saturate with TV in the language, and then polish up afterwards. Anyhow, even with hypnosis one can't squeeze blood from a stone. That's why I was asking about resources and communities.

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 new things should be your privilege and bring you joy.

Great reply! Just out of curiosity (that is, because I want to know), what about "3. How do you manage your learning time" ?

I haven't figured that part out either ;-)

Pomodoro has been helpful for me. Also, mind maps & Airtable have been useful for storing & retrieving notes & takeaways.

Simply, I think the hardest part of learning is knowing how to pick it back up next time than it is about actually acquiring a new concept. Creating continuity in learning means more if you intend to actually embrace continuous learning as a mindset

Thoughtful and useful response! I also agree on the need to build a dictionary for effective learning

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.

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.

> 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

Inspiring words! Thanks...

I didn't edit that well. "Heavy work and little progress" is what I meant.

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.

Unemployment.

Use Roam Research.

> Liking the idea of being a novelist is not enough; you have to like the actual work of novel-writing if you're going to be good at it ; you have to like making up elaborate lies. [0]

Something I wish I had realized 10 years ago is the importance of figuring out how to learn in such a way that I enjoy the learning process itself. If you don't like PG's novelist example, consider bodybuilders. They don't see going to the gym as some necessary evil that stands in way of looking good. They like going to gym. In fact, they love it, and they would probably continue to do so, even if it they ceased to care about looking good.

Once you set a non-trivial target ("I'm going to learn French", "I'm going to become a competent C programmer", "I'm going to work through the exercises in TAOCP") you need to establish a path that is intrinsically enjoyable. Your end goal is years out. If it's the only thing that's keeping you going, you're going to quit in favour of more immediately rewarding activities.

My first second-language-learning experience - French classes at a community college - was unsuccessful, for a rather simple reason: I didn't give a fuck. In the course, myself and a bunch of aspiring bureaucrats (I was living in Canada at the time, where French accreditation opens up advancement opportunities for government employees) met twice a week and did as little work as possible to get a passing grade. We did the usual second language learning things: memorizing the names of animals (as if we were all preparing for a career in agriculture), watching low budget educational films, and filling out verb conjugation worksheets. Our instructor was good - she could explain concepts clearly and managed to stimulate a fair deal of discussion. But she was bound to a curriculum that heavily emphasized grammar and a particular vocabulary, and neither could motivate me.

Last year I decided to learn Swedish. Instead of signing up for community college courses, I started taking private lessons over Skype. I found a tutor with whom I share similar interests. We discuss things we've read, our favourite tv shows, and philosophy. I also started reading American mystery novels in translation. It turns out this is a highly effective learning mechanism, because you have a lot of context. It works especially well if there is a series you like, for the same reason.

Once I started asking "what is most enjoyable way to make this happen," and stopped worrying about what learning methodologies are efficient, scientific, or conventional, I saw a lot more progress. I only reach for Google translate a couple times per page when I'm reading a mystery, and I have about half my 1on1s in Swedish.

[0] http://www.paulgraham.com/love.html

I actively think about three levels of knowledge that I need to acquire- Broad- keeping up with changes in the overall industry. At this level I'm just trying to learn all the new things that are popping up, when they would be applied, alternatives, and maybe strengths and weaknesses. I mostly use podcasts for this, supplemented by reading HN and other tech news, easier to read books (like the Phoenix project), tech conference keynotes and detailed schedules (there is a ton of information to be gained just reading what people are presenting on), occasionally attending a conference, and occasional community meet ups, if those start happening again.

I do broad learning constantly, several hours a week, and it's mostly fun.

Deep- occasionally I'll do a deep dive into a new technology that I learn about I'm doing my broad learning. This happens because I've identified it as a broad industry trend that I simply need to understand (containers and kubernetes a few years back), something that I sense might be applicable to a current or upcoming project (most recently React), or just because I'm interested (augmented reality.) I use a mixture of training courses (pluralsight and o reilly because work gives me a subscription, or vendor provided learning material from the likes of Apple or Microsoft) and some hobbyists level effort capstone project. This takes about 40-80h and I often do the project as part of a hackathon. I rarely do this level of learning more than once a year and sometimes less than that. The goal isn't too become an expert, but just to be able to accomplish work in the new technology.

Immediate- learning as part of my day to day job. This is learning I get from having to figure out tasks (deeply reading the docs of our current tech stack to figure an obscure error), to evaluate a technology or technique against our current needs, or to learn a new technology that is part part of the job /a new project or team I've joined. Most of this is one the job learning or learning from others on my team, but sometimes there are relevant trainings. There is no real time metric here- it just happens.

As for your concern about being up to date on every single technology that might be listed on a job description, don't be. Most job descriptions are "aspirational." Few hiring managers expect to be able to get the "perfect" candidate. What they are really looking for is high potential and a short ramp time. Sure, I might occasionally get a resume with experience in all 8 technologies I listed on a description, but it's rare. If you understand what my tech stack is and how it relates to what you know I'll forgive a lot if specifics.

On last thing on the job search and learning aspects of your career - keep your network up. You are 5 years in. Most likely there have been people you genuinely like that have moved on to different teams, roles, or companies. Reach out to them, find out how they are doing, what they are working on, chat about whatever you used to chat about. Trust me, people are happy you thought about them enough to reach out to them and are generally happy to talk. What your friends are working on should give you a good idea of what's actually important to know. On top of that, when you are ready to transition it's a pretty easy to ask "hey, I'd love to work with you /work with you again, is your team hiring?"

the last 'perfect' resume I got ended up being a legendarily bad interview, something my interview team jokes about imternally. Poor dude couldn't answer a single question correctly and we are pretty sure he just fabricated large parts of his resume.

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.

Think of a side project you would enjoy that includes a handful of these technologies and start building it. You will hit snags as you go that require deep-diving into rabbit holes, and this is where the learning happens.

Reply on news.ycombinator.com