41–50 of 72 posts
If it’s maths I’ll try to copy the book by hand and do the recommended exercises.
If it’s CS ill start with the labs/exercises. I use that as a guide to see what I am struggling with.
If it’s humanities, business etc - I’ll follow the CS path.
Find a reference or a sample codebase (which may be a tutorial or someone else’s project/blog or a by-example documentation) and copy, copy, copy, copy and copy. You always learn better by copying first and innovating later.
Predict how the the new language/subject should work according your current knowledge and iteratively improve your predictions based on subsequently being proven wrong again and again till you know all the good ways to do something and why this particular project/language/book chose to do it this way. Then pick up another book/reference on the same topic and repeat. Never trust a single source, always aggregate information and judge for yourself, only giving little weight to authority.
If you want to get really good at something you have to spam it. To that end find an IRC or discord channel meant for that topic and interact on the topic there as well.
2. Explore open-source code
3. Dig into language documentation
4. Hack together a working system
5. Refactor until there's a coherent system with a consistent analogy
A POC/Sandbox to play with in ways I don't need to worry.
Getting some hands on functioning code that I can break and see why it broke, so a good debugging configuration.
Documentation - During the 'calm' times I will go through the documentation and try to appreciate where the creator is coming from.
After all that, when I feel confident-ish. I will create another project using that particular library/methodology/advice etc and see how to improve for my needs.
This may not be the best/most optimized method but it works for me almost by osmosis!
1. Find the best book (or books) about the subject 2. Read it. Probably do some hands-on stuff while reading (e.g., writing simple programs if I'm learning a new prog. language; install a db in a VM and execute queries if i'm learning about dbs, etc.) 3. Let it sink 4. Read about the subject in blog posts, articles. Stuff like "best practices", or something like that 5. Let it sink 6. Come back in 1 year, and do it a…
I call this "compounding knowledge." I take any excuse to learn new skills, tackle new projects, and accumulate new information. After a long enough time, those disparate skills become complimentary and connected.
My analogy revolves around collecting keys that unlock future doors.
Top-down establishes the high level concepts, underlying motivations, etc. It provides a map of what there is to learn and a scaffolding upon which all new knowledge and concepts can be secured and contextualized.
Bottom-up is where the rubber hits the road. Because disrupting a system and seeing the effects of that disruption is key to learning, bottom-up is a very active and iterative process. Write the “Hello, world!” program, and then see what happens when you change the text, remove the semicolon at the end of the line, etc.
- Often people ask about things that I wasn't even aware existed. For example someone asked how to get Svelte Inspector to work, and I discovered a wonderful tool.
- You don't really understand something until you can sell/teach it to someone else. I had implemented Functional Core, Imperative Shell[1] a few times, so I thought I understood it. However, when I tried to explain why this concept was such a game-changer to someone not familiar with functional programming, I couldn't articulate it very well. Thinking about how to persuade them really helped me organize my thoughts about it.
How I read and parse informtion: 1. Print the page/article/book as pdf 2. insert printout in OneNote 3. Read printout on iPad: highlight important info, add my own notes on the side, add tasks if I need to look up sth 4. Collect my notes in OneNote page, look up tasks. If I am learning something new, I usually start with Wikipedia and grow from there. Lately, I am also using ChatGPT to look up stuff I am curious abou…
- Can you compile and run a basic program?
- Can you “Hello World” your own code?
- Can you effectively re-use your code via functions and subroutines?
- Are you able to effectively work with any OOP classes, enums, structs, and other types, if present?
- Can you create and manage libraries, that can be used by other programs?
- If the language supports it, can you use auto-documentation tooling to provide API and functional information?
- Can you properly debug code with tooling?
- Can you create test cases for your code?
- Do you regularly educate others on the use of this language?
- Are you a contributor to, or the creator of, this language?
1. Write a blog post about it. I'm an old school blogger and my best learning tool is to immediately start writing about it. I'll do this even before I've used the thing in question. Another writer here talks about producing versus consuming and that's the magic -- this shifts you immediately into being a producer. Most things you try and learn aren't that hard when you start actively engaging with the topic by writing about them.
2. Write test coverage. If it is a software technology then I'll start to use it by writing out the tests needed to use it. I find tests always make software technologies much more understandable because, inherently, they force you to think very atomically.
3. If I really, really want to understand something in depth then I'll create a side project about it or that requires it. Just for example I'm currently doing this as a way to force myself to build better web apps. I've chosen HotWrite and Turbo as enabling technologies and now I've got the core of a neat little app that avoids full screen redraws, uses CSS I actually understand and so on.