Have you ever found a Rails topic that didn’t make any sense to you?
Like, you thought you knew it, so you wrote some code, and something completely different happened?
Or you know you don’t understand, but you kind of know enough to get by, except you spend so much time fighting edge cases that you could have been an expert in it by the time you were done?
Well, what if it didn’t have to be that way? Wouldn’t it better to just know how things worked? To have a solid mental model of the problem in front of you? So you could just make the right decisions, and write the right code?
When I was first learning web development, sessions were That Thing: I thought I kind of knew them, but I didn’t. And my misunderstanding of sessions caused so many bugs that I was criticized, a lot, for the problems I created.
Soon, I realized I had to take time to actually understand how sessions worked. To demystify them, to make them not scary or weird. And eventually, to be able to guess how they’d behave – and to be right.
“Sessions” isn’t the only topic I’ve done a deep dive into. Data modeling, caching, metaprogramming, they’re all confusing things that are really easy to get to kind of work. But you’ll run into eternally hard debugging problems if you don’t understand them.
In Practicing Rails, I wrote about T-Shaped learning: When you have good baseline knowledge, but push much further into specific topics as you need to. Those pushes are deep dives, and they’ll help you solve huge problems over the course of your programming career.
When should you do a deep dive?
So how do you know when it’s time for a deep dive?
First, to do a deep dive, you have to know what you’re diving into.
Deep dives are most helpful when you’re dealing with a single topic. A specific thing you can describe in a word or a short phrase. SQL query performance. Sessions. HTTP Caching. Too specific, and you miss the interactions that make a topic so complicated. Too general, and you’re doing a deep dive into “Programming.” Which, I guess you kind of are, but that’s a deep dive you’ll spend your whole career on.
Next, you should do a deep dive in one of two situations:
-
You think you know what you’re doing, but something totally unexpected happens. You know in your heart that pushing that green button turns the hallway light on, but you push it, and the room collapses instead.
-
You know you don’t really understand something, and that’s been OK… But now, you’re fixing a bug, and everything you try causes more problems than you’re solving, creating new bugs as quickly as you’re fixing old ones.
These situations have something in common: You’ve just started to notice that you’re going in the wrong direction. And even though you hope you’ll turn things around, you’re starting to realize you’ll waste a lot of time struggling.
They’re both ways to help you sense, early on, that the way you’re doing things isn’t working.
So, the next time you run around in circles, battling edge cases to fix a bug, or the next time you’re floored by code you wrote doing something completely different than what you expected, remember the feeling you have. Get sensitive to it. That’s the feeling that’ll tell you it’s time to pause. To collect yourself. And to learn, deeply, that thing you now know you don’t understand.
But now that you’ve decided you need a deep dive, how do you go about doing it?