Maybe fixing a bug just spawned a dozen new ones. Or your code breaks in such a weird way that you wonder if you really understand it at all. You think it’s time for a deep dive.
But knowing you need to dive deeply into a topic? That’s only step 1. How do you actually learn a topic down to its fundamentals? How do you learn enough that it comes naturally to you?
Where do you start?
There are a lot of places you could start your learning. But when I need to learn a lot about a topic quickly, books are my favorite place to start. For example, if you’re doing a deep dive into git, a book called Pro Git is probably exactly what you’re looking for.
Books are great for deep dives because they’re comprehensive: Most medium-sized topics are pretty well covered by a 200–400 page book. At the end, you might not be an expert, but you’ll have a pretty good understanding and solid fundamentals to grow from. That’ll help if you decide to move on to reading source code or specs.
But maybe you don’t want to buy a book. Or a book on your topic doesn’t even exist. When that happens, where else can you look?
Official documentation is a good alternative. If you’re doing a deep dive into a single part of a framework like Rails, or a web technology like OAuth, official docs are an especially good match.
For projects and frameworks, something named “The X Guide(s)” is your best bet for starting. For example, I often recommend the Rails Guides for new Rails developers, and the Elixir Guides are a great place to learn how to write Elixir code.
But while guides are more comprehensive than, say, a blog post, they aren’t totally comprehensive. Instead, you can use the guide as a jumping-off point to the reference documentation, like RDoc.
Reference material is hard to understand if you don’t have a way to put all those methods and classes into context. It’s just a mess of details with no real structure. So I find that references work best when you pair them with guides or books.
I say “almost nothing”, because there is one thing more comprehensive than reading official docs: Reading the source code. But reading source code isn’t like reading a book: it takes experience, practice, and guidance. So even though it will give you the most detail, it’s not where you should go first.
After deep diving through all this written material, you’ll have some open questions. So, ask them! The author of a library will usually have a better mental model of it than anyone else, and can walk through their thought process to help you out. Many authors of open source projects and frameworks make themselves available through Slack or IRC. You can usually find details on project pages.
If you don’t have access to those people? You can still ask. Ask your colleagues, or more senior devs. I’m surprised at how often asking a single unanswered question to a friend will make everything else click into place.
Once you know you have to do a deep dive, there are a few places you can start. Here’s the order I’ll usually follow:
- A book, or an official guide
- The official reference documentation (like RDoc) or a spec / RFC
- The source code
And I’ll fill the gaps by asking questions. It’s not the fastest process, but it’s the best combination of breadth and depth that I’ve found so far.
Do you regularly do deep dives? If so, I’d love to know what resources you’ve found most helpful. Leave a comment and let me know!