Your point about studying code & improving it in isolation is good. The weakest part of the analogy, in my opinion, is that in tactical chess puzzles there's actually a right answer.
On the other hand, if you have a chess puzzle but not its answer, you can still practice recognizing the tactical situation (hung pieces, checks, forks, pins, etc.) That's closer to what I was suggesting, and I still think it's useful: learning the jargon first, and then reading code and taking the time to describe it in terms of that jargon. The purpose isn't to "discover things you don't know", it's to concretely drill and internalize things you do know.
Sometimes you'll think something -- a particular brace style, a naming convention, a commenting convention, a design choice -- will make code better. But when you try it, it doesn't help comprehension or maintainence.
There is no substitute for honestly taking the time to make some code the best you know how, and then being stuck maintaining it for a fussy customer for several months. If you never had the time to do it right, you can deceive yourself about how good it might have been. But if you know you did your best, you have nothing to blame the inevitable mess on but your own abilities.
On the other hand, if you have a chess puzzle but not its answer, you can still practice recognizing the tactical situation (hung pieces, checks, forks, pins, etc.) That's closer to what I was suggesting, and I still think it's useful: learning the jargon first, and then reading code and taking the time to describe it in terms of that jargon. The purpose isn't to "discover things you don't know", it's to concretely drill and internalize things you do know.