Writing code is really a modelling problem: you write down code that describes the model that's inside your head. When you're done, you're left with both workin

Writing code is really a modelling problem: you write down code that describes the model that's inside your head. When you're done, you're left with both working code on a hard drive, and a new, better model inside your head, because you understand the problem better. So, reading someone else's code can be like reading a model of something that has gone through dozens of iterations, where the bottleneck isn't really understanding "the code", but understanding the thing that is modelled, which the people writing the code are intimately familiar with, unlike you[1]. In my opinion, developing this modelling skill, in yourself, is much more important than watching the result of someone else exercising their modelling skill. A lot can be learned from observing someone else's solution, but this will always be secondary to learning how to craft your own. [1] For example: try reading compiler code. People have been writing compilers for so long that reading and understanding this code isn't about understanding the actual code, but about understanding how a compiler is modelled (scanning, lexing, parsing).