Coding Horror

Have you ever been to an interview for a programming job where they asked you one of those interview puzzle questions? I have. The one I got was:

How much of your favorite brand of soda is consumed in this state?

And no, the correct answer is not who cares, unless the thing you don't care about is getting the job you're interviewing for. I didn't know it at the time, but this is a Fermi Question. (To prevent spoilers, the answer can be found in a previous blog post.)

Puzzle questions were all the rage in programming interviews in the 90s and early aughts. This is documented in the book How Would You Move Mount Fuji? with a specific emphasis on Microsoft's hiring practices.

It is prudent to study common interview puzzle questions if you know you'll be interviewing at a company that asks these sorts of questions. And if you think you're ace at programming puzzle questions, then I challenge you to point your massive brain at this, the hardest interview puzzle question ever:

A hundred prisoners are each locked in a room with three pirates, one of whom will walk the plank in the morning. Each prisoner has 10 bottles of wine, one of which has been poisoned; and each pirate has 12 coins, one of which is counterfeit and weighs either more or less than a genuine coin. In the room is a single switch, which the prisoner may either leave as it is, or flip. Before being led into the rooms, the prisoners are all made to wear either a red hat or a blue hat; they can see all the other prisoners' hats, but not their own. Meanwhile, a six-digit prime number of monkeys multiply until their digits reverse, then all have to get across a river using a canoe that can hold at most two monkeys at a time. But half the monkeys always lie and the other half always tell the truth. Given that the Nth prisoner knows that one of the monkeys doesn't know that a pirate doesn't know the product of two numbers between 1 and 100 without knowing that the N+1th prisoner has flipped the switch in his room or not after having determined which bottle of wine was poisoned and what color his hat is, what is the solution to this puzzle?

In other words, I hate puzzle questions.*

I'm also not a huge fan of those abstract impossible questions, eg, "how many optometrists are there in Seattle?", but I suppose that's a matter of taste. If you absolutely must, at least ask an impossible question that has some relevance to a problem your very real customers might encounter. I just can't muster any enthusiasm for completely random arbitrary puzzles in the face of so many actual, real world problems.

And yes, I totally failed that interview. Which was disappointing, because it was kind of a cool job.

Not that my proposal for interviewing programmers was any more popular, though I do think it's much better.

I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:

• Is this person passionate about what they are doing?
• Can they communicate effectively to a small group?
• Do they have a good handle on their area of expertise?
• Would your team enjoy working with this person?

You'd certainly want to complement this type of interview with some actual hands on programming, to make sure the applicant isn't full of crap -- although I'm pretty sure that you can't B.S. your way through a technical presentation to a handful of your peers if you truly have no idea what you're talking about. (And if you can, you should be CEO of a startup by now.)

What I'm optimizing for here is the ability to communicate. Most programmers, once they pass the FizzBuzz level of competency, are decent enough. But coding chops aren't enough. To go from good to great, you must be able to communicate effectively: with your teammates, your manager, the users, and ultimately the world.

My wife and I just finished a five day hospital stay for the birth of our first child. During our stay, we were assisted by a parade of different nurses, at least two different nurses every day, sometimes more as we progressed to different areas of the hospital and through daily shift changes. The quality of care at this particular hospital is generally quite high, but we were flummoxed by the disparity in care between the worst nurses and the best nurses. After a few days, I finally figured out the common characteristic -- the worst nurses were invariably the worst communicators! The fact that these nurses couldn't effectively communicate with us:

• why they needed to do something
• what the options were
• offer advice
• troubleshoot our problems

Hiring is difficult under the best of conditions. But an interview process that relies too heavily on puzzle questions is risky. Sure, you may end up with programmers who can solve (or memorize, I guess) the absolute gnarliest puzzle questions you throw at them. But isn't effectively communicating those solutions to the rest of the team important, too? For many programmers, that's the hardest part of the puzzle.

* although I expect aficionados of the style should be able to identify all the classic interview puzzle questions represented here.

