The Ugly American Programmer

On the internet, you can pretend the world is flat. Whatever country you live in, whatever language you speak, you have the same access to the accumulated knowledge of the world as every other citizen of the planet Earth. And a growing percentage of that knowledge can and should be available in your native language.

But I believe the rules are different for programmers. So much so that I'm going to ask the unthinkable: shouldn't every software developer understand English?

A wildly disproportionate amount of programming information is available in English. The overwhelming majority of programming languages use English keywords. By any metric you can possibly measure, English is the lingua franca of programming.

Now, In terms of cultural literacy and travel, presuming that everyone should speak English is a totally unacceptable attitude, the epitome of the ugly american.

But those rules don't apply to us.

We're not talking about normal everyday people. We're talking about programmers. Citizens of the internet. People who swear allegiance not to a country, but a compiler. Hackers have their own culture, their own norms and standards for literacy. Eric Raymond notes that functional English is required for true hackers:

As an American and native English-speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet, and that you will need to know it to function in the hacker community.

Back around 1991 I learned that many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all).

Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It's an example worth following.

Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong -- and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

It's difficult to communicate this idea without feeling like an ugly American programmer. But it doesn't come from a nationality, or a desire to dominate the world. It's nothing more than great hackers collectively realizing that sticking to English for technical discussion makes it easier to get stuff done. It's a meritocracy of code, not language, and nobody (or at least nobody who is sane, anyway) localizes programming languages.

I received this email from Slawomir, a Polish programmer, a few months ago. He confirmed what I've always suspected and secretly believed -- but have been hesitant to say:

I just listened to Stack Overflow podcast episode 29 where you discuss localization of developer tools.

In my opinion there is no reason to translate developer tools and documentation.

I know many developers in Poland who prefer (as Joel mentioned) to get English documentation rather than Polish translation and the reason for that is that translations were not always accurate. Even Microsoft developer documentation was translated partially or with errors, so reading original English document was easier than English-Polish soup.

If everybody blogs and develops in English - our global repository of solutions and blog posts is much bigger and you have better chances of finding an answer to your problem.

Consciously choosing to switch from Polish to English reminds me why I gave up Visual Basic for C#, as painful as that was. These languages do exactly the same things -- and the friction of choosing the minority language was severe. I found reams of code and answers in C# whenever I searched, and almost nothing at all in VB.NET. I spent so much time converting code into VB.NET and introducing new bugs and errors in the process, along with countless language-only forks. This eventually stopped making sense to me -- as it would to any good programmer.

Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it.

Don't Like It? Code it Yourself!

Have you ever considered paying for, or sponsoring, a

• bug fix
• new feature
• plugin
• small tweak to existing functionality

... for software that you use?

I don't mean waiting for a new release of the software, which will contain a bunch of new features you may or may not care about, along with all new bugs. I'm talking about making a very specific request for existing software happen through financial sponsorship.

Sure, if the software you're using happens to be open source, you can theoretically download the source code, roll up your sleeves, and code it yourself.

If you have a very strong desire to see a particular feature implemented, your odds of success of ultimately having it become a part of the tool are dramatically increased if instead of asking for it to be implemented, you check out a copy of the latest source code tree, code it yourself (even if slightly incomplete or somewhat buggy), and submit it for peer review by the existing developer pool. Other technical parties are far more likely to help you complete a worthwhile code enhancement that you've clearly put time and thought into than they are to remotely consider doing what you want from scratch just because you want it.

Of course, not all end-users have the technical acumen or programming experience to bring such things to reality. You have three options: a) find a programming friend that you can get excited about your idea and have him follow the above paragraph, b) live without the feature and enjoy the software you have been provided free and proves useful to many others, or c) find a different software package that does do what you want.

But how realistic is this for the average user? Heck, how realistic is this for the average programmer? Even if you're the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in -- do you honestly have the kind of time it would take to do that?

Sometimes, when people say this:

The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don't you code it yourself?

They're really saying this:

F**k you.

That seems a bit harsh to me. Surely there's something between the extremes of "give up" and "code it yourself."

Why isn't there a service to aggregate and pool funds to sponsor programming particular features or bugfixes in open source software?

There are many end-users willing to pay for improvements to free software and writing new programs. There are also many talented programmers wanting to get paid to work on free software. Allow end-users to escrow payments that are pooled together to pay developers for implementing features / writing software. A panel of well-known free software experts is needed to vet new ideas before payment is escrowed for them, and to review programmer work having met the target.

I realize that using financial incentives on open source projects can have some unintended consequences. But a sort of attention and interest aggregation service for existing projects -- one backed by real money, so you know the interested parties are serious -- seems like a worthwhile cause. It might even attract the interest of other programmers if the pool got large enough.

To me, at least, sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project. For example, I've sponsored several bugfixes in a key .NET open source library that we use for Stack Overflow. These are bugfixes they considered low priority, but were serious issues for our site. I was happy to give back to the project, and it was certainly a more realistic option than us carving out a chunk of our own development time to contribute the bugfixes ourselves.

That said, I am concerned that this sort of aggregated sponsorship system hasn't naturally evolved on its own by now. Is it not sustainible, or incompatible with the kind of intrinsic motivations that drive most open source development?

Who's Your Arch-Enemy?

I didn't fully understand 37 Signals' advice to Have an Enemy until recently.

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go.

When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.

One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.

I've explained Stack Overflow to hundreds of people, and by far the most effective way to explain what we do -- the way that causes people to visibly "get it" almost instantly, with a giant cartoon lightbulb practically appearing over their head -- is this:

We're like experts-exchange, but without all the evil.

I never appreciated how easy Experts-Exchange makes it for us. They are almost universally loathed. We don't just have a rival, we have a larger than life moustache-twirling, cape-wearing villain to contrast ourselves with.

No matter how much we may suck (and we try very, very hard not to suck), we can simply point to the experts-exchange website and we instantly become the hero. The good guy. The underdog.

I have absolutely nothing against Experts-Exchange. Realize that I've been a fan of the smackdown learning model for a long time; it's like kayfabe in professional wrestling. There are no hard feelings; this "rivalry" is mostly useful as a way to explain what it is we do. This internet is certainly big enough for the both of us -- big enough, in fact, for hundreds of Q&A websites.

That said, if you have an arch-enemy -- the more horrible and evil and larger-than-life the better -- consider yourself lucky. They're doing you a huge favor.

So, who's your arch-enemy?

See You at EclipseCon!

I have the very great honor of speaking at this year's EclipseCon with one of my heroes, Clay Shirky.

The theme of this year's EclipseCon is collaboration -- so all the talks are presented by two speakers. Our talk, The Social Mind: Designing Like Groups Matter, will alternate between the theory (Clay) and practice (Jeff) of online community. Hopefully in a coherent way.

This is an easy talk for me to deliver, because I quite literally used Clay Shirky's book, Here Comes Everybody: The Power of Organizing Without Organizations, as a blueprint for building Stack Overflow.

I wasn't kidding when I said It's Clay Shirky's Internet, We Just Live In It.

I can't emphasize enough how deeply I respect Clay. I've read everything he's written to a degree that you might even say I studied it. Clay continues to be one of the most perceptive and insightful technical writers in the world on the topic of internet culture and community. His latest missive on the demise of newspapers is not to be missed. It's thrilling to have this opportunity to speak side by side with such a vital, important figure in internet history.

It is also extremely gratifying to me that I am giving this talk to a group of non Windows-centric developers. Despite my personal background, we always intended Stack Overflow to be a tribute to the greater craft of programming, a place where you could rub shoulders with fellow programmers from all sorts of different backgrounds and professional interests -- a bit like the old, classic computer programming magazines like Byte and Dr. Dobb's Journal.

It pains me to see developers who let themselves get locked into some particular toolchain ghetto, without at least peripheral awareness of what else is going on in the programming world around them.

Good programmers are interested in everything -- and that's exactly the kind of talk Clay and I intend to deliver.

Update: I'm not sure the event was recorded, but Alan Zeichick's summary of our talk is outstanding. I also put the slides up on SlideShare for viewing or download, though it's tough without audio.

Five Dollar Programming Words

