Part of Chuck Jazdzewski's fatherly advice to new programmers is this nugget:

Programming is fun. It is the joy of discovery. It is the joy of creation. It is the joy of accomplishment. It is the joy of learning. It is fun to see your handiwork displaying on the screen. It is fun to have your co-workers marvel at your code. It is fun to have people use your work. It is fun have your product lauded in public, used by neighbors, and discussed in the press. Programming should be fun and if it isn't, figure out what is making it not fun and fix it. However, shipping isn't fun. I often have said that shipping a product feels good, like when someone stops hitting you. Your job is completing the product, fixing the bugs, and shipping. If bugs need fixing, fix them. If documentation needs writing, write it. If code needs testing, test it. All of this is part of shipping. You don't get paid to program, you get paid to ship. Be good at your job.

It's true. One key measure of success for any programmer is how much code you've shipped. But merely shipping is not enough. A more meaningful measure of success is to ask yourself how much code you've shipped to living, breathing, real-world users. But then total users doesn't equal total usage, either.

How many users actually use your application? Now that's the ultimate metric of success.

But it's a little scary when you start doing the math. Rich Skrenta explains:

I was just an engineer in this group, but the reality of what was happening in the market to our product line started to seep in. Here I was putting all of this effort into stuff that never would be used by anyone. It was still intellectually challenging...like doing crossword puzzles or something. But it had no utility to the world. I started to look around and I saw many other examples of groups working on stuff that no one would ever use or care about. Mobile IP initiatives, endless work around standards that nobody cared about, research from the labs that would never be applied or even cited. Yikes. I had written stuff that people actually used, before. It felt good. I had written a usenet newsreader that was used by hundreds of thousands of people. I was running an online game, as a commercial hobby on the side, which had several hundred paying customers. Sheesh, I thought. My side projects have more customers than my day job. So I made a simple resolution. I wanted to work on stuff that people would actually use. This sounds simple. But if you walk the halls of Sun, AOL, HP, IBM, AOL, Cisco, Siebel, Oracle, any university, many startups, and even Google and Yahoo, you'll find people working on stuff that isn't going to ship. Or that if it does ship, it won't be noticed, or won't move the needle. That's tragic. It's like writing a blog that nobody reads. People make fun of bloggers who are writing "only for their mother". But what about the legion of programmers writing code paths that will never be traversed?

It's for precisely this reason that I've often wondered if writing code is really the most effective way for software developers to spend their time. A software developer that doesn't write code-- sacrilege, right?

But wait a minute. A smart software developer knows that there's no point in writing code if it's code that nobody will see, code that nobody will use, code that nobody will ultimately benefit from. Why build a permanently vacant house?

A smart software developer realizes that their job is far more than writing code and shipping it; their job is to build software that people will actually want to use. That encompasses coding, sure, but it also includes a whole host of holistic, non-coding activities that are critical to the overall success of the software. Things like documentation, interaction design, cultivating user community, all the way up to the product vision itself. If you get that stuff wrong, it won't matter what kind of code you've written.

If, like Rich Skrenta, you want to work on software that people want to use, realize that it's part of your job to make that software worth using.