Why the Rails founder automatically rejects 80% of Software Engineer applicants | Hacker News Reader

Why the Rails founder automatically rejects 80% of Software Engineer applicants

medium.com

11 pointschristf2411 comments

I keep lots of commented out code in my projects, usually with a dated explanation of why it was commented out. You don't want someone coming by later and trying the same thing that worked most of the time but was foiled by an inobvious edge case

That's not really the same, is it?

// The following approach (some psuedocode follows) will not work because of xyz.

Though I'd still prefer not to have that. With a VCS + bugtracker that contains info on how the fixes were arrived at, or very verbose commit messages, you don't even need this.

Agreed. It's definitely better than just commenting out code and leaving it there, but it could get super messy.

That requires future developers to check the VCS + Bugtracker diligently and somehow search for relevant issues. My method places the warning right where the mischief might be done

Isn't what version control is for? You could see how the code evolved by looking at its history and combined with meaningful commit messages you can easily identify the original problem and how it got solved.

When someone is changing a piece of code, how often do you think they will go through the commit history to see if someone else tried to do that same thing?

Commit history is very useful for forensics, and I strongly encourage writing useful commit messages, but if you want to say very clearly "Do not try this!", that shouldn't be buried in history, but be clear in the code itself.

That's not to say the best way to do that is just commented-out code, of course.

I personally would like just a comment in situations like that; not necessarily commented out code. If someone else had tried that and committed in the past, could link to the revision number in the comment.

Thanks for partially supporting my position :)

Do you just leave the code in the spot it was? Or do you move it up in the function comment? I've done that to also explain example use cases, and I've seen David do it in Rails core.

I'm not a Ruby programmer so maybe this is wrong for some reason. I leave it in place. With intelliJ you can collapse comment blocks so if you have a bad reaction to "messy" code you don;t have to look at it. Leave the corpse where it fell as a warning

Rather hire somebody who can resolve bugs and focus on the specific objectives and values, within given time-frames of a particular project than somebody who never writes code that might be "poorly indented, poorly named, and poorly scoped.", or containing commented out code also.

Reply on news.ycombinator.com