4 ms·

> Labor does not receive (or insist on) percent-of-value or percent-of-transaction compensation. This is true of pretty much all engineering jobs, and more bro

by freyr 11y ago

> Labor does not receive (or insist on) percent-of-value or percent-of-transaction compensation. This is true of pretty much all engineering jobs, and more broadly, most non-sales jobs. Commission becomes feasible when you can directly attribute sales or billable hours to a specific person. > Initial salaries are good, but there is wage stagnation. This is true for all engineering jobs, and also most jobs in general. Banking and consulting are exceptions, and as others have pointed out, the attrition rate is quite high in these fields and that skews the numbers somewhat. > In contrast, 5x or more is not unusual in other fields. Care to name some, besides banking and consulting, and possibly corporate law? I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company. Why should programmers be an exception?

sl8r 11y ago
> Care to name some, besides banking and consulting, and possibly corporate law? I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company. This is fair / you're right: I was mainly thinking of banking, consulting, law, and buy-side finance. As you say, though, there are plenty of highly-trained professionals who don't experience a 5x earnings increase over 10 years; functional medical roles (e.g., anesthesiologists) come to mind. Something I was wondering when I wrote the original question -- and I may be way off here -- is whether there are cultural or structural effects in tech-industry programming that cause wage stagnation. For example, there is less wage stagnation for programmers in quant hedge funds than there is in the tech industry; part of this is the clear p&l, of course, but perhaps there is a cultural / structural component as well? I'm not a programmer, but I once heard something that stood out to me: A friend, who was a senior programmer, discovered an inefficient process where he worked. In brief, whenever a certain "event" occurred, the company lost money; the senior programmer noticed this, and built a fix -- no more "events", and hence lots of money saved. From what he told me, my back of the envelope was that by building this (which took him about a week), he saved the company more than $600k a year. I mentioned to him that if he had come in as an outside consultant with a black box solution and offered to charge $100k a year to save the company $600k per year, there was a nonzero chance they would have said "yes"; he laughed and shrugged. This made me wonder whether there is something intrinsically non-value-capturing going on; perhaps (1) tech-industry programming doesn't have a culture of individual-value-capturing, or (2) the role of a programmer doesn't have the structural leverage to reliably capture value. Of course, this story is just anec-data; there may be no conclusions here.
- fsloth 11y ago
  "whether there is something intrinsically non-value-capturing going on" If you mean that it's hard to apply value to an individuals labour in programming you are correct, except in some rare circumstances where there is only one guy at work - then it becomes trivial. Let's look this from the point of view of features and fixes for an individual software product. For a car mechanic, an unserved issue means the single client may switch vendors (cost, say, 1 k). For a software engineer, a botched feature may mean that a category of clients abandon the product (cost:1M+). Ok, from the point of view of catastrophe recovery we know who can save more megabugs. What about delivering value from new features? The car mechanic doesn't create anything new. Let's take the construction worker, then. This is really bad analogy but hold on. The construction worker gets plans, builds the house, and moves on. Architecture, engineering and construction are split to separate people, all of whom have a known cost to their labour. Thus, we have a fixed project and a more or less transparent cost structure. Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things. Writing new software is like playing a combined game of sudoku and mastermind in a dark room - in the best circumstances. Sometimes the lights are on and the board is almost done, and you only need to put one piece down. But - you can't really tell from outside what the situation is. Is the board ready? Did someone mess up the first steps and now they have to start over? The whole thing is like a black box with input and output. The only measure of quality and value is that is the customer satisfied with the data coming out. There is no metric you can gauge the work reliably. From the point of view of the organization the software project is like a black box, into which the team goes to do their work. They yell estimates to the project manager sitting patiently outside, who then writes project reports. After the team declares they are done, the deliverable can be tested. You can send anyone inside the room, but only software engineers understand whats going on. Sometimes a new programmer needs to meditate months inside the room before starting doing changes. Sometimes the black box blows up. Sometimes the team just goes into the box and cries all day without doing any porgress-for months - unknown to the org. I'm sure this gets the imagination going - basically, anything that can happen with a black puzzle box and real people can happen. I'm exaggerating to make a point, of course. But these unknowables make writing software a really risky proposition from the point of the view of the org. And individual can be incredibly productive, or a total failure, and it's really hard to point this out reliably if all are not specialists. That's why, IMO, personal bonuses aren't really helpfull for software projects and fixed company wide bonuses are the only way reward without creating unfair situations. Any KPI based individual bonus system will at worst be destructive, and at best almost completely unfair.
