May 2012 Archives

We try to have fun together at Famigo.  Every Wednesday we have Taco Twednesday, in which we all leave the office to eat at and review various taco establishments.  (We're also logging these reviews, taking steps towards the world's first big taco data powerhouse.)  I also regularly invite everybody over to my house to make homebrew beer. (Ask about our not-quite-award-winning ale, Electric Brewgaloo.)  Finally, we devote one afternoon a month to Mandatory Fun Day, where one rotating employee plans an afternoon of fun for the rest of the company.

What's the point of all this camaraderie?  Sure, it's fun to get out of the office, it's great for retention, and it helps with recruiting.  We're doing something more important than all of that though when we're having fun, though.  We're doing something that every software organization needs help with: we're learning to listen to each other.

Writing software is an isolating experience.  Many years ago**, I had a job where I'd sit down, I'd put on my headphones, I'd bang away at the keyboard, and I'd go home 10 hours later.  That was all day, every day, for a few years.  Actually, there was an occasional exception.  Sometimes, I'd hit a hard problem and I'd spend 20 or 30 hours at the keyboard before I went home.  I wasn't the exception; the rest of the team was like that too.  And let me tell you, we made some crappy, crappy software.

It was a little surprising at the time, because, individually, we were all smart.  As a group then, shouldn't we have been very smart, making very good software?  Spoiler alert: no.  No one listened to anyone else, and so each person on the team was left on his own to make crucial mistakes.  These mistakes compounded over the years until the product crashed.

Why weren't we talking?  I can only speak anecdotally here.  My teammates were friendly enough, but there were differences when it came to age, outside interests, background, and politics.  All we had to discuss were the typical programming debates (vim vs. emacs, etc.) or company rumors, both of which were charged conversation topics.  In short order, everyone was still talking, but no one was listening.

We had important questions for each other, things like "What do you think of Feature X?", "Do these requirements make sense?", and "What the hell is it we're actually building?"  Even at the time, I knew I should be asking them, but not enough to get me to participate in an awkward conversation with people I didn't know very well.  Collectively, we could've answered those and built something important.  Instead, each of us charged ahead with a deeply flawed idea of what we were building.

Would tacos, beer making, or a go cart outing have fixed that?  Maybe so!  At the very least, it's a shared experience.  It's a starting point.  We could begin having agreeable conversations, starting with questions like "How about these tacos?"  or "Wow, we made some crappy beer, didn't we?" These simple conversations build rapport, and I would now trust my teammate's opinion on something.  All of that is crucial if I want to feel comfortable asking harder questions like, "I can't figure this out; will you help me?" or "Are we building the right thing?"  That is why it's only partly a joke when I say we practice taco-driven development.

**The job in question is wayyyy back in time, and has nothing to do with any recent employers.

About the Author

The Art of Delightful Software is written by Cody Powell. I'm currently Director of Engineering at TUNE here in Seattle. Before that, I worked on Amazon Video. Before that, I was CTO at Famigo, a venture-funded startup that helped families find and manage mobile content.

Twitter: @codypo
Github: codypo
LinkedIn: codypo's profile
Email: firstname + firstname lastname dot com