I was thinking.... most code I have looked at, certainly does not seem as simple to read as the kind of code the cattle drive promotes... maybe its just to complex for me to understand.... but I was curious.... does anyone have examples of code (not of cattle drive assignments, but other random stuff) -- that lives up to the readability expectations of the cattle drive?
I learn a lot by example, and thought it would be nice if I had some code files for more complex stuff (again, not cattle drive related), that I could look at to see examples of real life, good coding.
I think that examples of both things occur in the wild -- things that are simply messy and complex, as well as things that are actually quite clean, but where I (or you, as the case may be) don't have the requisite domain knowledge, or a good understanding of the language idioms, or the design patterns underlying the choices, such that it seems a lot more unreadable than it actually is.
Did that make any sense?
One of the best discussions of this concept at a meta-level is the chapter about The Dreyfus Model of Skill Acquisition in the book "Pragmatic Thinking and Learning -- Refactor Your Wetware" by Andy Hunt. I'll probably torture the concept by trying to explain it, but let me give it a go:
You can model the process of acquiring a skill as 5 distinct stages that you go through. Depending on where you are in the process, you need different types of approaches, different types of guidance, and different types of exercises. The stages have been given the names
One of the key concepts is that the amount of context a person is able to process and use becomes greater, deeper, and more fine-grained as they develop skills.
A novice can't deal with any sort of context; it would just throw them off, and frustrate and discourage them. Even more, it seems completely irrelevant. They need a sort of recipe to follow, something rule-based. They just want to accomplish the immediate goal.
An advanced beginner still needs to work with small chunks of things with very clear goals and many, frequent rewards. Big picture is still just confusing. In the context of programming, an advanced beginner might be able to look up methods in the documentation, but not really be able to troubleshoot much. Once something out-of-the ordinary occurs, they would pretty much be floundering.
A person who has developed skills to a competent level can begin to develop conceptual models, and can troubleshoot and problem solve. These are great people to have on a team because they are often able to work with beginners, both in terms of helping them out and communicating with them, while they also don't piss off the experts too much.
Someone who is proficient starts seeing a much bigger picture; they are driven to seek larger conceptual models, underlying principles, and they can self-correct. They have the ability to process enormous amounts of context, and start seeing what pieces of context are incidental, and which bits are important.
With experts this ability to see fine-grained details and make detailed distinctions has become so well-established that it is practically intuitive. To the rest of us it seems like magic. Wizards. Try to give these folks a recipe to follow, and their performance would degrade -- they are so deeply skilled that they instinctually know when to "break the rules" (especially when those rules aren't actually recipes, but principles). The experts are always driven to seek better methods.
The large majority of people in the large majority of fields seem to be perpetually stuck at a state of advanced beginner. These are the folks who say they have 15 years of experience, but it turns out they basically have 1 year of experience repeated 15 times.
In terms of your question of readable code, at the beginning when you start acquiring the various skills related to programming, there is a lot of big-picture context stuff that is simply unavailable to you. Even if people explain it, it just seems too confusing, and kind of irrelevant. Sometimes what really is an extraordinarily good design might seem unreadable to a beginner, because it uses a form of abstraction that makes it possible to solve the problem in a way that keeps things orthogonal -- but that also requires that you keep a larger picture of the system in your head at once while thinking about it.
I don't work in Java on a day-to-day basis, but I do have some examples of good, clean, understandable code in Ruby. Would you be interested in seeing that? (I'm going to have to go dig up some links, and I don't have time right now, but sometime this weekend I could certainly do that).