I can't argue with you there. I think even better learning in my career has come from posting code on boards like this and having my peer's tear into it. It's also the hardest thing to do. Actually other than SQL I haven't coded for awhile. But I have found that people who post to boards and get peer reviewed are typically not the programmers who write silly things like

if 1==0

or if x==1 then <do>

elseif y==2 then <do>

elseif z==3 then <do>

etc. to unbelievable levels of depth when a case statement will do.

Anyway this is a big digression from the original article.

My summary is I don't think making the code as small as possible makes it clear. Making it clear means making it as obvious as possible what it is intended to do and then actually what it does. Personally I think parameter lists in the comment header are good if you put what the parameters are supposed to be unless it's painfully obvious from the name. empId hardly needs explanation but many things do. Depending on going to other places as your most important way of getting the information you need to understand code is not, in my opinion, writing cleaner code. That doesn't mean I don't believe in using source control and check in comments, I do. In fact I think you should check in small chunks so your checkin comments can be clear and succinct about what's been done to the code. But the reasoning that comments get out of sync because programmers don't think about them so SC is better is like saying, coders will always comment source control better than comments. I just don't think that's true.