The worst epithet for a programmer: 'Clever'.

I used to hate sloppy programmers, but now I've come to see there's an even worse beast - the *clever* programmer. A sloppy programmer tends to make big, sloppy errors, the kind you find and can easily track down. A clever programmer creates the kind of subtle errors that you spend days tearing your hair out searching for.

For example, in the software I maintain, one particular feature searched a particular subset of transactions. The author of the feature realized you could improve performance by quite a bit if you just made one tiny assumption - that transaction IDs monotonically increase with time (that is, that transaction #X occurred later than transaction #Y iff X > Y.)

In 99.9999% of cases this is true - however, under certain very rare circumstances, a transaction may be created out of order. If that transaction isn't of the type that this feature considers, no big deal. And if it is, in that one in a million chance, this feature loops over a nearly correct (but not quite) set of results. It was a very clever optimization, but in the end it created a nigh impossible to identify bug that lingered for years. In fact, it was a fluke that it was EVER caught.

I think I actually prefer maintaining code from mediocre programmers the best. They're good enough not to make an endless amount of mistakes, and they're not clever enough to come up with the subtle 'shortcuts' that nearly always work, but occasionally explode in your face.

Hmm... that's food for thought, indeed. I do prefer to work with clever programers. And preferably clever than me. What I think really failed there was that the programmer didn't properly comment that optimization. That's definitely one of the reasons one should comment. So, your programmer... can't say he was only clever. He was sloppy too. And that is one exploding combination.

Incidentally, this goes to illustrate the reason why I'm adamant that one needs to document (document, not just comment) code for any mid to large size project. The simple fact programmers are forced to document the project, is bound to introduce some discipline into the team coding practices even when there are no guidelines established. It would also probably have solved years ago this problem you guys had.

I agree with mario, having an optimization like that is good if it's improves performance, but it should be documented. Also, it should have been easy enough to verify that the IDs were monotonic by comparing the last with the current and at least dumping a warning if an inconsistency was detected.

Besides, there is no 99.999% of the times. It is "case 1" and "case 2". You have to take care of both. Because the "out of a million" will easily happen if you make a million transactions. If taking care is documenting it that can be acceptable if it is clearly documented as "limitations".