I've been a longtime fan of Eric Lippert's blog. And one of my favorite (albeit short-lived) post series was his Five Dollar Words for Programmers. Although I've sometimes been accused of being too wordy, I find that learning the right word to describe something you're doing is a small step on the road towards understanding and eventual mastery.

Why are these words worth five dollars? They're uncommon words that have a unique and specialized meaning in software development. They are a bit off the beaten path. Words you don't hear often, but also words that provide the thrill of discovery, that "aha" moment as you realize a certain programming concept you knew only through experimentation and intuition has a name.

Eric provides examples of a few great five dollar programming words on his blog.

1. Idempotent

There are two closely related definitions for idempotent. A value is "idempotent under function foo" if the result of doing foo to the value results in the value right back again.

A function is "idempotent" if the result of doing it twice (feeding the output of the first call into the second call) is exactly the same as the result of doing it once. (Or, in other words, every output of the function is idempotent under it.)

This isn't just academic. Eric notes that idempotence is used all the time in caching functions that create the object being requested. Calling the function two or a thousand times returns the same result as calling it once.

2. Orthogonality

Imagine for instance that you were trying to describe how to get from one point in an empty room to another. A perfectly valid way to do so would be to say how many steps to go north or south, and then how many steps to go northeast or southwest. This hockey-stick navigation system is totally workable, but it feels weird because north and northeast are not orthogonal -- you can't change your position by moving northeast without also at the same time changing how far north you are. With an orthogonal system -- say, the traditional north-south/east-west system -- you can specify how far north to go without worrying about taking the east-west movement into account at all.

Nonorthogonal systems are hard to manipulate because it's hard to tweak isolated parts. Consider my fish tank for example. The pH, hardness, oxidation potential, dissolved oxygen content, salinity and conductivity of the water are very nonorthogonal; changing one tends to have an effect on the others, making it sometimes tricky to get the right balance. Even things like changing the light levels can change the bacteria and algae growth cycles causing chemical changes in the water.

Orthogonality is a powerful concept that applies at every level of coding, from the architecture astronaut to the lowest level code monkey. If modifying item #1 results in unexpected behavior in item #2, you have a major problem -- that's a form of unwanted coupling. Dave Thomas illustrates with a clever helicopter analogy:

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you're constantly dancing on all the controls to keep the helicopter stable.

That's kind of similar to code. We've all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back -- like that Whack-a-Mole game -- and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you'll always get that kind of distributed bug fixing.

3. Immutability

Immutability is a bit more broad, but the commonly accepted definition is based on the fact that String objects in Java, C#, and Python are immutable.

There's nothing you can do to the number one that changes it. You cannot paint it purple, make it even or get it angry. It's the number one, it is eternal, implacable and unchanging. Attempting to do something to it -- say, adding three to it -- doesn't change the number one at all. Rather, it produces an entirely different and also immutable number. If you cast it to a double, you don't change the integer one; rather, you get a brand new double.

Strings, numbers and the null value are all truly immutable.

Try to imagine your strings painstakingly carved out of enormous blocks of granite. Because they are -- they're immutable! It may seem illogical that every time you modify a string, the original is kept as-is and an entirely new string is created. But this is done for two very good technical reasons. Understanding immutability is essential to grok string performance in those languages.

I don't pretend that these three words are particularly unique or new, just a tiny bit off the beaten path. They were, however, new to me at one time, and discovering them marked a small milestone in my own evolution as a programmer.

What's your favorite five dollar programming word? And how did it help you reach that particular "aha" moment in your code? (Links to references / definitions greatly appreciated in comments -- perhaps we can all discover at least one new five dollar programming word today. Remember, learn four and you'll earn a cool twenty bucks worth of knowledge!)

The Hardest Interview Puzzle Question Ever

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

Meant they ended up feeling like rigid, inflexible proceduralists who didn't care or constantly had to appeal to authority. Of course, this wasn't true. I'm sure they were perfectly competent registered nurses. But in the absence of reasonable communication, it sure seemed that way. To be fair, these nurses were frequently (but not always!) non-native English speakers.

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.

The World's Largest MMORPG: You're Playing it Right Now

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.

Spawned a New Process

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.

Why Can't Error Messages Be Fun?

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.

Sharpening the Saw

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?