# When to take a Rails deep dive

DevFeed: [When to take a Rails deep dive](<https://devfeed.tech/articles/when-to-take-a-rails-deep-dive-26275.md>)

Original publisher: [Read original article](<https://www.justinweiss.com/articles/take-a-rails-deep-dive/>)

Author: Justin Weiss

Published: 2017-08-15T04:40:15Z

Content type: opinion

Language: en

Sources: [Justin Weiss](<https://devfeed.tech/sources/justin-weiss.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [debugging](<https://devfeed.tech/topics/debugging.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [data-modeling](<https://devfeed.tech/topics/data-modeling.md>)

Tags: [debugging](<https://devfeed.tech/tags/debugging.md>), [deep-dive](<https://devfeed.tech/tags/deep-dive.md>), [programming](<https://devfeed.tech/tags/programming.md>), [rails](<https://devfeed.tech/tags/rails.md>)

## AI overview

The article explains when developers should take a deep dive into a Rails topic: when unexpected behavior or recurring bugs reveal that their mental model is incomplete. It recommends focusing on a specific topic and building a deeper understanding to make better decisions and write more reliable code.

## Source excerpt

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