Prioritize What You Learn
Tech keeps changing at a fast pace. Skills can become outdated quickly, and it’s not easy to keep up.
It’s better to spend time learning things that remain unchanged over time, like CS fundamentals, programming languages, or frameworks.
On the other hand, avoid things that go out of fashion quickly, which generally is the case with tools and libraries.
Then, within a topic you're learning, you can optimize further. For that, classify its subparts into the following categories:
- Need to know.
- Should know.
- Nice to know.
- Edge case, only if it applies to you specifically.
- Useless.
Your categorization might change as your understanding of the topic becomes clearer, and that’s totally fine.
Now, the trick is to apply discipline and focus most of your attention on the “need to know” category, spend less time on the “should know'' category, and avoid like the plague everything falling into the remaining categories.
By the way, this applies to all fields and topics, not just tech topics!
Try doing this for the next topic you learn, and tell me how it feels.
JS world in a nutshell.
😂🔥
I'm a big fan of JIT learning.
I used to learn EVERYTHING about a topic before I delved into actually taking action on it, but that tends to not go so well.
Learning the bare minimum and then learning as I go, as I need it has worked best for me.
Where would you see Bubble.io in this way of thinking?
So, from the first part of my article, I would put Bubble.io more in the "framework" category, because once learned it's not very transferable to anything else.
To take a concrete example, if you have to choose between spending time learning Bubble.io or learning your first programming language, then go for the programming language.
This is not to say that no-code tools aren't useful: if this is what you want to specialize in or if it's the only way you have to build something, then go for it. But all those tools will change rapidly, some will go bankrupt and other will be acquired and killed, and once this happens all the time you spent learning that thing will be gone, whereas a solid foundation in software/programming will serve you your entire life.
Then if you do decide to go with Bubble.io or any other tool like that, within the tool itself you can prioritize your learning by spending time on the "must know" and "should know" rather than obscure features that look cool but that you probably won't use.
I hope this made sense and that it helped, if there's something you'd like me to clarify, ask away!
Great topic.
This makes me think of other applications for prioritizing your knowledge which I've used before. When I pick things to learn (tech or otherwise), I tend to do a ranking matrix of sorts, then apply something like you've defined above.
For example, let's say I want to pick which framework to learn next. I could evaluate 4 candidates based on popularity, community support, # of jobs available, and how enjoyable it seems to work with. Then within the one I pick, choose the topics based on the framework you defined above.
~ You are what you focus on. At first I tried to learn everything, but it's just a waste of energy.
That's correct I guess. But I'm not sure about that part:
"It’s better to spend time learning things that remain unchanged over time, like CS fundamentals (...)"
Is it something that you must know or should know? For many programming jobs you don't need much CS fundamentals. And skills not used vanish over time.
That's a good point, and I guess I could have been more specific about what I meant with "fundamentals."
I agree with you, and I'm not recommending that everyone should learn how to implement a B-Tree, but rather that some of the fundamentals of CS, like what classes of algorithms and data structures are out there, are things common to all frameworks, programming languages, technologies.
Being able to recognize classes of problems and knowing where to find solutions if needed is a useful skill by itself. And by covering this once, you can transfer it to new projects without having to re-learn it.
A counter-example would be knowing the ins and outs of the API of a specific library in a given language, because you won't be able to carry with you to the next project.
Does this make more sense?
Totally :)
I would like this comment twice if I could 😊.
Learning some fundamental computing concepts was a huge turning point in my career, and my code is undoubtedly better for it.
For example; I'll probably never need to write a whiteboard-interview-style binary search, but in my normal day-to-day I find that a lot of problems can be solved by that divide-and-conquer approach (where I would have written some ugly and slow loops before).
I agree other comments about just-in-time learning for things like language features or new APIs. However, I would encourage anybody to read about some common algorithms, data structures, protocols etc.
(so much so, that last week I started a newsletter about exactly this! https://www.baseclass.io)
True that. I'm self-taught and by far the hardest thing isn't the coding itself (as with many things, once you get fundamentals down, you're pretty much equipped to learn anything) but deciding what to focus on -- actively rejecting anything not aligned with your present goals is painful but crucial. I have the rest of my life to learn anyway, so it's just a matter of knowing one's priorities.
This is a really good point. Haven't thought about this at all. But it's really smart to both prioritise and actively avoid the things that can distract. I've spent sooo many hours learning and relearning pointless edge cases.
True. I always get sidetracked when learning something new but try my best to stay focused on the path in mind.
"Buy a book or read an article only if another guy recommends it, retweet it,..."
is a good way to filter all the shitty content on the internet
I try to spend most of my time learning the business case of the app that I'm coding, rather than libs and tooling. I've been using the same editor, programming language, database explorer and HTTP client for years now. This strategy will probably not get me a job at a Big Tech (I'm brazilian, so there is a huge entry barrier anyway), but this is what I enjoy doing and hopefully can turn me into a successful indie hacker in the future.
While I think this is generally good advice, it may be a bit too prescriptive. I’d say learn what you want to learn. Apply lessons as necessary to make money. There is overlap between learning and making money, but they are not mutual. It’s possible learn because you like all the new tech or just like learning new things while still keeping pace in the area that makes you money.
Good points; probably something that I should add to my book's first chapter (https://www.dev-concepts.dev/table-of-contents/#software-craft).
I touched on many things related to learning, but didn't put emphasis on the learning prioritization aspect. Makes a lot of sense! :)
Oh wow, this table of content looks very thorough. It feels like part #8 in the Introduction section could be a book just by itself.
Have you thought of how you want to distribute your book though? What's your plan to build up the audience so that when you launch you can make the sales you need?
I think you'll find this presentation relevant for your project: https://sidenote.me/note/0gcKho/nailing-your-first-launch-adam-wathan-microconf-starter-2018
Indeed, it could be !
The first part is about 90 pages long, and I think that section 8 is about 2/3 of that. I thought about splitting up the content of the book in different parts, but didn't consider just selling the first part on its own: https://gumroad.com/l/DevConcepts
I still have tons to learn about content marketing & distribution. It's a tough ride. Thanks for the link, I'll check it out!
Maybe it's a good idea :)
This comment was deleted 5 years ago