I was struck by the conclusion of Andy Oram's thoughtful piece on the next generation of online forums.

People who want to learn more about computer technology and solve problems they encounter on their systems currently have a wealth of forums to turn to: mailing lists and newsgroups, official and unofficial documentation (which may be distributed on the Web, on their systems, or in printed form) and the more collaborative media of IRC channels, wikis, and virtual worlds.

Why tamper with this set of resources? Because they are not as easy to find or to use as they should be. Each medium was invented for purposes other than the specific task of educating computer users, and have never been tailored to the tasks of generating and searching for information about computer systems. If relevant material was served through more specialized and helpful tools, people might create better information and it might be used more.

[..]

Done well, this system would make it fun and rewarding to contribute information to user communities.

The key word here is "fun".

When you interact with other people online ..

• sending an email to a mailing list
• posting on a discussion forum
• chatting on IRC
• revising a Wiki entry
• entering a blog comment

.. like it or not, you're participating in the world's largest MMORPG. Lurking is always free. Those that choose to go beyond lurking, to add some tiny bit of content to the web, do it because they find it enjoyable. On some level, they're having fun. If you want to a cultivate a community of participants instead of passive, zombie-like TV viewers who contribute nothing, you should be designing to maximize this fun. As Andy discovered, not designing game-like aspects into community websites is the bigger long term mistake.

In the fantastic presentation Mixing Games and Applications, Dan C. explores the example of Mario Brothers, which we know as a game. But what if it was a traditional desktop application: Rescue Princess Enterprise 2008?

Or a web 2.0 website, Princesszr?

How easy are the above two applications to learn? To use? The desktop application has a steep learning curve, but offers lots of power and flexibility. The web 2.0 version has almost no learning curve, but it only does one simple (and boring) thing.

Now consider it as a game.

The player is handed a new tool called Mario the first time they see this screen. They don't know how to use him. The screen gives them a playground where they can try different things:

• Blocks that reward jumping by giving out coins.
• Goomba that rewards successfully learning how to attack. It also teaches the players to avoid Goombas on pain of death.
• Blocks that teach the player how to collect powerups.

There are a couple interesting points to note:

1. The awarding of a new tool is almost always paired with a simple level that lets the player learn the tool in a somewhat safe environment.
2. The player cannot pass this section without mastering at least one critical skill, in this case moving and jumping. This sort of gating ensures that the designer can rely upon the user having the jumping skill available at later points in the game.

This is different than most apps. In many apps, you sort through the options and turn on a new feature. There is nothing that is the equivalent of a 'level' or learning context to help you build skills associated with the tool.

Recasting the experience as a game means it can be simultaneously complex and easily learnable. That's something we couldn't accomplish through traditional applications, which are designed to be usable but not necessarily fun. They've failed to design for fun. And in an era of ubiquitious web community , that's a big mistake.

Let's not trivialize this. Just because your application is fun doesn't mean you've turned it into a game. You've adopted game mechanics in order to build community:

I see game mechanics working well on sites like YouTube, Yelp, Twitter, and Flickr. These sites have added game mechanics like points, leaderboards, level-ups, social exchanges, and customization to a strong core experience. In particular, YouTube has done a brilliant job of making the overall experience feel game-like, without turning the site into a traditional game.

Why is this happening in so many places? I think game design principles have become common knowledge for young Web designers. Many of the people who are designing and building these sites grew up playing games, and are familiar with game design principles - even if they're not "officially" game designers themselves. It's a testament to how pervasive and mainstream gaming has become.

I recommend paging through Amy's presentations for a more detailed explanation with lots of great examples:

1. Putting the Fun in Functional
2. Power to the Players

If you're looking for a lower-level design compendium of game mechanics, suitable for implementation on your own site, check out the Yahoo Developer Network social design patterns library:

• Ratings & Reviews
• Reputation
• Ranking

Not every activity can be turned into a game. And perhaps not every activity should be a game.

