What if Obama is a flop?

Despite having not written for months, I didn't see how I could possibly let an event like this go by without comment. Far more significant than the Canadian election (even to us Canadians), last night's election says a lot about where the U.S.A. is at.

Of course, this is a very significant result. Despite a difference of only 0.1% of the popular vote, Americans actually did vote in favour of a minority for president. Unlike in Canada, where we picked the candidate that the rest of the world would look down on us for choosing, the U.S.A. picked the candidate that every other country wanted.

In a time like this, when everyone is happy and reflecting on the significance of the moment, I can't help but think of the worst-case outcome of this. What if 4 years from now the U.S.A. is still a disaster? Imagine that Obama floats through his presidency, without delivering on any of his promises, the country falls deeper into recession, the divide widens, etc. It certainly could happen. Specifically I'm thinking of a 2012 America where:

- Most citizens don't have free access to health care.

- They are still at war with (at least) three countries and losing many lives in the process.

- The sagging American economy has dragged down the entire world, such that new and emerging economies sink back to their old levels bringing many countries back to 3rd world status.

- More than 50% of Americans long for the days when a decisive Republican ran the country.

This could happen for a variety of reasons. Since every writer in the world is commenting on this election, the coming 100 days, the coming 4 years, etc. I won't comment on it here. Needless to say, despite every good intention and the rising hope of an entire nation (and arguably the world), it's entirely possible that nothing substantial gets accomplished and things operate pretty much as normal. I hope that's not the case, but it could be.

Despite the possible doom-and-gloom scenarios, this was, without a doubt, the right thing to do. This is the single biggest gift the U.S.A. has given itself and the rest of the world in my lifetime and regardless of what the next 4 years are like, I doubt anyone, from any country will be able to shake their heads and say "I told you so".

On code reviews

One of the most valuable lessons I've learned from working at Google is the importance of code reviews. There was no mention of code reviews in school or at my previous employers, but now I can't imagine developing without it. Code reviews come in many forms but for my current project it comes down to one thing: Every piece of code must be okay'ed by at least one coder other than the code's writer before it gets checked in. That's it.

Here's a typical cycle:

1) Coder A writes code to add a small feature (or fixes a bug, or whatever).
2) Coder A shows diffs for this change to coder B (and possibly C, D, E, etc.)
3) Coder B reads through the code and notices some small logic bugs, a few style issues, and raises some other concerns.
4) Coder A fixes the issues that B brought up and responds to B's concerns.
5) Repeat 2-4 as many times as required.
6) Coder B is now happy and says so - in writing (e.g., via email)
7) Coder A checks in the change.

Sound painful? Sometimes it is. But the value added by this cycle is quite remarkable. It's extremely valuable to have people inspect the code before it gets in for many reasons, including:

1) Small logic bugs resulting from the same person staring at the same code for several minutes or hours are often caught quickly by a second set of eyes.

2) At least two people see every piece of code checked in, spreading the knowledge throughout the team and reducing the likelihood of ending up with code that only one person understands and/or can modify.

3) People are more cautious about what they check in. With code reviews, most developers do additional work to clean up, comment, and optimize their code before requesting a review in order to minimize the number of review iterations.

4) The blame can be shared among the team when things go wrong. This may seem like a small deal, but I think it's very important. No matter how careful people are, imperfect code will continue to get checked in. Without code reviews, it's easy to place the blame and this can cause animosity in the team. With code reviews, multiple people are involved in imperfect code getting checked in. This means that not only is it in everyone's best interest to make sure the best possible code gets checked in, but also mistakes become something that the team can improve on instead of just "coder A screwed up".

Code reviews add overhead, there's no question about it. But the value of code reviews is comparable to unit tests and other magic tools of software development productivity, so if you aren't using them, you should.

Climbing the CN Tower for WWF

A couple of weeks ago, a few of us Googlers climbed the CN Tower to raise money for the WWF. It was even more difficult than I anticipated, but it was also a great time. We raised $1480 which Google matched (giving $2960) for the WWF. If you get a chance to try it next year, you definitely should. Photo of us (post-climb) from the website here:

http://www.flickr.com/photos/saveourclimate/2433116362/in/set-72157604608762941/

Listening while coding

I sometimes get on these kicks where I can only work while listening to music. Other times I need silence. Lately, I'm in an unusual situation where I'm getting my best work done listening to This American Life episodes. I only recently learned about this wonderful radio show, but in the past 3 weeks I've logged well over 50 hours listening to one program after another. They have archives for the past 10 years that you can stream for free. There are tons of really interesting programs and somehow you can listen and code at the same time. Definitely worth checking out.

On interviewees' questions...

I do a lot of interviews these days and I'm always amazed at how much trouble people have asking questions. There are lots of good questions you can ask, and several bad ones. For a brief discussion of this (and a fantastic book about managing software engineers) check out Managing Humans.

Here are some bad questions (often asked by otherwise good candidates):

• What exactly does this company/office/group do? [you should know this and so this really reflects badly]
  
• How well did I do? [no way... you didn't just ask this... I don't believe it... ugh... most likely this means you did badly - if not you just lost several points]
  
• How can I do better in the next interview? [are you serious? never ask this]
• Anything about money [unless maybe you're talking to an HR person, which if I'm interviewing you, you're not]
• I can't think of anything [nothing? nothing at all? really? you know you might have this job for the next 5-10 years; it could be thousands of hours of your life; it might keep you up at night from time to time; it might be the job you've always wanted; it might be the best decision of your life; it might be the worst decision of your life; are you sure there's nothing you want to know? really?!?!]
  

For me it's very simple. Ask two questions to each interviewer. Clear, concise, insightful questions. I find it easiest to ask one question about the job or a specific project/product and one about the company. And what's a good question to ask about each one? How do you know? You research it in advance! Know what your company does, come with an idea about what your job might be, and find things that interest you in these areas to ask about. If there's nothing that this company does that really interests you, you don't want to be there... really you don't.

Interviewees' questions don't make or break the interview - their answers do. Still, interviewers (especially if they're developers/engineers/etc.) like to know that their potential coworker has interesting things to say and shows some interest in what's going on. Think about it - this is probably what we want to do and we're here doing it. At least pretend you're interested.

But of course if you're just pretending... we'll know.