I’m going to tell you the secret of being a top developer. It’s the actual foundation that underlies the various advice you may have read in the past about how to improve your craft. It’s a subtle epiphany, so it may require that you read this a few times for it to really sink in.

Before we get there, let me tell you about Michael. Michael is the project manager on the infrastructure project that has been ongoing for about 7 weeks now at Ideal. One of the ways he put me at ease with the process was to describe his lead developer, Praveen, as a “rockstar.”

For those of you who aren’t part of the geek culture, rockstar is an insider term — a magic word that lets developers know when someone else is “in the know.” Having the president of a company use that word, said to me that this guy had his finger on the pulse, and he knew the difference between good and bad development.

I was gullible to be persuaded so easily. Such is the power of tribal signals, c’est la vie.

Are you sure you’re in the band?

I have been described as “the real deal” — the fabled “rockstar” developer that Praveen was rumored to be.

I think there are people “out there” who can code circles around me, but I have not met them, and I am certainly an expert in at least web development and related disciplines. What most people don’t realize is that the chasm between rockstar and roadie is not made of technical merit. It’s not only a deep understanding of the technical systems, but a holistic view of the development process that allows a developer to figure out the correct problems to solve in the first place.

I “get” the tiny, system-level implementation details that most developers don’t have a clue about, and that makes me a good developer–a valuable addition to any team. The difference that really pushes me over the threshold is that I also really “get” what my software does, and what it means to people, and how they will use it.

My software does exactly what it’s supposed to do, in exactly the way my users expect it to.

Praveen is a different species of developer. He suffers under the misconception that software is about variables, functions, and objects. He believes that if the database returns the correct results, and he can vomit those results into the user’s eye sockets somehow, then his job is done.

This is the first thing I noticed in the system Praveen is building for me: I can see that the functionality exists in some way, but I can only see that because I’m an expert in the language he coded it in, and even then it barely works.

As a test, I tried to add a ticket to the development queue which is the primary purpose of this software. After hacking the button to work with my client-side debugger, I was able to see the input screen, which I tried to use, causing a fatal error.

I pointed out this egregious error that ensured any attempt to a add a development ticket to the queue would fail. Praveen “fixed” the error. To Praveen bugs and program interaction are isolated, so his fix was great — if it was the only ticket in the system and the user was on a full privilege administrator account.

It still failed spectacularly if the user did anything out of the ordinary, like select an existing ticket before pressing “create new ticket,” or if the new ticket wasn’t on page 1 of the list. In addition, he didn’t fix the same bug in the parallel support ticket system — lord knows why it’s a separate code base to begin with.

Utility and Pain

This mentality is what holds Praveen back. A very small part of this is that Praveen isn’t very good at the language he writes — that’s a prerequisite for rockstardom, but it’s not enough. If Praveen had the makings of a rockstar he would go further. He would really think about how people are going to interact with the system, and make intelligent guesses about the ways he could make that interaction… get ready for it… more useful and less painful.

And it’s not just a question of user interface. It’s also a question of programmer interface, which is exactly what people mean when they talk about “code maintainability.” How useful and painless is the structure of this code to change or build on?

Focusing on these key ideas of utility and pain to the various stakeholders virtually guarantee the rest of the geek best practices like proper testing and documentation take care of themselves. It’s not because they become automatic somehow, but because they serve a higher purpose so their value becomes self-evident. Instead of a burden, these practices become stepping stones to your useful, painless software that just makes people feel happy to use.

Is your software intensely useful and absolutely painless? Well then, rock on.