"I'm about a 7"

Many people (and sociologists!) have noticed that, when you ask someone to rate themselves on a scale of 1 to 10, they give themselves a 7 typically. It doesn't matter what it is.  For example, if you ask someone to rate how well they drive, they'll say 7. I've been in interviews where candidates are asked to evaluate their SQL skills, for instance, on a scale from 1 to 10. Their answer? "I'm about a 7."

 If everyone says they're a 7, one inference to make is that people are not objective when it comes to things close to them, like their children or their own skills. This is sometimes called the 'Lake Wobegon Effect', named after Garrison Keillor's fictional hometown in which 'all children are above average'. You can't trust people to rate themselves, it is inferred. That's why driver's tests, SATs, and other methods of evaluation were invented.

 But another, often-overlooked inference is that people value different things differently. You might value driving fast, while I might value driving safely, or in a way that shows off my car, or in a way that is fuel efficient, or in a way that doesn't remind me of a terrible accident I once had. Since driving can be many things to many people, they answer in terms of what driving means to them when asked abstract questions like, "How good are you at driving?" The reason people are a 7 at SQL is that they know enough to be able to do their jobs, but they could always learn more. There is no absolute standard of SQL-ness that they could rate themselves against. They're a 7 at writing reports, performance tuning, deploying code, or whatever else their (previous) job entails.

9 for fight scenes; 2 for plot

I think this second conclusion is more interesting and more useful. It has consequences for the ways we assess skills, since we never care about someone's skill in general--whatever that might mean--but rather their ability to perform a certain job. They should be asked questions particular to that job, and, if possible, they should demonstrate those specific skills in interviews.

The realization that people value different things differently is also important in everyday life. We'd have a lot fewer arguments about whether or not someone is a good driver, teacher, or cook, or whether or not something is a good movie. Or, at the very least, we'd have more concrete arguments.

And, maybe sociologists would ask us less bizarre questions.

Determining Your Value

This summer I took a break from my extra-vocational studies to reflect upon my career and my plans for the future. There are a surprising number of software career books out there, but I turned to the Pragmatic Press for the Passionate Programmer by Chad Fowler, a saxaphonist/programmer (with no relation to Martin Fowler). I love that the Pragmatic Programmers are passionate about things other than programming, such as woodworking, aviation, or music, but I'm not crazy about the name of the book. I guess the idea is to play off of the Pragmatic Programmer.

A lot of Fowler's advice is common sense, though common sense is not always so common. One of Fowler's most interesting suggestions for me was: your value depends upon your ability to give different people what they need. Writing elegant code, keeping up on the latest technologies, or other technical skills are only a small part of your value as an employee of a company, as you are likely to have a lot of different demands from a lot of different people.

Salespeople could care less about how elegant your code is unless your poor skills lead to performance issues with their reports. Your managers are primarily concerned about managing you. If you are difficult to manage--such as by not showing initiative or not keeping them informed of your bottlenecks--you become less valuable. Your users need someone who understands what they actually do and who can speak their language. If you don't learn their vocabulary, you're not a good programmer. Your teammates need someone they can count on, such as when the production system goes down or you break the build. HR needs you to fill out timesheets. Finance needs you to bring in more money than you cost. If you can't do any of those things, you're not a good programmer.

This piece of advice really hit home with me because, as a philosophical pragmatist, I've long held that there are many factors that could determine a thing's value. Whether or not that thing is valuable to you depends upon how those factors impact you. We often think of a rotten tomato as being bad, but it's only bad if you want to eat a tomato. If you want something to throw at a comedian, it might be just what you need. There's nothing intrinsically good or bad about a rotten tomato. There's no category of 'tomato-ness' that it's not living up to. It's just a rotten tomato.

In the same way, there's no one thing you must do in order to be an excellent programmer--not even programming. Many developers think that they're under-appreciated geniuses who should get paid proportionately to how smart they are. They don't have to worry about writing coherent emails, filling out paperwork, dressing appropriately, or staying after 5:00 PM when the server goes down at 4:59.

If you don't think about your value in the right way, you will not be able to articulate your value when it's time to talk about raises or starting salaries. A great interview question is: "I see you cost X dollars last year. How did you return on that investment?" Often, we're so used to being bombarded with technical questions and thinking about our value from a technical perspective that we cannot answer such questions very well. This is a habit that you should try to break.

It does take some work to become a great programmer. A good way to start is: instead of asking yourself what you need to accomplish today, ask yourself what you need to do for the people who depend on you. Prioritize accordingly.

Links:

-William James's Pragmatism: A New Name for Some Old Ways of Thinking. The first two chapters are classic.