Ask HN: What is your learning strategy?

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>P.S.: My company is looking for experienced Deno developer, min 5 years of production experience. Unpaid internship position.

Start building the things that you want to build, and you&#x27;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 have a strategy. I call it &quot;Engine vs Power-ups&quot;.<p>The &quot;engine&quot; 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.<p>In contrast, &quot;power-ups&quot; 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 &quot;back-end as a service&quot; offerings, etc).<p>Keep in mind, the &quot;engine&quot; vs &quot;power-up&quot; 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.<p>The strategy I try to use is to spend most of my time working on the engine, but at key times when there&#x27;s an opportunity, I go all-in on power-ups.<p><a href="https:&#x2F;&#x2F;alchemist.camp&#x2F;learning-machine&#x2F;engines-powerups" rel="nofollow">https:&#x2F;&#x2F;alchemist.camp&#x2F;learning-machine&#x2F;engines-powerups</a>

My learning strategy involves three steps: consume, produce, and engage. Though they are self-explanatory, let me explain how I practice these.<p>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.<p>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.<p>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.<p>I go deeper into this in a series of articles here: <a href="https:&#x2F;&#x2F;jjude.com&#x2F;sdl&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jjude.com&#x2F;sdl&#x2F;</a>

This is for tech skills -- my learning strategy differs greatly for other types of skills.<p>&gt; 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>To the last 2 questions: I don&#x27;t really.<p>But to the first question: I read widely, but I also add an accelerant to the process -- Pluralsight. (or, insert your favorite screencast&#x2F;tech pedagogy site here)<p>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&#x27;m partial to learning by mimicry (at least at first).<p>Docs are good as a reference, but it&#x27;s tedious and slow to mentally parse step-by-step instructions and scaffolding code in docs -- there&#x27;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.<p>For instance, I tried learning K8S by reading blogs and docs but didn&#x27;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.<p>Downside: these sites only cover established technologies. If you&#x27;re learning cutting edge stuff, then they&#x27;re no help.

I think one of the best way to learn something is by using it at work. That&#x27;s it.<p>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.<p>I just don&#x27;t think it&#x27;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.

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.<p>You should rather focus on what you NEED to learn, don&#x27;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.<p>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 keep a running Google doc consisting of Things I&#x27;ve Learned, and append to it whenever something interesting or insight-generating happens in life or work (even if trivial, eg &quot;it&#x27;s really important that we review Product PRDs the same way we&#x27;d code review a pull request, I should write that down&quot;).<p>I review my now-very-long doc every few quarters and it&#x27;s an easy way to reinforce core concepts that I&#x27;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&#x27;s probably a better system for gaining &quot;wisdom&quot; as opposed to hard technical knowledge.

You don&#x27;t need to be good at all the things you listed. As a human you can&#x27;t be good at everything. You always need to balance between being average in a lot of topics and good in a few topics.<p>If you are able to land a job, it is means that you know enough as a software engineer.<p>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.<p>For example I&#x27;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&#x27;t know anything about before

&gt; On the other hand, as far as I see, I am supposed to know many of them.<p>Why do you think of that? were you hired as the person that knows all of them?<p>Remember that as software engineers, our job is to solve problems. It doesn&#x27;t matter what technology, language, or framework as long as you bring value on the table.<p>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.<p>Personally, I&#x27;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&#x2F;research next.<p>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&#x27;s not required though and you can demand from your employee to provide that time for you. I&#x27;m doing it because it&#x27;s my choice to do so.

You might find this useful:<p><a href="https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;learning-how-to-learn" rel="nofollow">https:&#x2F;&#x2F;www.coursera.org&#x2F;learn&#x2F;learning-how-to-learn</a><p>Personally, I usually try to get a job where they use the thing I want to learn.<p>Two years ago I landed a job in a company that was using Vue.js and Vuetify.<p>Recently just started in a company that&#x27;s doing Elixir and Phoenix. I&#x27;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.

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.<p>In short, if you produce more, you will automatically learn more.<p>Now, what to learn depends entirely on your choice, also for me, I am Ok to quitting if I don&#x27;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.<p>1: <a href="https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=EtJy69cEOtQ" rel="nofollow">https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=EtJy69cEOtQ</a>

