Re: commenting sub procedures

Gary,

Obviously I'm talking about the basics here - if there's something 'weird'
going on, then of course it's commented. But I'd expect to only hire
someone who can figure stuff out. To the extent that I have had any
influence over hiring someone, I give them some complex (but not
*crazy*complex) code and give them 10 minutes to tell me what they
think it does.
They don't need to know all the details, but they need to be able to give
me a rough idea, ideally including something like "Well I'd need to see
what's in called procedures x, y and z to know more". Even better is them
asking "This looks complicated - why did you do it this way?".

I wouldn't think it's asking too much, but from experience it has been.
I've turned down some people who had great resumes but couldn't figure it
out. And I've pushed my company to hire people (including 2 Indian
programmers with imperfect English language skills (and who therefore might
not intuitively know some common English acronyms and prefixes)) who did
very well in this test and proved excellent developers.

It may not work for all, but it has worked very well for me.

Just sayin'. YMMV.

Rory

On Fri, Mar 23, 2012 at 4:29 PM, Monnier, Gary <Gary.Monnier@xxxxxxxxx>wrote:

Rory,

By comparison, in many of those cases, the procedure itself will have

minimal documentation, since any developer who has to maintain it should
know what they're >doing before they start messing with the code.

FWIW this is a dangerous attitude, in my opinion anyway. It presumes
someone thinks like you do and can understand your logic quickly. This may
not be true. Comments in the code, even to the point of pseudo-code, can
be of great benefit to those having to understand why you did something the
way you did.

Gary Monnier