In the same way, the best coders seem to absorb sections of code at one gulp.

I might comment more later, but I just wanted to thank you for that nugget. I find code hard to read when it is spread out too far. The oft-praised practice of putting your braces on lines by themselves, separating your blocks with blank lines, and putting multi-line comments all over the place yields code that I have a terrible time following. I have to stop and read it a line at a time, remembering more and more lines until I can collapse them into a concept.

I love a nice tight subroutine whose entire code fits on a 40x80 screen. I like end-of-line comments that don't break up the code and trip up my eye. Complex things should be explained outside the code of the subroutine.

These attitudes of mine are always interpretted as some rebel hacker sickness. My primary job for years was reading other people's code. The hardest to read code is poorly designed code. But the number two worst problem is code that is so broken apart that you don't have a complete, useful concept in one piece. Adding vertical white space is a good idea if you have a 300-line routine. A much better idea is to factor out the conceptual chunks into reasonably-sized routines.

Yes, if you go looking at the code I post on PerlMonks you will probably find much code that is too compact. That is the fun of Perl and PerlMonks. I avoid many forms of compactness in production code because I know the next guy might not be a great coder. But I hate the waste of vertical space that is so often demanded.

P.S. I think of "coder" as a term for a warm body that can produce functional code if you don't require any deep thought, design work, etc. from them -- just the opposite of your take on things. The use of "coder" as a compliment seems more a slang and usually requires an extra adjective. But that is probably just me being out of touch. :-}