I agree with you to some degree, but it needs to be said that _good_ code is very expressive. It should reveal the developer's intent clearly. "Doing a thing" is fine for amateurs or a quick script, but for large enterprise application development, it doesn't go nearly far enough. Good names, good function arrangement, plus everything else we should be studying needs to be applied well. If done well, it certainly should not take a half hour presentation to present a dozen lines of code. That tells me that the code is too complicated, too dense, too many levels of abstraction together, too much I have to keep in mind to understand some main idea. Very dense code is, more often than not, bad code.
I don't think reading codebases is an exercise worth doing often, but all the same good code should read like well written prose. It's difficult to appreciate that if an individual hasn't poked through a number of codebases of varying quality.
I don't think reading codebases is an exercise worth doing often, but all the same good code should read like well written prose. It's difficult to appreciate that if an individual hasn't poked through a number of codebases of varying quality.