It’s a little appreciated fact that being frequently wrong is (adjusted for a prioris) as difficult as being frequently right. For work, I once wrote a pixel classifier that, given an eye region of an image, would identify red-eye pixels. My classifier worked exactly as I intended it (ie, it was debugged) and yet it was wrong about 80% of the time. It was simultaneously a terrible and terribly effective algorithm.
For internal use, halve it. For external use, double it. Twice.
Imagine if I told you we were going to build a system to run our company. We’d use a domain specific language for the data-store, a second language for the back-end code which is run on a server written in a third language, a fourth xml-based approach to explain the documents, a fifth DSL to explain the styling of said document, a sixth language to write the front-end code, and a seventh “language” that is actually a library that makes the sixth language usable for our purposes. Would anyone think I was crazy?
Not that the web can easily be “fixed” but the existence of things like “reset.css” or tables vs css are not just excellent examples of the huge pile of sand people have built castles on, but more precisely, are a testament to a slaughtered paradigm.
I’ve looked at so many resumes. I try not to be biased but I’ll be honest. Long resumes are not as good as focused resumes. There isn’t some rule where over a certain length goes into the trash, it’s just that everyone gets about the same amount of time, and if yours is long, I’m more likely to miss something good.
Programming work, that is. This is why I never feel guilty if I leave 15 minutes early. I traded 15 terribly unproductive minutes for 15 terribly productive ones.