Here's my attempt at outlining my current optimal learning path for most new things. You may be totally different, but this is what I've personally found optimal for myself.
After each of these steps, it might be enough to stop the learning path because you have everything you need. You may also want to skip a step if you're studying something adjacent to your current knowledge and probably can get away with jumping through quickly.
- Introduction to the Technology
For most tools you'll want to first know what it does so you know it will solve your use case. But you also want to know that it's well supported and idiomatic in the community so that you'll have reasonable support and others will be able to pick up your code easier down the road. You also want to know your size and speed considerations are met.
For frameworks or large tooling you may not need any of this, you might be diving in because a friend told you it's awesome. In this case the best first step is direct exposure to what it's like to develop with the tool. Nothing beats a good example to fiddle with or video of the same. Pair this with some explanation material about why things are the way they are and why it's so awesome.
- Solving a Problem
After first exposure you want to get something working end to end. A good base case tutorial works best for this when it explicitly doesn't include any fluff or explanation. Simple, up-to-date, easy to follow steps that anyone can follow without knowing what they're doing to get something working.
- Off the Happy Path
Once we've solved the base case problem, now we want to solve my problem. This means fiddling with things that are going to break. Now that I have exposure to the tool and have something working I'll want to break it and fix it over and over until it's doing what I want. For this I'm going to need all the options with clear APIs and reference material that's comprehensive and easy to search. It can also help to provide several working examples showing common use cases.
- Mastery
Now that we're up and running and know the 80% use case APIs we can solve all kinds of problems. At this point we look like some kind of magic wizard to non-engineers. But this is not enough. We want to look like a wizard to other engineers. Or, maybe we just have a super tricky edge case to figure out.
For this we dive into the github repos pull requests, github issues, and of course, read the source! Source code should be well structured and commented. If you find something difficult or confusing check if there's a contributing guide and make a pull request. You'll find most library owners are happy to discuss their code and often take suggestions for improvement (but don't assume they will).
- Tune in to Updates
It's essential to keep libraries and tooling that you're using up-to-date. If it's a big enough deal they may have a newsletter. Otherwise you may want to check in with forums or the community from time to time to double check that your knowledge about the right tool for the job is still the best path.
If the environment has shifted, head back up to #1 and begin again! This is the fun and beauty of engineering, there will always be a new and interesting thing to discover. The more we take this path the easier it gets and the more fun it is.
Top comments (0)