Continuing my quest for enlightenment I was curious to see how others approach examining projects from an educational standpoint. How do you determine the quality of the code you are reviewing? How do you decide if a design/technique is worthy of adoption in your own development?
It's a little hard to answer because part of the answer is that mysterious thing "elegance". But think of it this way: if it does something surprising, does it in a way that you could explain to a third party easily, and does it in a way that gives you pleasure to read, it's probably a keeper.
Expanding upon Seneca the Younger's response, I also look for efficiency and maintainability. If I see a piece of code with a lot of cut and paste, duplication and it's difficult to read, I tend to want to run away from it as quickly as possible. However, if it's clean, takes advantage of encapsulation and is easy to maintain that's when I know I'm looking at well written code.
I start out by reading the definitions. So say for OO code, I'd be looking at the method names and any blocks of comments describing what classes are doing. If I can't at that stage make head or tail about what is trying to be achieved I don't bother. If I can understand want they're doing, then I'd delve further into trying to understand how they're doing it.
At a high level, it's worth thinking about how you'd attack the problem. How you'd put together the methods that the other developer has put together. If you would define the class or classes under consideration in a different manner (responsibilities of classes).
That's where it gets interesting; it's easy to see the stuff you do know and how it's applied. What is more rewarding is seeing a technique you're unfamiliar with and see that being applied. For example, I remember looking over a colleagues code that used predicates in C# years ago and I was blown away by it. But it all clicked for me because I had done some functional programming in the past. Back in the day, I then used that to direct some reading and research into generics and anonymous methods.
Design and Techniques can only be truly learnt through bitter experience. Sure, said technique might look nice but without living with the various trade-offs design/technique decisions render it's hard to judge their true impact on your potential project.
It may be worth getting in contact with the people who wrote the code and asking about their experiences with the design decisions and techniques they applied.