dasil003 11y ago
> I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company. Why should programmers be an exception? One way of looking at programmers is that they are managers of an extremely cheap, fast, scalable, yet stupid, workforce. Once that workforce is put into action it can operate indefinitely. The problem is this workforce is very rigid in what it can do, and it must be told exactly what to do. It also requires a certain amount of maintenance due to security issues and ecosystem rot, but even so, the fundamental nature of this workforce has completely changed the landscape of the global economy by discovery of a new type of worker neither human nor animal. Looking at it in this light, programmers potentially deserve to be paid on the order of top managers and even entrepreneurs and growth-phase directors. But not all of them, because being a programmer entails getting lost deep in the weeds of the mechanics of managing this invisible workforce. So the people who are capable of doing this are not necessarily the type of people who are good at understanding and articulating the business goals. Furthermore, because of the inscrutability of the work to non-programmers it is very difficult to enforce accountability from the outside, and therefore it is all too easy for programmers to become infatuated with operations that actually yield no value to the greater business. At the end of the day programmers can drive businesses just as management can, but the tools are different. This is why I believe calling programmers "engineers" is a misnomer—it's not because real engineering is harder, but because programming is much more open-ended; a running program is literally logic incarnate. There is no limit to what can be done with software, but whether that can be harnessed to create a profitable enterprise is another question.
- Joof 11y ago
  Maybe, but that unfairly biases towards writing types of code that scales when that isn't always the case. Lots of work doesn't scale in the same manner and still needs to get done. Plus the company owns those workers you made now. Of course, the company itself captures most of the created value from this process, so if we're sticking with capitalism I'm fine with making extra money.
LoSboccacc 11y ago
Well, that bit about management is true but sucks. I saved my previous employer 60k years in running cost on my first three month on the job, and couldn't get a 10% raise out of it. Just promises and nice words. Well guess what? If you pay programmers as blue collars and get them to work as blue collar in a "software factory" paying them blue collar wages, you are in a self fulfilling profecy about their value.
- sokoloff 11y ago
  My point of view is that I should cost my company somewhere between 1/5 and 1/3 of the value that I create for them. Less than 1/5th and there's room to pay me more. More than 1/3rd and I'm at risk of getting into the unstable realm where if I or my team hit a temporary rough patch, that the company would be economically ahead to fire us, especially after you consider the amount of "double counting" that goes on. (Engineering builds something that saves $100K/yr. Manufacturing deploys that thing to save $100K/yr. What do you want to bet that the total savings claimed is closer to $200K/yr than $100K/yr?)
  - LoSboccacc 11y ago
    I see what you mean, but putting your work value at the company behest is a losing proposition. My work has value even if the company that commissioned it to me is unable to monetize it. My time has a value which is independent to what the company pays me to actually do. My time would carry the same value even if the company got me to clean bathrooms. If I had the willingness to start a company and spent my time there, how much money would I make? That's the value of my time, but it carries quite some risk. I am not the best at monetizing software, so I outsource the monetization of my time and associated risks to a third party. They do get a substantial cut of the money, which is fine since I get reduced risk. If you tie the value of your time to the capability of the company to direct you doing high value tasks you're starting with the losing foot in any negotiation. What if you gave your time to a charity? What if the company needed you to debug some worthless software in the chain as an emergency? Your time has a value even if what you are told to build in your time from your employer has no value - it's the employer loss, not yours.

by freyr 11y ago

sl8r 11y ago

> Care to name some, besides banking and consulting, and possibly corporate law? I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company. This is fair / you're right: I was mainly thinking of banking, consulting, law, and buy-side finance. As you say, though, there are plenty of highly-trained professionals who don't experience a 5x earnings increase over 10 years; functional medical roles (e.g., anesthesiologists) come to mind. Something I was wondering when I wrote the original question -- and I may be way off here -- is whether there are cultural or structural effects in tech-industry programming that cause wage stagnation. For example, there is less wage stagnation for programmers in quant hedge funds than there is in the tech industry; part of this is the clear p&l, of course, but perhaps there is a cultural / structural component as well? I'm not a programmer, but I once heard something that stood out to me: A friend, who was a senior programmer, discovered an inefficient process where he worked. In brief, whenever a certain "event" occurred, the company lost money; the senior programmer noticed this, and built a fix -- no more "events", and hence lots of money saved. From what he told me, my back of the envelope was that by building this (which took him about a week), he saved the company more than $600k a year. I mentioned to him that if he had come in as an outside consultant with a black box solution and offered to charge $100k a year to save the company $600k per year, there was a nonzero chance they would have said "yes"; he laughed and shrugged. This made me wonder whether there is something intrinsically non-value-capturing going on; perhaps (1) tech-industry programming doesn't have a culture of individual-value-capturing, or (2) the role of a programmer doesn't have the structural leverage to reliably capture value. Of course, this story is just anec-data; there may be no conclusions here.

