Archive for January, 2012

The most important pig in the office

January 26, 2012

In the world of devops, we have complex software packages like Jenkins to take care of continuous integration of source, and intricate monitoring systems like Nagios and Icinga to keep an eye on the state of your servers. For notification of problems, however, sometimes the low-tech solution is best. Ladies and gentlemen, I present to you: Olivia the pig.

Olivia normally sits on my bookshelf at the office. She’s a toy from when my daughter Quinn was much younger, the star of the Olivia picture books that she loved back then. When Quinn decided she no longer wanted to play with Olivia, I gave Olivia a new home at the office, where she serves two important purposes in the web development department.

First, Olivia is a warning flag. She’s a plush visual semaphore that says to all the developers “Something is wrong with the website source code.” Like most shops (I hope!), we practice continuous integration of our source. The rule is that we must be able to roll out trunk to the production website at any time. Projects are done on branches, so that we don’t have half-done work in progress committed to trunk. If code is committed to trunk, it’s ready to go live at any time.

Olivia is the visual indicator that says “we cannot push to production.” Normally, Olivia sits on my bookshelf. where she is only seen by me. When she is on top of my cube, she can be seen by everyone on our end of the building, including all of us developers. She can’t be missed. If Olivia is out, Job #1 is to fix trunk and get it stable.

Sometimes Olivia comes out intentionally, such as when we start a project merge to trunk. Olivia stays out until we’ve passed all our smoke tests, lest someone push out unproven code. Olivia tells everyone that things have not yet been proven to be stable.

Many organizations have physical semaphores like this. In the Perl 5 world, the person who is allowed to make changes to the master source tree is said to be “holding the patch pumpkin.” Why did the Perl community come up with the name “patch pumpkin”? Chip Salzenberg explains:

David Croy once told me once that at a previous job, there was one tape drive and multiple systems that used it for backups. But instead of some high-tech exclusion software, they used a low-tech method to prevent multiple simultaneous backups: a stuffed pumpkin. No one was allowed to make backups unless they had the “backup pumpkin”.

In Chip’s example, the physical semaphore granted privileges. With Olivia, the semaphore of her being atop my cube indicates a problem. In both cases, they’re low-tech but they work.

One Saturday afternoon at the office I had Quinn with me, and she asked why I had her old Olivia stuffed animal at work. I explained Olivia’s purpose, and Quinn thought that was pretty cool. A little later she came back with the picture below. Change “Andy’s computer” to “mission-critical web application that drives all company revenue” and she’s got it right: If Olivia is out, the web app is broken.

The visual semaphore is so simple and unmistakable, a then-eight-ear-old understands it.

But Olivia has a second purpose that I didn’t expect. She’s also a conversation starter, and so an ambassador for the department.

We web developers sit near a main entrance to the building, so many people walk by throughout the day. When Olivia is up on my cube, I’m often asked by a passerby why I have a stuffed pig up there. That’s my chance to do a little department PR. I can tell the person about automated testing, continuous integration, and how we make sure that everything is going well.

I’ve become pretty good at cramming everything into a minute. I’ll say something like “The source code to the website gets 100,000 tests run against it every hour on the hour, so we know we can always update it if we need to. If we discover that something is wrong, Olivia tells everyone that something is wrong. She’s like an oil light on your car’s dashboard.”

I’ve found that people are generally interested in hearing about how we do the magic of running the website. Talking to people helps them understand what it is we do as developers, and helps squash the idea that we just sit around all day typing. They find out just what sorts of processes go into keeping business-critical systems running.

Does your organization have similar low-tech tricks as part of your process? Tell me about them in the comments.


Open source is improv, so say “Yes and”

January 23, 2012

In her fantastic book Bossypants, Tina Fey has a sidebar about how improvisational comedy has changed her life, and given her a new worldview. We in open source would do well to adapt these ideas to how we conduct our projects as well.

Improv and open source share many characteristics. A group of people come together to create something without a plan, and the result is greater than any one person could have created on his own. Everyone has a wellspring of ideas, and adds to the work created by others. In improv, the people make a scene or a sketch. In open source, they make software, or a body of knowledge, or a community, or a gathering.

From her book:

The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt. But if I say, “Freeze, I have a gun!” and you say, “The gun I gave you for Christmas! You bastard!” then we have started a scene because we have AGREED that my finger is in fact a Christmas gun.

