I have found that the secret (for me) is to manufacture some reason to read the code. Code is difficult to read from top to bottom unless it's done in a litera

I have found that the secret (for me) is to manufacture some reason to read the code. Code is difficult to read from top to bottom unless it's done in a literate style. Instead, it is much more pleasurable if you are jumping around reading code because you want to understand something. I find that editing the code makes a big difference. Find something to chage. Refactor something. Add a tiny (even meaningless) feature. This forces you to understand what the code is doing. That, in turn, forces you to explore the code and to read it. It also gives you a gauge to judge the code against. Why did they do it that way? What if I changed it? Oh, I see why the couldn't do it like that. Yes, their solution is quite nice. That kind of thing. I very frequently refactor PRs at work and show my refactoring to nobody. Usually it's 6 of 1 half a dozen of the other. However, it gives me an idea about how flexible the code is. Or I might start to implement the next feature that's likely to touch that code. Not TDD. Just sketching some code and seeing how easy it is. If you've never tried it, I highly recommend it.