I don&#x27;t learn by studying (I&#x27;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.<p>Currently, I need to learn HTML, JavaScript and Node.js. I&#x27;ve come up with project that uses a little computer (ESP32) to serve up a web page that controls a mechanical finger.

If it&#x27;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&#x27;ve built with best practices I&#x27;ve learned.<p>If it&#x27;s something theoretical, I write down notes with it in a Q&amp;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).<p>&gt; How do you pick a subject or tool to learn?<p>I have a list of tools I&#x27;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&#x27;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.<p>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.<p>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.<p>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&#x27;t try to go through the whole docs or tutorial. Search for &quot;react basics&quot;, 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.<p>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&#x27;t be bogged down by styling (CSS) or performance or anything. Just get it running.<p>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-&gt;implement-&gt;learn-&gt;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.<p>Maybe that, or I am simply naive.<p>As my distributed systems teacher used to say: don&#x27;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&#x27;s a concept that is similar to something you have learned before, if not entirely the same.

You could go even further and list things outside of the programming world which you would like to learn.<p>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.<p>In terms of the learning useful skills, I wouldn&#x27;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.<p>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.<p>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.<p>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 &lt;pick your own timescale&gt;, 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...<p>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&#x27;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.<p>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 ~&quot;next&quot; at any given time, toward a specific learning goal. So, someone doesn&#x27;t ever feel a need to stay up with everything, because knowledge is growing so fast anyway, just what comes &quot;next&quot; at any given time. With anki-like features built in. Something like wikipedia plus low-level computability of all the info stored. I haven&#x27;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 <a href="http:&#x2F;&#x2F;onemodel.org" rel="nofollow">http:&#x2F;&#x2F;onemodel.org</a> .

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&#x27;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 &quot;thoughts&quot; and an entry for &quot;lessons&quot;. 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&#x27;t force myself to come up with lessons if there aren&#x27;t any). Generally, if I struggled a lot with something I&#x27;ll pull lessons out and if it was easy I may not have anything in the lessons section.<p>For example, last year I started using python more at work. I&#x27;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.<p>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.<p>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.<p>Mark: Quick overview of the landscape marking key ideas&#x2F;sub-topics.<p>Drill: Map task at hand to a sub-topic, drill as deep as needed to finish that task.<p>Sweep: If needed, systematically study the subject.<p>It is rare that I get to do sweep. It is &quot;eventually&quot; 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,<p>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.<p>Understanding how some container or faas systems work (instead of their API) is h enough to understand most of them.<p>Understanding how some distributed noSQL systems work is enough to understand whats capabilities most of them will have, and their limitations.<p>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.<p>Everything I&#x27;ve learned came from trying to figure out how to implement something and then how to improve that implementation.<p>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 &#x2F; 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<p>2. Fundamentals: Parallelly, I take MOOC course every once in a while to learn fundamental concepts from first principles<p>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: <a href="https:&#x2F;&#x2F;amitness.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;amitness.com&#x2F;</a>

whats your objective in learning all those things?<p>&gt; I&#x27;m afraid to fall behind the industry.<p>Do you mean you are worried about not being able to pickup another job if you lose your current one?

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.<p>I got what all I mentioned above.

Learn to learn. Step 1: learn self-hypnosis.<p>You brain is the most sophisticated information processor in the known universe but it doesn&#x27;t come with a manual. Some manuals have been developed and published.<p>(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&#x2F;think) with comprehension and retention.)

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&#x27;t know. I will try to break it down a little. My Job requires me to rapidly understand fields I&#x27;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.<p>1. How do you learn: My learning strategy might seem a little weird but I&#x27;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&#x2F;demotivated (at least for me). So you have to iterate over a topic in order to feel familiar with it&#x27;s vocabulary. Just think of those Wikipedia rampages where you go deeper and deeper down certain words until you don&#x27;t know where you originated from: that&#x27;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&#x27;ve learned and iterate myself further by asking basic questions about stuff I don&#x27;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.<p>2. How do you decide what to learn: I learn because my job requires me to be familiar with Y. That&#x27;s one part, can&#x27;t really change much about that. The second part, for me personally is purely interest based. I always try to learn concepts&#x2F;methods instead of tools. Don&#x27;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.<p>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.<p>4. How do you handle the pressure of that huge mountain of stuff you don&#x27;t know:<p>Just have a good mental health. Be aware that staring to long into the abyss of stuff you don&#x27;t know will never lead to anything good. You have to be aware of the things that you don&#x27;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.

I get an idea, try to build it, Google anything I don&#x27;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.<p>It&#x27;s completely reactive but it forces me to learn by doing.

My learning strategy has a few parts:<p>(1) Projects as the top-level structure. [Lookup: Ultralearning - a book&#x2F;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.<p>(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.<p>(3) A Review Process - I use a combination of Anki and Readwise. To review them later.<p>(4) Personal Tooling - I do <i>not</i> try to keep it all in my brain. The review process is to keep things fairly fresh, but I&#x27;m only keeping the big points and indices in-core. The rest is out in my tools. Evernote, readwise, and anki are basic elements.<p>Then I set up software for specific tasks. I don&#x27;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&#x27;m currently experimenting with integrating taskjuggler), calibre for book management, polar for injesting papers, etc.<p>--<p>For your list of topics, it sounds like you need to build a small go app to run on AWS, perhaps on minikube. That&#x27;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.<p>I&#x27;ve focused on a process for learning instead of strategy because I&#x27;ve done this stuff for decades. You have to be efficient, strategic, and retain what you&#x27;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&#x27;s too easy to get flooded with technical minutiae if you don&#x27;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&#x27;s no useful notes to be made from them.<p>Doing a few of these projects and not retaining their output is demoralizing. In absence of an intentional retainment plan, you&#x27;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&#x27;ve lost the point.<p>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 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.

&gt; Liking the idea of being a novelist is not enough; <i>you have to like the actual work of novel-writing if you&#x27;re going to be good at it</i> ; you have to like making up elaborate lies. [0]<p>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&#x27;t like PG&#x27;s novelist example, consider bodybuilders. They don&#x27;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 <i>love</i> it, and they would probably continue to do so, even if it they ceased to care about looking good.<p>Once you set a non-trivial target (&quot;I&#x27;m going to learn French&quot;, &quot;I&#x27;m going to become a competent C programmer&quot;, &quot;I&#x27;m going to work through the exercises in TAOCP&quot;) you need to establish a path that is intrinsically enjoyable. Your end goal is <i>years</i> out. If it&#x27;s the only thing that&#x27;s keeping you going, you&#x27;re going to quit in favour of more immediately rewarding activities.<p>My first second-language-learning experience - French classes at a community college - was unsuccessful, for a rather simple reason: I didn&#x27;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.<p>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&#x27;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.<p>Once I started asking &quot;what is most enjoyable way to make this happen,&quot; 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&#x27;m reading a mystery, and I have about half my 1on1s in Swedish.<p>[0] <a href="http:&#x2F;&#x2F;www.paulgraham.com&#x2F;love.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;love.html</a>

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&#x27;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.<p>I do broad learning constantly, several hours a week, and it&#x27;s mostly fun.<p>Deep- occasionally I&#x27;ll do a deep dive into a new technology that I learn about I&#x27;m doing my broad learning. This happens because I&#x27;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&#x27;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&#x27;t too become an expert, but just to be able to accomplish work in the new technology.<p>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 &#x2F;a new project or team I&#x27;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.<p>As for your concern about being up to date on every single technology that might be listed on a job description, don&#x27;t be. Most job descriptions are &quot;aspirational.&quot; Few hiring managers expect to be able to get the &quot;perfect&quot; 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&#x27;s rare<i>. If you understand what my tech stack is and how it relates to what you know I&#x27;ll forgive a lot if specifics.<p>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&#x27;s actually important to know. On top of that, when you are ready to transition it&#x27;s a pretty easy to ask &quot;hey, I&#x27;d love to work with you &#x2F;work with you again, is your team hiring?&quot;<p></i> the last &#x27;perfect&#x27; resume I got ended up being a legendarily bad interview, something my interview team jokes about imternally. Poor dude couldn&#x27;t answer a single question correctly and we are pretty sure he just fabricated large parts of his resume.

I&#x27;ve found it helps to watch &#x27;state of x in 2020&#x27; type videos to get a broad overview, and weekly email newsletters can help stay on top of a particular area.<p>Apart from that the skill is in knowing what you need to know about something. For example I don&#x27;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&#x27;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.