One thing that separates successful career programmers from those with a bit…less success (we won’t call it failure, because it usually doesn’t manifest as abject failure, but rather as stunted potential) is their ability to figure out their value to the people who are retaining their services. Regardless of what that job posting says, what the recruiters tell you (more on this in a minute), or what you’d like to hear, you are NOT ever hired into a position simply to write code. You are hired to solve a problem that someone has, with the expectation that your solving of said problem presents an advantage greater than that provided by simply keeping (or using elsewhere) the money required to hire you. It’s a simple thing that is missed fairly frequently when discussions of programmer salaries come up, as well as when programmers sit and complain about the messes they deal with at their jobs. It also happens in just about every other industry. I’ve had similar discussions with people in other industries. The fitness industry, for instance, is loaded with people who live under the belief that the fitness program they are selling is actually the reason they have clients, instead of what the clients are actually there for, such as losing weight, gaining muscle, just the feeling of accomplishment and pushing past obstacles, etc. The dividing line between the successful ones in that industry and those who are unsuccessful is also remarkably similar, in that the latter fail to line up their offerings with what their customers are actually buying, versus what they think they are selling.

In addition, many developers make mistakes about who their actual client is. If you are building software for resale, unless you are the owner of the company, your client is not the buyer of that software, no matter who tells you otherwise. It’s the owner of the company and THEIR client is the one buying the software (assuming they don’t have reseller channels and other things in the mix further complicating the picture). This doesn’t mean, by the way, that you aren’t in a position to improve the client experience. You most certainly are, but a successful approach will not look the same as it would in a case where the client is your direct customer, nor should it.

Finally, many, if not most, developers seem to have a very difficult time figuring out where others’ value comes from, and to whom they are providing that value. This results in a great deal of misplaced disappointment when developers interact with certain groups, often due to the developer incorrectly understanding who the person is working for. Two of the most common groups who receive such ire are Human Resources and recruiters. As a developer, you need to remember that neither group works for you (as in, neither group is getting a check from you directly). That doesn’t make them useless, but it should inform you how to discuss things with them. Sometimes, that means NOT discussing the matter at hand with them, because it doesn’t matter to them.

In the case of HR, they work for the company, not for you, and their interest is in protecting the company from the expense of lawsuits and turnover while making sure that departments are able to staff themselves. Going to them with a complaint isn’t going to make them budge most of the time, unless the problem in question is a substantial monetary risk for the company. If it is, they are remarkably quick about acting on it, but if it isn’t, you shouldn’t be surprised when the complaint disappears out into the ether. They aren’t your employees and your irritation over how long staff meetings are is sort of irrelevant for their interests (and that of the people paying them). On the other hand, if something is an actual danger to others or could possibly result in a lawsuit, then getting them involved will speed things up.

In the case of recruiters, you are also not the one paying them. Well, who is? Turns out that it is the company that employs them, usually on a commission basis. Their company is paid by the firm that is looking for employees. You’ll note that nowhere in here is a monetary contribution from you – they frequently get a slice of the money from the hours that you work, but that is radically different than you paying them directly. That doesn’t make recruiters useless, but it does mean that you need to understand how their work gets done so that you can interact with them effectively. It is more reasonable to view them as an outsourced HR/hiring department for the companies they are representing, rather than your personal agent as if you were a celebrity. They aren’t the recruiting agent looking for the next Metallica, they are the venue that sticks Metallica on stage. They still have to make Lars happy to get their slice of the pie, but they get their money from the people paying for the show. It’s this distinction that gets developers in trouble, I think, believing that the recruiters work for you. They don’t. You are the product. That’s not a bad thing, because you need to eat. But it should inform your approach. You need to be aware of (and constantly cultivating) your value. When you do this, recruiters are suddenly a free marketing channel for your services, rather than an annoyance that rings your phone 8 times a day every time some local sweatshop starts hiring. You should no more go to a recruiter with no marketable skills and no resume than Dan’s Generic Garage Band from Podunk Kentucky should approach a venue that seats a thousand with the expectation that they’ll sell tickets out of the goodness of their heart. It doesn’t happen that way, never has.

