The labor market for programers in the tech industry has two features (anecdotally observed) that are interesting to me:
1. Labor does not receive (or insist on) percent-of-value or percent-of-transaction compensation. This is in contrast to some other professional disciplines (e.g., salespeople often get paid on a percentage or commission, bankers often take a % cut, pe / vc / hf has 2% and 20%, real estate is on a %, lawyers may get paid on a % ("contingent fees"), etc.)
2. Initial salaries are good, but there is wage stagnation. Just-out-of-college salaries for programming are often better than virtually everything else (notably, banking and consulting); but after ten years, the opposite is relationship is reversed (considerably so). The difference between a newgrad salary and a 10-yearer salary for tech-industry programmers is often (in my anecdotal experience) less than 2x. In contrast, 5x or more is not unusual in other fields.
> out-of-college salaries for programming are often better than virtually everything else (notably, banking and consulting); but after ten years, the opposite is relationship is reversed (considerably so)
Don't forget that there is huge flight from banking and consulting, but much less so for programming. Of 10 people who start as bankers or consultants, 80% will likely leave the industry within 5 years, and 90% within 10 years. So, in a way you're comparing the salary growth of a median programmer to the salary growth of a top 5-10% banker.
This is an interesting point; thanks! Found this article incase anyone is interested. One quote stood out to me:
> Private equity recruitment firm PER conducts an ‘unofficial count’ into how many analysts join the M&A and corporate finance teams of six leading banks in London. In 2010, PER calculated that 250 people joined a combination of Bank of America, Citigroup, Credit Suisse, Goldman Sachs, JPMorgan and Morgan Stanley. After tracking those individuals for three years, it recently calculated that 140 of them are still working in banking. That’s an attrition rate of 44%.
That's consistent with the staffing ratios within the firm (Wikipedia suggests thare are ~400 directors compared to about 9000 total consultants). Those are the ones who stuck around for more than a decade.
This is the employment equivalent of Betz' law from wind power. Before you throw that idea out as ridiculous let me explain.
Betz' law states that there is an upper limit to the amount of power that you can extract from a given mass of moving air (aka wind). The plainest explanation is that the wind has to go somewhere in order to be able to bring in fresh wind. If you extract all the energy then the air would have to pool around the windmill and then eventually the pressure differential would drop to 0 and there would be no more wind. So you give up some of the energy and use it to remove the air after you're done extracting energy from it.
The parallel is that if up-or-out wasn't a fact that these companies would sooner or later run out of room in their org chart to bring in fresh recruits at the bottom. This would stop them from hiring the occasional gem that they will promote to the top of that chart. So to be able to hire the really good people they have to create room at the bottom, they have to get rid of a certain percentage of their people at all levels every year to keep the machinery moving.
It's an expensive affair but in the longer term it makes good business sense. Both windmills and really big companies are extraction devices.
> 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.
> 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.
Isn't this just how employment works? If you build something and it turns out to have been a total waste of time and energy, you get paid all the same. If you build something and it turns out to save the company $600k a year, you also get paid, but the surplus value goes to the company in exchange for substantially reducing your financial risk. You can't have it both ways: if you want to capture more of the value, you need to share in more of the risk.
"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.
> Software is nothing like building a house except in rare circumstances. Real world construction projects are mostly about creating linear combinations of known things.
Have you actually built a house before? The plans never quite match up to the reality. It always takes longer than you think, and costs more. No house is exactly the same as another. Every house has bespoke parts to it. Shoddy construction happens often, and fixing the issues that result can cost more than initial construction. And then the customer changes their mind, causing costly rework that never quite fits properly into the initial design. I would say building software is very much like building a house.
"I would say building software is very much like building a house."
Yeah, it's good to remind that making anything new and not mass produced is always messy. I would still claim that software only goes more insane from that since there are very little constraints to the work and it's less understandable as a whole. House at least is bound to the basic laws of physics. One cannot mess up the local universe so that walking through any arbitrary door takes one suddenly to the toilet. In software, on the other hand, one needs to design the constraints oneself (I'm generalizing again, of course).
Yes, civil engineers use a 30% - 40% fudge factor to deal with those unforeseen costs. They often get the costs wrong, sometimes it's nearly twice more, but those times are rare.
Software developers normally apply a 200% - 500% fudge factor do deal with unforeseen costs. Problem is, they are usually wrong by an order of magnitude or two, at whatever direction.
> 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.
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.
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.
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?)
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.
Your second paragraph talks about the value of your time to you and in that sense, it's true. From the company's point of view of your time, your second paragraph is somewhere between irrelevant and false.
You hit the nail on the head that we're giving up a lot of the value "pie" in exchange for much lower risk. My mindset takes that one step farther: ensure that everyone's economic goals are aligned and stably pointed to continued employment of me and my team. That requires an exchange of my time for the company's money at a rate low enough that it's obvious to the company they're getting an economic gain from buying it and high enough that it's obvious to me that I'm getting an economic gain from selling it.
If those ranges don't overlap, you have a very unstable situation. When those ranges have large overlap, many different valuations of time are stable and mutually beneficial.
>What if the company needed you to debug some worthless software in the chain as an emergency?
If the software I'm debugging is worthless, it's hard to imagine there's a genuine emergency involving it. The mere fact that there's an emergency involving it means it has some value to someone.
Point 1 makes sense, to the degree that it's true. Programmers are typically too far removed from actual transactions to get paid in the way that sales, bankers, real estate agents, etc. are paid. Thus, measuring what they're actually responsible for is difficult.
To the extent it can be done at that level of abstraction, I'd argue that programmers are actually very over-represented in being paid based on hard outcomes. I haven't heard of any other profession with such a focus on equity grants.
This is interesting, I would be more bold and call these problems instead of features, as I think programmers deserve better. (Then again I may be biased!)
Problem 1 is more systemic and harder to solve.
For Problem 2 I feel there may be a way to strategize around it. Specifically, wondering if there is a point where salaries increase, and then after a certain point, rate of salary increase drops off at which point it may be beneficial to do a masters, phd, MBA or some professional work to refresh the resume. Either that, or perhaps dedicate some time (in lieu of higher ed) to some interesting open source project. Thinking more about economy of time here than education, education is just a way to make this concrete.
I'd be very hesitant to push a system that gave significant bonuses to salary increases based on going out and getting an additional degree. A.) Does the material in the additional education in any way contribute to making you better/more efficient/whatever at your job? B.) The risk of bullshit diploma mills goes up again.
I have family in education, and many districts have incentive programs for teachers to get Master's degrees, so that in addition to the pay bump, they get some or all of the tuition covered. I've known a number of people who've done this, and not one says that it helped them do a better job as a teacher - the programs were big rubber-stampers, and the only real outcome is that they are now not quite so pitifully paid.
This is very much a requirement for promotion in federal service. I've joked I'd get paid less than my wife whom holds a masters in government when I currently make 5x what she does and I'm currently underpaid.
You can never make good money as a programmer, if you let non-programmers pick the subject, or let non-programmers monetize the platform in your stead. Google and Facebook are worth hundreds of billions of dollars exactly because there is not one non-programmer with a say in them.
I think you confuse the founder/owner status with the work role. I would rephraze this - you can never make good money as a salaried employee (google with it's early-stock-millionaires is an exception).
The second question is, how can a company be succesfull? I know several very succesfull software businesses which were not directed by software engineers. The question about competence to run a company is far more complex than saying if domaim specialists won't run the show it will tank.
I did not say that I believe this because it would be true. Of course, I only believe this because I want to believe this. You see, I am a programmer. So, my belief is that programmers are superior and non-programmers are inferior. So, everything I claim will always further that view. Therefore, my every political move is always aimed at confiscating any possible say or decision power from non-programmers and to eject them out of the game. Seriously, when push comes to shove, I only listen to other programmers. Isn't that obvious?
1. Labor does not receive (or insist on) percent-of-value or percent-of-transaction compensation. This is in contrast to some other professional disciplines (e.g., salespeople often get paid on a percentage or commission, bankers often take a % cut, pe / vc / hf has 2% and 20%, real estate is on a %, lawyers may get paid on a % ("contingent fees"), etc.)
2. Initial salaries are good, but there is wage stagnation. Just-out-of-college salaries for programming are often better than virtually everything else (notably, banking and consulting); but after ten years, the opposite is relationship is reversed (considerably so). The difference between a newgrad salary and a 10-yearer salary for tech-industry programmers is often (in my anecdotal experience) less than 2x. In contrast, 5x or more is not unusual in other fields.