I'll probably go back and update the article at some point.
Background on the book Ultralearning. It was written by Scott Young who went viral for doing his MIT challenge, to teach himself the MIT CS coursework within a small amount of time.
I would expand on the post and focus on the concept of direct learning. That is, if you're not really practicing a skill in the way you're going to use it in an actual real life situation then it's less optimal.
The example he gave in the book and I totally agree with is learning a language. People look to apps like Duolingo where you're working to recall vocabulary and language in a way that's much different than when speaking.
This isn't to take anything away from doing drills wherein you focus on a specific subset of a skill, like say, free throws in basketball.
The approach I discovered myself and outlined in this post is really a drill for doing code reviews in a language you're learning and learning idioms and patterns from the community. People don't usually look at these aspects because usually the advice is to build a project you're passionate about.
I'm bad at finding side projects to build from the ground up that I'm "passionate" about. I have a couple of drills to work on coding more actively than reviewing code. I take an open source library that I'm interested in, take the tests and write the code to make the tests pass. Or vice-versa where you write the tests for a library. You can make this as big or small as you'd like. I'd start with either a function or a module that's interesting.
This way you zero in on the coding aspect and you don't worry too much about designing the interface since it already has tests. It's also much more real world than doing leetcode algorithm problems. I was taking this approach when I was working on learning how the raft consensus protocol worked.
I would not edit the post in any way, leave it as it is. But I would love to read a follow up. You can link to that new post from that old one.
For me your article is a revelation, didn't realized that I can just read old PR to check how to contribute to Open Source project. I've never read this advice in any guide that show how to contribute to FLOSS and I'm working on Open Source for more than 10 years (I'm sometimes read about how to get started, when I was starting with OSS, there were no guides like this).
I would give this advice to anyone that that want to contribute, it's even more important than looking for good-first-issue or help-wanted. This should be first thing the person do when trying to contribute. Look at old PR.
For me learning new language is side effect. You always learn when you're practicing with real project and work with more experienced developers. It doesn't matter if you work on closed source program in your own team at work or on Open Source. But with Open Source there may be more people, and big project are usually created by very smart people.
Background on the book Ultralearning. It was written by Scott Young who went viral for doing his MIT challenge, to teach himself the MIT CS coursework within a small amount of time.
I would expand on the post and focus on the concept of direct learning. That is, if you're not really practicing a skill in the way you're going to use it in an actual real life situation then it's less optimal.
The example he gave in the book and I totally agree with is learning a language. People look to apps like Duolingo where you're working to recall vocabulary and language in a way that's much different than when speaking.
This isn't to take anything away from doing drills wherein you focus on a specific subset of a skill, like say, free throws in basketball.
The approach I discovered myself and outlined in this post is really a drill for doing code reviews in a language you're learning and learning idioms and patterns from the community. People don't usually look at these aspects because usually the advice is to build a project you're passionate about.
I'm bad at finding side projects to build from the ground up that I'm "passionate" about. I have a couple of drills to work on coding more actively than reviewing code. I take an open source library that I'm interested in, take the tests and write the code to make the tests pass. Or vice-versa where you write the tests for a library. You can make this as big or small as you'd like. I'd start with either a function or a module that's interesting.
This way you zero in on the coding aspect and you don't worry too much about designing the interface since it already has tests. It's also much more real world than doing leetcode algorithm problems. I was taking this approach when I was working on learning how the raft consensus protocol worked.