Returning to the original premise, that being that your value is not your profession. No one is hiring you to write software. Business cards, job titles, and pedantic rants about choices of programming languages and data access frameworks aside, you will seriously restrict your career options (and be easily and happily replaced by outsourced labor as well) if you run your career as if your boss “just wants code written”. Your value is in solving a problem, usually by writing code. That should similarly inform your interactions with management. Here are some common scenarios along with how I’ve seen developers approach it, both successfully (Genius) and unsuccessfully (Dingus).

1. You want to switch from the X framework to the Y framework for data access. The Y framework stops using nasty stored procedures and has a nice ORM layer, and even allows asynchronous operations, retries, and caching without extensive additional work. Dingus: We should use the Y framework. It’s so much easier to work with and will be good for our careers. Genius: We may want to consider switching to the Y framework. The ORM will make it easier for us to surface new features more quickly, will make it easier to get new developers up to speed, and will be more stable and faster due to the built in retry capability and the caching. Breakdown: Dingus is suggesting what is good for HIM, not good for the guy making the decisions. In addition, he’s not putting the guy in the position to be the source of the decision himself. If it’s such a good decision, let your manager take credit. He’s going to need a second in command once he moves up. Finally, Dingus just suggested Resume-Driven-Development (ie., teach me how to do this at your expense so I can work for your competitors for a modest raise).
2. The staff meeting happens at 8:30 every morning. This is annoying for you, as it means you have to rush into the office, barely have time to get your stuff together and get coffee, start your day off with something that makes you drowsy, and then have a narrow gap in between the staff meeting and lunch, which pretty well destroys the morning’s productivity. This needs fixing. Dingus: The morning meeting sucks. Everybody is tired and it is hard on me to get in on time for it. Genius: Hey, I’ve noticed something. The timing of the morning meeting seems like it might be a little early for some of us, and is easily messed up if traffic is ever backed up. Do you think we could try putting it a little later in the morning, perhaps even right before lunch? I’ve noticed it breaks up my concentration in the morning, which is when I do my best work (as do several others on the team) and I’m wondering if there might not be a more optimal place for it on the schedule. Breakdown: Dingus is simply whining. He has a legitimate complaint, but notice how the entire tirade is about how the problem impacts him and his feelings on it. Genius notices the problem and points out how it could be causing a problem for the boss. In addition, he phrases his request in a way that is not confrontational, plus it enlists himself in the process of helping the boss fix the issue. It also allows the boss to be the one that makes the adjustment, which is critical for not eroding his power (which will help you when he promotes you someday, or writes a good referral for you) and avoids meaningless confrontation (notice that I’m not suggesting here to avoid all confrontation, but stupid confrontation is worthless from a career perspective).
3. The company does not allow employees to work from home, but allows VPN access to workstations in the event of deployments and emergencies. You’d love to be able to work from home a couple of days a week, both to avoid the expense and time of travel, and simply to have a better working environment. Dingus: We should allow people to work from home a couple days a week. It’ll get rid of the commute and give me more time with the kids. Genius: Hey, do you mind if I work remotely on Tuesday? It’s our anniversary and I need to be home early so that we can leave on time to get to the restaurant, but I don’t want to just do a half day, considering all the work that we have to get done before the next release. [Genius then gets a little more done on Tuesday than he normally would and mentions it in passing to the boss as being curious]. Breakdown: Dingus still believes that the whole thing is about his feelings. It isn’t. Genius, however, realizes that his boss is likely not the one setting the work from home policy. He is planting a seed that he will have to carefully water for a while, probably while going through the same exercise a few more times, before work-from-home is cleared from further up the chain of command. In this case, he realizes that the person he needs to sell the idea to is not his immediate supervisor and he lays the groundwork for his supervisor to sell the idea instead. Dingus’s approach will make management even more resistant to the idea of working from home, while potentially creating friction between himself and his supervisor.
   The point of this whole thing is simple: Incentives Matter. You need to figure out which incentives (and from whom) an individual you are working with is responding to. Usually, when you know what those are, you can come up with a way to improve things for both of you. It doesn’t always work, but your odds are better than what happens when you assume someone is being incentivized by something that doesn’t actually motivate them at all. The surprises there are almost universally unpleasant. Knowing who you are dealing with and who pays them as, in many cases, more impact on the final result of a discussion than does being right.