But when it comes to community websites -- sites that get better for everyone the more users actively participate -- these are already so close to being de-facto games that it'd be downright negligent to ignore this aspect of the design. You should shape and define your community by explicitly acknowledging and embracing the game-like aspects you want to encourage, rather than pretending they don't exist.

After all, the first step in breaking our addiction to the world's largest MMORPG is to admit that we have a problem.

Back in September 2008, I mentioned that we were spawning a new process. Well, that process arrived today, and its id is Henry Burton Atwood.

We're starting him off right with a little light reading.

You may recognize this book from Apple's Mac vs PC ad series, specifically, the "Gift Exchange" Mac vs PC ad.

Because, truly, what better gift is there for a newborn than the C++ GUI Programming Guide? Watch the ad to see what I mean. "I've been eyeing that myself."

All credit for creation of this new process of course goes to my wife Betsy who did the real work. I now truly understand the meaning of the classic Bill Cosby skit on childbirth.

Helping my wife walk the pain scale, going from pain level 7/10, 8/10 and then seeing the maw of darkness that lies at pain scale 10/10 and beyond, was quite an experience. How much pain? Well, imagine the worst pain you've ever experienced. Now imagine taking that pain, packing it in to a rickety Oldsmobile, setting it on fire, then driving it off the edge of a cliff at maximum speed. Into a valley filled with white-hot molten lava.

It's a little bit worse than that.

You may have heard that childbirth is a mystical, spiritual process. The thing that ties every human being together as one long continuous string of life, extending all the way back to the beginning of time. To a point, it is. As my friend Phil said, it's all ponies and butterflies. Until the ponies and butterflies start spontaneously screaming. But, it was all worth it to get Henry, who is genetically engineered to be awesome. Being a geek from birth, Henry has his own Twitter account, which was opened with exactly the first message you'd expect:

Hello World. Literally.

If you've been reading my blog for a while, I'm sure you know I will approach our new parenting adventure the same way I do programming -- with absolutely no freaking idea what I'm doing. And often hilarious results.

Here's to you, little guy, and every other little programmer being born around the world.

As a software developer, how do you sharpen your saw?

Sharpening the saw is shorthand for anything you do that isn't programming, necessarily, but (theoretically) makes you a better programmer. It's derived from the Covey book The 7 Habits of Highly Effective People.

There's a guy who stumbled into a lumberjack in the mountains. The man stops to observe the lumberjack, watching him feverishly sawing at this very large tree. He noticed that the lumberjack was working up a sweat, sawing and sawing, yet going nowhere. The bystander noticed that the saw the lumberjack was using was about as sharp as a butter knife. So, he says to the lumberjack, "Excuse me Mr. Lumberjack, but I couldn't help noticing how hard you are working on that tree, but going nowhere." The lumberjack replies with sweat dripping off of his brow, "Yes... I know. This tree seems to be giving me some trouble." The bystander replies and says, "But Mr. Lumberjack, your saw is so dull that it couldn't possibly cut through anything." "I know", says the lumberjack, "but I am too busy sawing to take time to sharpen my saw."

Of course, the best way to improve at something is to do it as often as possible. But if you're so heads down coding that you have no time for discussion, introspection, or study, you aren't really moving forward. You have to strike a mindful balance between practicing your craft and thinking about how you practice your craft.

Scott Hanselman has some solid ideas on ways to encourage members of your development team to sharpen their saws. And then there's the obvious way, the thing you're doing right now: reading programming blogs. I don't mean this blog, but ones of actual worth. If you keep an open mind, you can sharpen your saw that way, as Reginald Braithwaite notes:

What we do is this: we read a blog post, reading thing after thing we agree with, and if just one thing in there doesn't fit our personal world view, we demand a correction. If the thesis of the post clashes with our prejudices, we accuse the author of being an idiot. Honestly, we would suck as salespeople. We would quit the first time someone disagreed with us.

What I suggest we do is mimic these salespeople. When we read a post, or a book, or look at a new language, let's assume that some or even most of it will not be new. Let's assume that we'll positively detest some of it. But let's also look at it in terms of our own profit: we win if we can find just one thing in there that makes us better programmers.

