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