fsloth 11y ago
"whether there is something intrinsically non-value-capturing going on" If you mean that it's hard to apply value to an individuals labour in programming you are correct, except in some rare circumstances where there is only one guy at work - then it becomes trivial. Let's look this from the point of view of features and fixes for an individual software product. For a car mechanic, an unserved issue means the single client may switch vendors (cost, say, 1 k). For a software engineer, a botched feature may mean that a category of clients abandon the product (cost:1M+). Ok, from the point of view of catastrophe recovery we know who can save more megabugs. What about delivering value from new features? The car mechanic doesn't create anything new. Let's take the construction worker, then. This is really bad analogy but hold on. The construction worker gets plans, builds the house, and moves on. Architecture, engineering and construction are split to separate people, all of whom have a known cost to their labour. Thus, we have a fixed project and a more or less transparent cost structure. Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things. Writing new software is like playing a combined game of sudoku and mastermind in a dark room - in the best circumstances. Sometimes the lights are on and the board is almost done, and you only need to put one piece down. But - you can't really tell from outside what the situation is. Is the board ready? Did someone mess up the first steps and now they have to start over? The whole thing is like a black box with input and output. The only measure of quality and value is that is the customer satisfied with the data coming out. There is no metric you can gauge the work reliably. From the point of view of the organization the software project is like a black box, into which the team goes to do their work. They yell estimates to the project manager sitting patiently outside, who then writes project reports. After the team declares they are done, the deliverable can be tested. You can send anyone inside the room, but only software engineers understand whats going on. Sometimes a new programmer needs to meditate months inside the room before starting doing changes. Sometimes the black box blows up. Sometimes the team just goes into the box and cries all day without doing any porgress-for months - unknown to the org. I'm sure this gets the imagination going - basically, anything that can happen with a black puzzle box and real people can happen. I'm exaggerating to make a point, of course. But these unknowables make writing software a really risky proposition from the point of the view of the org. And individual can be incredibly productive, or a total failure, and it's really hard to point this out reliably if all are not specialists. That's why, IMO, personal bonuses aren't really helpfull for software projects and fixed company wide bonuses are the only way reward without creating unfair situations. Any KPI based individual bonus system will at worst be destructive, and at best almost completely unfair.

dasil003 11y ago

> I'd suggest that in most fields, you don't make significantly more money until you're managing a significant percentage of people, or tasked with making decisions that set the direction the company. Why should programmers be an exception? One way of looking at programmers is that they are managers of an extremely cheap, fast, scalable, yet stupid, workforce. Once that workforce is put into action it can operate indefinitely. The problem is this workforce is very rigid in what it can do, and it must be told exactly what to do. It also requires a certain amount of maintenance due to security issues and ecosystem rot, but even so, the fundamental nature of this workforce has completely changed the landscape of the global economy by discovery of a new type of worker neither human nor animal. Looking at it in this light, programmers potentially deserve to be paid on the order of top managers and even entrepreneurs and growth-phase directors. But not all of them, because being a programmer entails getting lost deep in the weeds of the mechanics of managing this invisible workforce. So the people who are capable of doing this are not necessarily the type of people who are good at understanding and articulating the business goals. Furthermore, because of the inscrutability of the work to non-programmers it is very difficult to enforce accountability from the outside, and therefore it is all too easy for programmers to become infatuated with operations that actually yield no value to the greater business. At the end of the day programmers can drive businesses just as management can, but the tools are different. This is why I believe calling programmers "engineers" is a misnomer—it's not because real engineering is harder, but because programming is much more open-ended; a running program is literally logic incarnate. There is no limit to what can be done with software, but whether that can be harnessed to create a profitable enterprise is another question.

Joof 11y ago
Maybe, but that unfairly biases towards writing types of code that scales when that isn't always the case. Lots of work doesn't scale in the same manner and still needs to get done. Plus the company owns those workers you made now. Of course, the company itself captures most of the created value from this process, so if we're sticking with capitalism I'm fine with making extra money.

LoSboccacc 11y ago

Well, that bit about management is true but sucks. I saved my previous employer 60k years in running cost on my first three month on the job, and couldn't get a 10% raise out of it. Just promises and nice words. Well guess what? If you pay programmers as blue collars and get them to work as blue collar in a "software factory" paying them blue collar wages, you are in a self fulfilling profecy about their value.

sokoloff 11y ago
My point of view is that I should cost my company somewhere between 1/5 and 1/3 of the value that I create for them. Less than 1/5th and there's room to pay me more. More than 1/3rd and I'm at risk of getting into the unstable realm where if I or my team hit a temporary rough patch, that the company would be economically ahead to fire us, especially after you consider the amount of "double counting" that goes on. (Engineering builds something that saves $100K/yr. Manufacturing deploys that thing to save $100K/yr. What do you want to bet that the total savings claimed is closer to $200K/yr than $100K/yr?)
- LoSboccacc 11y ago
  I see what you mean, but putting your work value at the company behest is a losing proposition. My work has value even if the company that commissioned it to me is unable to monetize it. My time has a value which is independent to what the company pays me to actually do. My time would carry the same value even if the company got me to clean bathrooms. If I had the willingness to start a company and spent my time there, how much money would I make? That's the value of my time, but it carries quite some risk. I am not the best at monetizing software, so I outsource the monetization of my time and associated risks to a third party. They do get a substantial cut of the money, which is fine since I get reduced risk. If you tie the value of your time to the capability of the company to direct you doing high value tasks you're starting with the losing foot in any negotiation. What if you gave your time to a charity? What if the company needed you to debug some worthless software in the chain as an emergency? Your time has a value even if what you are told to build in your time from your employer has no value - it's the employer loss, not yours.