Now, obviously in real life you’re not always going to agree with everything everyone says. But the Rule of Agreement reminds you to “respect what your partner has created” and to at least start from an open-minded place. Start with a YES and see where that takes you.

As an improviser, I always find it jarring when I meet someone in real life whose first answer is no. “No, we can’t do that.” “No, that’s not in the budget.” “No, I will not hold your hand for a dollar.” What kind of way is that to live?

The second rule of improvisation is not only to say yes, but YES, AND. You are supposed to agree and then add something of your own. If I start a scene with “I can’t believe it’s so hot in here,” and you just say, “Yeah…” we’re kind of at a standstill. But if I say, “I can’t believe it’s so hot in here,” and you say, “What did you expect? We’re in hell.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “Yes, this can’t be good for the wax figures.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “I told you we shouldn’t have crawled into this dog’s mouth,” now we’re getting somewhere.

To me YES, AND means don’t be afraid to contribute. It’s your responsibility to contribute. Always make sure you’re adding something to the discussion. Your initiations are worthwhile.

Too often in open source, we do the opposite. We quickly say no, without regard to its effects. In improv, “no” kills a scene. In open source, it can drive away a contributor or kill an improvement to a project. It doesn’t need to be the word “no”, but any negativity towards a fresh idea.

Consider this exchange, all too common in mailing lists and IRC channels right now.

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “Language Y is a pain in the ass.”

In one quick bit of snark, Bob has taken a giant crap on Al’s idea, even though his only disagreement was in the implementation. Chances are Al will lose enthusiasm for the probject. In many cases, Al’s reaction might just be “Screw it, I don’t need this.”

Consider this alternative response from Bob:

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “That sounds like a cool idea. I bet a lot of people could use X. I have some concerns about writing it in Y if you’re interested in hearing them.”

This is not “sugar coating the truth” or “being politically correct.” It’s being polite. It’s being a human who understands that other people have feelings, and that those feelings drive behavior.

I’m certain that some reading this will say “If Al gives up based on that, Al needs to toughen up. If someone doesn’t like something I’m doing, I’ll still do it anyway.” That’s great for you, Mr. Self-Esteem. Not everyone is as highly advanced as you are.

The “suck it up and take rude criticism” attitude might make sense if your project can be picky enough to only take contributions from those with your level of self-esteem. No project that I’m on is so overflowing with contributors and code that it makes sense to drive away those who want to help. It’s my job in my communities to help bring in more contributions, and I suggest it’s yours, too.

Open source is not standup comedy. It’s never one star on stage, doing it all himself. It’s a worldwide improv ensemble. Try saying “YES, AND” and see what can come out of it.

Don’t waste your time with fancy resume sites and video resumes

January 9, 2012

I came across a website that offers a service to host your resume in a snazzy web 2.0 format. It offers a custom URL that you can send employers to, and it lets you host a video resume. The site is all pretty with the latest pastel colors and rounded corners, and there are little tabs you click on to get to different bits of information. Somehow this is supposed to make you stand out and let you take control of your career or something.

Don’t believe it. It’s extra work for the hiring manager, and will work against you in the hiring process.

Consider the hiring manager who has 100 resumes in his inbox. He’s looking to weed through the crap and find the good people. Now here’s an email that says “I don’t have a resume, but here’s a link to my page”.

You think that hiring manager is going to click through? Not very likely.

Say he clicks through and sees all the Web 2.0 colorful goodness. Hey, look, a video. You think he’s going to watch a video about you? Not very likely.

And then say you put up a video, and you fill it with meaningless blather like “I’m a hard worker and I’m a team player” and don’t tell anything about what you’ve actually done and haven’t given the viewer any details about what you’ve actually achieved in your career. Now you’ve wasted the hiring manager’s time to tell them the same nothing.

Video resumes aren’t a new idea. They’ve been around since the 80s when people thought it was brilliant to mail a VHS tape to an employer. Now it’s the 10s, and it’s only slightly less time-wasting.

It’s all about WHAT you say, and not about making it flashy. Flashy works against you if it gets in the way of the hiring manager quickly and easily finding out what he wants to know.

And what does a hiring manager want to know? Three key points:

  • What can you do for me?
  • What have you done in the past, in specific?
  • Are you going to be a pain in the ass if I hire you? Or are you one of those guys who comes in and disrupts a team and has to be fired three months later?

A resume and cover letter that answer those questions are worth 100x more than a video resume and branded website.