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.