That's all we need from a blog post, you know. It's a huge win if there's one thing in a post. Heck, it's a huge win if we read one hundred posts and learn one new valuable thing.

If you're looking for good programming blogs to sharpen your saw (or at least pique your intellectual curiosity), I know of two excellent programming specific link aggregation sites that can help you find them.

The first is Hacker News, which I recommend highly.

Hacker News is the brainchild of Paul Graham, so it partially reflects his interests in Y Combinator and entrepreneurial stuff like startups. Paul is serious about moderation on the site, so in addition to the typical Digg-style voting, there's a secret cabal (I like to think of it as The Octagon, "no one will admit they still exist!") of hand-picked editors who remove flagged posts. More importantly, the conversation on the site about the articles is quite rational, with very little noise and trolling.

The other site is programming reddit. The conversation there is more chaotic, with a wild-west anything goes sensibility, gated only by the up and down votes of the community. But it is quite reliable for digging up a great variety of links that are of particular interest to programmers.

Of course, too much saw sharpening, or random, aimless saw sharpening, can become another form of procrastination. But a developer who seems completely disinterested in it at all is a huge red flag. As Peter Bregman explains, obsession can be a good thing:

People are often successful not despite their dysfunctions but because of them. Obsessions are one of the greatest telltale signs of success. Understand a person's obsessions and you will understand her natural motivation. The thing for which she would walk to the end of the earth.

It's OK to be a little obsessed with sharpening your saw, if it means actively submitting and discussing programming articles on, say, Hacker News.

What do you recommend for sharpening your saw as a programmer?

I haven't had the opportunity to talk at all about Google's new Chrome browser yet. Which is a shame, because it's easily the best web browser I've ever used. If it wasn't for the complete and utter lack of an add-in ecosystem, I'd switch away from Firefox in a heartbeat. If you're curious about Chrome, check out the Scott McCloud comic Google commissioned to explain it. Or, heck, just try it yourself!

Chrome is a joy to use, and in my opinion at least, it's the first true advance in web browser technology since the heady days of Internet Explorer 4.0. Chrome is filled with so many thoughtful details, so many reimaginings of web browser functionality as a true application platform, it's hard to even list them all.

In fact, the best way to explain how great Chrome is might arguably be one of the silliest, tiniest things about it -- even Chrome's error messages are fun! Here's an error I experienced last night while trying to clean up my GMail contacts list.

The tab is frozen, you see? With the snowflakes, its little scarf and teeth chattering in the cold? Rather than being annoyed with GMail, and blaming Chrome, I am completely disarmed by this error. It makes me laugh! It reminds me that the developers working on this software, rather than just taking the path of least resistance and spitting out a generic message box with a cryptic error code, took time to make their error messages not only user friendly, but fun.

I'm reminded of the Beagle Brothers statement of quality:

Our programs are FUN to use. Our instructions are CLEAR and complete.

And what happens if there's a serious rendering error on a Chrome tab, resulting in a per-tab process crash? Aw, Snap!

These errors are subtle homages to the classic Macintosh Sad Mac. Which is a tad ironic, as Chrome is very much Windows only, at least for now.

Now, none of this means that you shouldn't take errors seriously. As a competent and professional software developer, you will crash responsibly. Every time. Humor alone is not the goal here.

Errors aren't the most glamorous part of software development. In fact, they're sort of a downer. But the way you handle errors speaks volumes about how much you respect your users, and ultimately, your own project. Remember, this stuff is supposed to be fun! Why not share some of that joy, that fun you had building your application, with your users? We certainly did this on Stack Overflow with our CAPTCHA and Error pages. It's a major drag for your users to end up on a human verification page, or a big fat honking server error. So why not ease the tension a bit by spending a little extra time on your errors and using them to illustrate the lighter side of software development?

Don't get me wrong. Your error messages should always be informative and helpful. That's not optional. But as Google Chrome shows us, it is possible to do that while also being fun. And that's even better.