Possibly the best session I attended at FOO Camp was given by Brian Fitzpatrick. Fitz talked about The Art and Adventure of Beekeeping, and tied it together with his experiences with his old house in Chicago and software development.
I’m not going to talk about the talk itself except in the most general terms above (as per FOO Camp policy, I shall only be blogging about publicly-available stuff) but I will talk about my reaction to it, since the whole thing hit very close to home for me.
I’m hasty. I tend to jump into things without thinking or looking. I make rushed decisions, I jump into things, and I tend to constantly strive for better without appreciating what’s there. This is most obvious in my thesis, when I decided not to use NS2 and wrote my own network simulator instead. I learned a hell of a lot, and it honestly probably didn’t take longer, but… Was it the right decision? I’m not sure. I thought at the time that I’d considered all my options carefully, but in retrospect, I think I might’ve jumped at the opportunity to demonstrate my ego. Honestly, I think a lot of software folks are this way - it’s why we’re so bad at code re-use.
The Art and Adventure of Beekeeping is all about the value of observation, contemplation and patience. I’ve been suggesting for a while that our culture needs to learn the value of being slow again - for example, we need to realize that not being able to travel halfway around the world in less than twelve hours is not necessarily bad. But listening to Fitz talk (and joining in the discussion), I realized that I need to learn that I don’t need to do everything at 100% speed. There’s a lot of value to sitting and watching beehives, listening to the bees and learning their behaviors. Before you jump in and start clearing out honey and replacing bits of the hive, you’ve got to learn the feel of what’s already there and what that feel means.
Another interesting thought was that cleanliness isn’t necessarily the highest virtue - things that are messy can still have value. Cleaning them up without pausing to observe them and consider them from different perspectives can inadvertently destroy that value. Yes, working with them in the interim can be annoying, but it’s better than wading in and wrecking things before you grasp the full picture.
I could probably write a small book about the stuff in that session, but I think I’m going to stick to two more little bits. First off, unless you’re writing an RFC, don’t say “should”. Should usually means that you’re coming to a situation with a pre-conceived notion of how it “should” be, making snap value judgments without actually taking the time to observe.
Secondly, “failure scales.” It may sound like a quip, but it’s surprisingly accurate. It’s hard to replicate success, it’s much easier to replicate failures or borderline marginal.
