14 ms·

The top rated comment on this question asserts that the reason why programmers have lower salaries is because they are logical, intelligent individuals who refu

The top rated comment on this question asserts that the reason why programmers have lower salaries is because they are logical, intelligent individuals who refuse to play the politics game and thus are hated by executives. Not only it this incorrect (have you seen the politics in certain open source software projects ?) but it plays into a narrative that programmers want to believe: business people are corrupt and programmers are superior to them morally if not in compensation. You're doing yourself a disservice if you follow this line of thinking. On the other hand, the top rated answer has a pretty elaborate and abstract theory about widgets and film makers. I make no assertion about the accuracy of this abstract theory, but I can summarize reality in a much simpler way: many programmers work in businesses where software is a cost center. If you want to make money as a programmer, you need to work at a company where software is a generator of profit and negotiate compensation aggressively after demonstrating your value. The following is required reading if you'd like an algorithm for doing the above: Don't Call Yourself A Programmer, And Other Career Advice http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro... Salary Negotiation: Make More Money, Be More Valued http://www.kalzumeus.com/2012/01/23/salary-negotiation/ http://www.kalzumeus.com/2012/01/23/salary-negotiation/

dpeck 14y ago
"many programmers work in businesses where software is a cost center. If you want to make money as a programmer, you need to work at a company where software is a generator of profit and negotiate compensation aggressively after demonstrating your value." This is right on. Looking back to when I was finishing my degree an older friend of mine advised that if possibly you shouldn't work for a company who's primary income stream isn't what you do. I still think this is a fantastic suggestion. Not everyone can be an important member of the R&D group for their employer, but if you've got the chops why shouldn't you be? I find that doing that you get the best of both worlds. You're valued enough that you get shielded from most of the office prattle and politics, you usually report very high up the hierarchy ( I've never reported less than one level down from executive team, and usually its been directly to a C-level position), and these teams tend to be full of others who know their shit and will make you better. Of course the compensation is usually quite good too, and bonus you're unlikely to be held to a standard soul sucking 9-5 schedule, or God forbid have to be on call.
- throwaway1979 14y ago
  Actually, being in the R&D group pretty much guarantees that you aren't in the income stream. You are in the futuristic stuff stream. If costs need to be cut, guess what impacts current revenues the least?
  - dpeck 14y ago
    I'll grant you that. If times get hard future revenue generation can often be sacrificed to make sure that the business can get through the "now" part. I think I'd likely look at that as a blessing, if things are going downhill for everyone at least you're lucky enough to know and get out early. Also, I should mention that in my case the research generated is often used as an intelligence source for the current products. In the early days of my career my teams research resulted in a constant stream of snort rules, vulnerability discoveries, and bypass techniques that often made their way into the products/services of the company. Those 2-3 times a week updates being pushed down to client devices were a big part of the perceived value that the customers received. Modern software and service driven models mean that there doesn't have to be much of a gap between research and deployment.
Retric 14y ago
Everything is a cost center even sales until you start looking at larger chunks of an organization. As long as you can demonstrate an increase in profit you can easily justify a huge salary regardless of what part of an organisation you work for. 'I did X which generated Y cost savings' works just as well as 'I brought in X business at Y profit margin generating Z profit.' edit: Typical examples include research and development, marketing and customer service.[1] http://en.wikipedia.org/wiki/Cost_centre_(business) http://en.wikipedia.org/wiki/Cost_centre_(business) PS: I updated the data entry screen, increasing our call center's throughput by 3% creating 5 million in savings over the next 3 years.
lmkg 14y ago
Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one. I suspect programmers are less correct in their assumption than they would like to believe. Probably more correct than the other two groups of employees, but still less than correct. The sad fact is, most programmers (especially non-entrepreneurs) don't "get" what PM's and BA's do, the same way that most managers don't "get" what programmers do, but their role still provides value (if they're good at their job). The nature of their job often involves filtering crap for their programmers, so the better job they're doing, the more invisible they look. The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters. Of course, the above is a perfect world, which is about as common as the mythical sufficiently-smart compiler. Which is to say, it never exists and never will. Nonetheless, there are such things as PM's that provide value. My experience is that ones with non-negative value are about one-in-four, ones with measurably positive value are less than one-in-ten, and if you find one you should pay what it takes to keep them around. YMMV. ---- That said, there are reasons why PM's are paid more than their value more often than programmers are. I agree with the majority of these, but I'm restricting my contributions to the portions of my opinions which aren't echoed throughout this thread.
- flatline3 14y ago
  > Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one. This is all true. However, you forgot this additional piece: Managers and business analysts generally sit higher in the organizational chart than programmers, and thus have an advantage when negotiating salaries, presenting the programmer's relative value to the rest of the organization, etc. > The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters. However, many would argue that translating abstract business requirements into technical requirements is a technical matter. That said, the notion that programmers always make less is not universally true, and many organizations are more sane about paying commiserate with value generated.
ojbyrne 14y ago
Theory X (people only work hard when figuratively whipped) and Theory Y (people only work hard when treated like professionals) are real things in HR management. But they've largely been superseded by Theory Z (both Theory X and Theory Y have value, but a bit of both works best).
photon137 14y ago
I totally agree with this. I am a quant working at a bank writing trading strategies in C++. I have a colleague in "Infrastructure" (they call it) who sits two desks away from me and he writes C++ code that loads my code and runs it on a massive grid, does load balancing, interfacing and all kinds of cool stuff. Yet he's in a "cost-center" and I'm in a revenue-center when, basically, without his work my code would be as useful as European politicians right now. This is insane but that's the sign of organizations that have hierarchies misaligned with what generates value for them. Basically, such organizations haven't figured out how to assign such "hidden" value a number while in my case it's simple to judge the value generated. (Actually, sometimes the ones in power are too afraid to admit they'd be useless without these guys). Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers.
- brazzy 14y ago
  > Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers. That's exactly the same kind of self-bullshitting your parent comment was arguing against. NONE of the parts of a business can really work effectively without the others. A bunch of super-smart skilled programmers with attitudes, no leaders and no clear requirements is going to produce a lot of efficient, scalable, well-designed code that represents a handful of sub-projects that can't be integrated and don't do anything useful to end users.
  - trobertson 14y ago
    I realize this is an extreme case, but you should check out Valve's corporate structure. No one has a "title", everyone can move to whatever project that want to work on, and they still turn out excellent software.
    - mprovost 14y ago
      ...but not on schedule.
      - 14y ago

dpeck 14y ago

"many programmers work in businesses where software is a cost center. If you want to make money as a programmer, you need to work at a company where software is a generator of profit and negotiate compensation aggressively after demonstrating your value." This is right on. Looking back to when I was finishing my degree an older friend of mine advised that if possibly you shouldn't work for a company who's primary income stream isn't what you do. I still think this is a fantastic suggestion. Not everyone can be an important member of the R&D group for their employer, but if you've got the chops why shouldn't you be? I find that doing that you get the best of both worlds. You're valued enough that you get shielded from most of the office prattle and politics, you usually report very high up the hierarchy ( I've never reported less than one level down from executive team, and usually its been directly to a C-level position), and these teams tend to be full of others who know their shit and will make you better. Of course the compensation is usually quite good too, and bonus you're unlikely to be held to a standard soul sucking 9-5 schedule, or God forbid have to be on call.

throwaway1979 14y ago
Actually, being in the R&D group pretty much guarantees that you aren't in the income stream. You are in the futuristic stuff stream. If costs need to be cut, guess what impacts current revenues the least?
- dpeck 14y ago
  I'll grant you that. If times get hard future revenue generation can often be sacrificed to make sure that the business can get through the "now" part. I think I'd likely look at that as a blessing, if things are going downhill for everyone at least you're lucky enough to know and get out early. Also, I should mention that in my case the research generated is often used as an intelligence source for the current products. In the early days of my career my teams research resulted in a constant stream of snort rules, vulnerability discoveries, and bypass techniques that often made their way into the products/services of the company. Those 2-3 times a week updates being pushed down to client devices were a big part of the perceived value that the customers received. Modern software and service driven models mean that there doesn't have to be much of a gap between research and deployment.

Retric 14y ago

Everything is a cost center even sales until you start looking at larger chunks of an organization. As long as you can demonstrate an increase in profit you can easily justify a huge salary regardless of what part of an organisation you work for. 'I did X which generated Y cost savings' works just as well as 'I brought in X business at Y profit margin generating Z profit.' edit: Typical examples include research and development, marketing and customer service.[1] http://en.wikipedia.org/wiki/Cost_centre_(business) http://en.wikipedia.org/wiki/Cost_centre_(business) PS: I updated the data entry screen, increasing our call center's throughput by 3% creating 5 million in savings over the next 3 years.

lmkg 14y ago

Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one. I suspect programmers are less correct in their assumption than they would like to believe. Probably more correct than the other two groups of employees, but still less than correct. The sad fact is, most programmers (especially non-entrepreneurs) don't "get" what PM's and BA's do, the same way that most managers don't "get" what programmers do, but their role still provides value (if they're good at their job). The nature of their job often involves filtering crap for their programmers, so the better job they're doing, the more invisible they look. The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters. Of course, the above is a perfect world, which is about as common as the mythical sufficiently-smart compiler. Which is to say, it never exists and never will. Nonetheless, there are such things as PM's that provide value. My experience is that ones with non-negative value are about one-in-four, ones with measurably positive value are less than one-in-ten, and if you find one you should pay what it takes to keep them around. YMMV. ---- That said, there are reasons why PM's are paid more than their value more often than programmers are. I agree with the majority of these, but I'm restricting my contributions to the portions of my opinions which aren't echoed throughout this thread.

flatline3 14y ago
> Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one. This is all true. However, you forgot this additional piece: Managers and business analysts generally sit higher in the organizational chart than programmers, and thus have an advantage when negotiating salaries, presenting the programmer's relative value to the rest of the organization, etc. > The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters. However, many would argue that translating abstract business requirements into technical requirements is a technical matter. That said, the notion that programmers always make less is not universally true, and many organizations are more sane about paying commiserate with value generated.

ojbyrne 14y ago

Theory X (people only work hard when figuratively whipped) and Theory Y (people only work hard when treated like professionals) are real things in HR management. But they've largely been superseded by Theory Z (both Theory X and Theory Y have value, but a bit of both works best).

photon137 14y ago

I totally agree with this. I am a quant working at a bank writing trading strategies in C++. I have a colleague in "Infrastructure" (they call it) who sits two desks away from me and he writes C++ code that loads my code and runs it on a massive grid, does load balancing, interfacing and all kinds of cool stuff. Yet he's in a "cost-center" and I'm in a revenue-center when, basically, without his work my code would be as useful as European politicians right now. This is insane but that's the sign of organizations that have hierarchies misaligned with what generates value for them. Basically, such organizations haven't figured out how to assign such "hidden" value a number while in my case it's simple to judge the value generated. (Actually, sometimes the ones in power are too afraid to admit they'd be useless without these guys). Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers.

brazzy 14y ago
> Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers. That's exactly the same kind of self-bullshitting your parent comment was arguing against. NONE of the parts of a business can really work effectively without the others. A bunch of super-smart skilled programmers with attitudes, no leaders and no clear requirements is going to produce a lot of efficient, scalable, well-designed code that represents a handful of sub-projects that can't be integrated and don't do anything useful to end users.
- trobertson 14y ago
  I realize this is an extreme case, but you should check out Valve's corporate structure. No one has a "title", everyone can move to whatever project that want to work on, and they still turn out excellent software.
  - mprovost 14y ago
    ...but not on schedule.
    - 14y ago