Brevity Is Important
by in Error'd on 2007-03-30Paul likes brevity, so he was discouraged when he received a really long and confusing error message. For those unfamiliar, "brevity" is defined by Merriam-Webster as a shortness of duration, or a shortness or conciseness of expression. To elaborate, it is the ability to describe a potentially complex idea in as quick a way as possible, leaving out extraneous details that would serve only to confuse the listener. If extra details are needlessly left in, listeners' eyes will glaze over and they'll stop paying attention to your message, which is why it is of the utmost importance that an idea be expressed clearly and quickly. Also, be sure to phrase your message in simple language. Overly uburbulous words will klologe readers if they have deblionic vocabularies. When trying to write humor, knowing when to end a joke is important, too. God damnit, here's your screenshot.

Document management is tricky. Personally, I'm anal about keeping documents organized in the most intuitive way I possibly can. In practice, though, that means I spend hours wringing my hands and ultimately wind up saving documents wherever I feel like saving them.
As we learned 
Ahh, to be young and in IT. In my younger days I was full of big dreams of being like the tech guys in action movies. You know, opening a socket to download a protocol so I can run a core dump on the secret agent's wristwatch.
Sometime near the end of the previous millennium, Neinhalt Sieger accepted a programming at a small software company that built Java-based games. Although today we realize that Java wasn't quite the ideal platform for videogames, back in the 90's it was all the rage. If your game wasn't made in Java, it might as well have been with made out of wood and rolled with a stick. 
Hi, I'm Jeff Atwood from 
Upgrading database server software is scary. I worked at an organization that spent just shy of a year upgrading Oracle 9i to Oracle 10g. But that's Oracle, and 
Remember being a kid, collecting Bazooka Joe wrappers to get a sweet knife that you could use to have dangerous, life-threatening fun with your friends? Then waiting by the mailbox for an agonizing six to eight weeks?


What was your worst production failure?
Congratulations, reader, you're now an IT "expert!"

Y2K. Second only to
If you’ve worked in this industry long enough, you’ve probably gone down a road I like to call Tool Blame. I know I sure have. Tool Blame is that final, last-ditch act of desperation where one simply refuses to admin that he’s wrong and concedes to “working around” the “deficiencies” of the “pathetic” tool he chose to use in the first place. My absolute favorite example of Tool Blame is a tirade from a developer I once worked with: “what do you mean .NET can’t parse an empty string into a DateTime? My whole middle-tier is designed around strings! It’s going to take me at *least* a week to work around Microsoft’s bumbling incompetence!!!”
Just about all of the systems I’ve written about here share quite a few things in common: they are poorly designed, poorly coded, and even more poorly documented. Today, I’m happy to share with you a system that doesn’t quite fit in with all the rest. It’s actually very sound software and, most of all, it’s well documented. Very, very well documented.


Hopefully after getting out of college, most of us have matured past drawing dude parts on passed-out roommates. Now, I don't mean to imply that I've matured beyond that point, just that I hope you have.