My first thought is that pair programming is a huge waste of time. When only one person has access to the keyboard, aren’t you wasting the other person’s time?

I could just see myself chomping at the bit and thinking — how could he not use windows+e to launch windows explorer–there has to be a better way. My brain would keep wondering why he wasn’t typing something the super efficient way that I knew to do it.

And yet, he started doing things that I didn’t know how to do — so you don’t actually need a GO between those SQL statements? huh — who knew? I guess that means I don’t know everything. And therein lies the key of pair programming. You don’t know everything, and if you pair with someone else who is a good programmer you will certainly learn something from them.

Not only that, but there’s something about the shared energy that comes from both of you working to solve a problem. For some reason, you seem to solve it faster. I think it’s because while one of you is trying one possible solution, the other one is thinking about another way to solve it.

Does that mean that pair programming is a panacea that you should always do? I don’t think so. Not yet, but it’s definitely something that I will plan to do more often because I think it’s a great way to encourage and learn from each other.

Quick, what’s the most important thing you can do to make your users happy?

If you’re a developer you’re probably thinking that you need to eliminate all bugs or make it as efficient as possible. But haven’t you used, and continued to use, software that was buggy or slow (I’m looking at you twitter)?

It’s a given that you need to have a market. After that, what is the most important aspect of your software?

I’m going to make a true, but controversial statement here. Are you sitting down? You’re software does not need to be bug-free.

That’s right — don’t try to eliminate all the bugs before shipping. In fact, as long as the bugs won’t corrupt user data or interfere with the user experience they are probably not worth fixing.

There are exceptions to this case if you are NASA, but most of us are not. And the cost of fixing many bugs outweighs the benefits.

Just get the software out there and make sure there’s a market. Then fix what’s important to the majority of consumers. We live in a different world than the days of shrinkwrapped software where fixing a bug after shipping meant sending another million disks out.

Follow the rule given by Facebook’s lead developer:

Move quickly and break stuff.

UX Rules

Instead of fixing every little technical bug, you should be focusing on the user experience because to many users, your software is the user experience.

Most users will only care about how your software looks and if it does what they want. To illustrate this “iceberg principle”, Joel Spolsky tells a great story about showing software before they had a chance to polish the UI:

What happened during the demo? The clients spent the entire meeting griping about the graphical appearance of the screen. They weren’t even talking about the UI. Just the graphical appearance. “It just doesn’t look slick,” complained their project manager. That’s all they could think about. We couldn’t get them to think about the actual functionality. Obviously fixing the graphic design took about one day. It was almost as if they thought they had hired painters.

What’s the lesson? Focus on UI as a top priority.

The parable of Mint and Wesabe

Think UX doesn’t matter for web software?

Let’s take a look at the post-mortem of a recent battle in the online money management space. Here is the reason that the founder of Wesabe cites for losing to Mint:

Between the worse data aggregation method and the much higher amount of work Wesabe made you do, it was far easier to have a good experience on Mint, and that good experience came far more quickly.

He lays much of the blame of Wesabe on not giving the consumer as good of an experience. And, of yeah, Mint just sold for $170 million.

Bad UX is a Bug

So if we all agree that bad UX should be eliminated from the open web, how do we make it a priority? As developers we are hardwired to care about bugs — it’s just in our DNA. So, what if we started treating bad UX as bug?

Sara Summers tells us how to do it:

So I say to all my devs out there: Bad user experience is a bug.

Working code is absolutely necessary to user experience, but there’s more to it. Building experience means facilitating the best ‘feel’ for your audience. You can begin by making the feature/page/experience you’ve created a bug to be checked. Pin it into whatever bug check-in software you’re using. If what you’ve made doesn’t feel enjoyable, simple, clear or trustworthy, mark it.

In order to treat UX as a priority, we need to treat it as a first class bug. That means logging it in our bugtrackers with the rest of the “real” bugs.

The next video in my series on vim is up! Now you too can learn basic navigation in vim: