I hate the term "rock star developer"

Yes, I've used the term "rock star developer" before, but now I decided I hate it. Why? Because it's a bullshit term used by people who define a great developer in the wrong ways.

We saw a video clip today at work that made me realize how stupid and misplaced the term is, and how more often than not, businesses measure the value of these people in the wrong way. So this guy in the video was talking about some dude who knew 15 programming languages or something. OK, and why does that matter? Every job I've had, we've used only one programming language (and the same one, at that). More on why that doesn't matter in a moment.

I remember a recent job posting from Calacanis for Mahalo where he talked about how he wanted a rock star, or someone he called a "killer" (I blogged about this before, and he even responded). To him, a dev has to have poor life-work balance, sacrifice everything and apparently have the productivity of several people. Again, what does this have to do with being a good developer?

I've interviewed many developers and had to assemble teams in a quick ad hoc fashion for consulting firms. What I look for is different than what others look for, but the best developers really require only three things to me:

1. They need to know how to code. Duh. They don't need a masters in computer science, or know a dozen languages, or whatever. I suppose they're nice to haves, but it's not required. I can coach and teach a developer to be better at their craft, so as long as they have very strong fundamentals, I don't care if they wrote a compiler.
2. They need to understand the fundamentals of business. Honestly, in my experience this is the thing that is most lacking among developers. Everything you do has a business context to it, and in some places, the decisions you make on things you develop can have an impact on whether or not the business makes money. I'll take it a step further and say that they shouldn't only understand the business, they should enjoy making the business work.
3. They need to look at development as a creative endeavor, particularly if what they do interacts directly with humans. Seeing a toolbox of radio buttons and text boxes and composing them into something is not being creative. That practice ignores the requirements of the end user and what it is they're trying to accomplish. That's why most software sucks. "Engineers" get so hung up on making something on the screen flash that they never ask why it should flash in the first place.

These three ideals should make for obvious requirements, but I don't think they do. The first is like any profession, where you need to know what the tools are and how to use them. The second gives you a higher purpose for the work you do, above simply "coding," because it defines the reason you have a job in the first place. The third leads to better experiences with your customers, which means they'll keep using what you offer.

The next time you hear someone is looking for a rock star, ask them if that comes with a guitar.