Hacker News new | past | comments | ask | show | jobs | submit login

I wonder if "boring" here just means "clear." I had a great case of this yesterday. We were reviewing a piece of code by someone that could have been better with a basic algorithm change. It did most of the right things but in the wrong order, sometimes on the wrong data, and did one major piece probabilistically were specific computation wasn't intractable.

The coder wasn't completely getting our explanation, but the code was so "boring" or "clear" that we opened up an editor, copy-and-pasted some blocks around added a few if statements and expected it to be basically functional. This was a complex algorithm and a complex change, and we offered provisos that we didn't know what that function returned so a "not" might have to go in front, and a variable name would have to be changed and one piece was going to have to operate on a new key in memcache, but it was basically there.

The point is, the code was so well-written that we could read it well enough to do this never having seen it moments before, and our resulting chopping was clearer to the original coder than 20 minutes of histrionics on a whiteboard full of formulae. That's how it should be. :-)

And for any haters in the crowd, it was all in Perl. So much for "write-only" complaints. :-)




In my coding, I'm starting to think it's better to write code that is wrong and clear than "right" and unclear. Because then you can understand it quickly when you come back to correct it later (note: including correcting the "right" code, due to bugs, problem change, etc).


coworker: This code is clearly wrong

6ren: Thank you


Shouldn't that be:

6ren: You're welcome.

?




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: