Things I Figured Out

Posted by Jacob Harris Mon, 03 Jul 2006 16:58:00 GMT

And now for something different (and shorter, for those recovering from the length of the last post). Insanely talented Internet prankster Rob Cockburn recently posted a short and sweet article Things I Figured Out, where he listed a bunch of interesting and slightly stupid revelations he’s had over the years. This has been followed by 15 pages of reader comments chronicling their own brilliant insights and forehead-slapping moments.

I think this is a brilliant idea for an article, and I’ve certainly had my moments of utter brilliance and sheer stupidity (even this blog probably has examples of both). So, I’m going to post a few of the things I’ve figured out on my own or, failing that, learned the hard way. But since this is a technical blog only, there will be no personal idiocy. Just technical things I now know better about now

• XML is Not For Everything Great for long data files, lousy for configuration files, downright terrible for love notes. It’s not one-size-fits-all.

• XML Is a Minute to Learn, a Lifetime to Master It’s easy to gloss over some of XML’s subtleties when you begin, but they’ll get you later if you aren’t careful. Sadly, very few resources articulate some of the things that’ll get you, but maybe there’s a future blog post about that.

• Somebody’s Done It Better Already I’m being glib here, but one of the joys of Open Source is that if you need a generic component, it’s best to look for someone who’s created it already. For instance, if you need a logger, you could write one on your own, but there are excellent libraries out there and your time is better spent writing stuff you can sell.

• HTTP Blows Away Raw Sockets Unless you absolutely, positively have no choice, there is no reason you should use raw sockets instead of HTTP protocol for remote services. Sure, it might be harder to set up in the short run, but it’s so much easier to debug and maintain in the long run this is a no-brainer. Especially since small, light, and fast HTTP parsing libraries are available for all.

• Often Too Much Is Worse Than Too Little Or as Donald Knuth put it, “Premature optimization is the root of all evil.” I’ve been stung so many times by trying to be clever, I’ve finally realized I should see if it’s slow before I try to fix what ain’t broke.

• Stored Procedures Are Evil DBAs swear by them because they’re supposed to control access and speed up performance. In reality, they move application logic out of your program into an awkward language (SQL) that will usually fall out of sync with your application and aren’t kept consistently in sourcesafe or migrations. Worse still, they’re the trenches for warfare between developers and operations.

• Developers Black-Box Way Too Much It’s too easy to leave this with a cliché admonition to “think outside the box,” but it’s sadly true. As developers, we’re taught early the useful technique of abstracting away complexity within black boxes. This is useful for that third-party API or calling operating systems, but it’s very easy to fall into that trap in your job (“we’ve always done it this way”) or your life (“I’ll just wait for career advancement to come to me”).

• Physical Contact Matters The Internet still hasn’t annihilated geography yet. And personal, physical presence still matters. Meeting people is so much better than emailing them. Which I guess is just a roundabout way of saying, yet again, I should’ve gone to Railsconf. Sorry!

• You’re Going to Screw Up The First Time. Just Accept It. It’s so easy to fall into the fear of not getting it right the first time, you never get started. Get over it. Accept you’re going to make mistakes the first time around and you’ll fix it later and do the best you can. And if you can, write unit tests to make it easier to clean it up when you start.

• Things Break Slowly, Rarely All at Once It’s rare you can pinpoint a single decision or piece of code where everything catastrophically failed. Instead, the road to failure and mediocrity is a gradual and painful process, of many small failures along the way. It’s hard to resist the downwards momentum, because it always seems feasible to reverse. I would like to see more project management texts that tell you how to stop digging that hole.

• If You Can’t Explain It, You Shouldn’t Do It. Sometimes I think half of IT operates by overwhelming your natural instincts and confusion with so much jargon, your brain just gives up. It’s a mysticism of sorts, but the wakeup to reality again is painful. My rule of thumb is if I can’t explain it in plain English using metaphors, and optionally table utensils, then it’s not worth doing. Because it most certainly will not be maintainable.

Okay, that’s all I have so far. But I’m sure the realizations will keep coming. Happy 4th of July everybody!