This.
Something being difficult to achieve does not make it valuable.
In practice, this is often the opposite. The most difficult jobs are also the less productive/less well paid.
The ability to write code is the closest thing we ever had to magic. There are many levels of mastery, but it is undeniably powerful.
The strange thing is that not everyone seems to enjoy acquiring the skills needed for programming.
And value to what? As an ex-physicist I can confidently say that doing that was substantially harder than the ML I do now. But I also think that what I did provided more value to society as a whole. Just my opinion though. But it doesn't pay well (<$100k/yr) and I'm not surprised I saw a mass exodus of people trying to get more money with their math skills (mostly in DS and CS). If pay was correlated strongly to difficulty mathematicians and physicists would be paid much more than Hollywood actors. But for some reason these conversations always revolve around the (barely a) millionaire class and never include the billionaire class. It feels surreal in that it looks like we're fighting for crumbs and arguing who deserves it more.
That is the only way I know to put a price on something, and this is clearly not a reliable process (see all the scams) but is there anything better?
The problem with market value is that it downplays the needs of the poor, and is sensitive to all kinds of regulation (intuitively, if regulation makes the same thing more expensive, it doesn't make it more valuable).
The problem with use value, as defined by Marx, is that it ignores the differences between individuals, and technically the needs of individuals at all. It simply means "what the one who controls the society considers valuable". (If you think this is a strawman, just read the Wikipedia article carefully.) Of course, it is assumed that the one who controls the society is omniscient and can determine the value correctly, but that's just answering the question by passing the buck to a hypothetical omniscient entity. (And if you look at actual communist societies, it turns out, perhaps surprisingly to many, that the ones who control them are neither omniscient nor benevolent.)
What seems to work best, so far, is a hybrid system where:
* the value of million little things (often not useful per se, but as a raw material for something else) is determined by the market;
* some form of social security ensures that anyone's needs have a non-zero weight;
* the "socially useful but not market profitable" projects are paid for by taxes and charities.
In other words, the "use value" can be implemented on top of "market value" by financing things by taxes and charities. In the opposite direction, the "market value" can also be implemented on top of "use value" by trading the government-assigned things on black market; the only problem is that this is typically considered illegal. The fact that both things occur naturally in different kinds of societies suggests that both are necessary. (And the proposal of "free market with unconditional basic income" is how they could exist side by side without having to implement one of them as a hack on top of the other. The last component you need is some kind of Kickstarter.)
There certainly is a shortage, or salaries would be lower. Anecdotally, at least 90% of the people I talk to say something along the lines of “ooh I could never do that” when they learn what I do for a living. Most people seem scared of coding, and I’m not entirely sure why.
Sounds backwards. A shortage is a situation where price is unable to rise. If there is a shortage, salaries should be higher than they are.
Price gouging laws are a good example of where shortages can occur. We experienced a shortage of toilet paper at the beginning of the pandemic because the law (in many jurisdictions) prevented vendors from charging the fair market value. If vendors were legally able to sell them for $1,000 a roll, the market would have been easily satisfied as the average person unable to pay $1,000 a roll would have bowed out of the market, leaving just the right amount for those who still were willing to pay up. Instead, because of the law toilet paper remained as affordable as it ever was, so it became a race to see who could get it first instead of letting a higher price scare some people away.
Within the scope of labor, healthcare can be prone to shortages as governments have been known to impose price ceilings on practitioners to try and make healthcare more accessible to all, so that the rich don't buy up all the doctors' time with a better offer, leaving no service available to the poor. This is quite uncommon generally, though, and not something I've ever seen within the software industry. We're quite happy to let Google outbid Mom and Pop's Used Book Emporium for developers.
It's very time consuming, requires you to think in logic and the work is relatively solitary. It's a nightmare job for a lot of people.
It's both. If software companies were poorer across the board, without changing the supply/demand ratio, salaries would be lower.
But if the companies were to be become sufficiently poorer, the amount they are able to pay has to come down at some point, and once that happens you've got a reduction in demand. That doesn't necessarily mean firing anyone, demand simply measures desire and ability to pay a given price to attain what is wanted.
What this means is that software companies are closer to the money than other businesses.
What's unique about Silicon Valley is the density of software-minded people willing to adopt products made by their friends. It sets up a "if you build it, they will come" situation. That promotes the early adoption needed to grow into something larger. If you were located in Iowa and your friend group was made up of farmers, they likely won't care about the software you are building, and you'll stall out quickly in trying to find users.
On the flip side, if you are building something that would be of interest to Iowan farmers, you will have a greater chance of success having that farmer friend group than a bunch of Silicon Valley tech bros to share with.
Like you said, we don't pay people based on how hard they work. However, we also don't pay people based on how much value they create... we pay people the lowest amount we can that is enough to keep them from going to another job. The value they create just sets a ceiling on the wages (you can't pay someone more than the value they create or you will soon go out of business)
So there are two possibilities as I see it... either there are simply so many possible business opportunities that the number of developer jobs is practically infinite (new jobs are created as soon as a new developer is ready), or there is something that limits the number of new developers.
I think it is a bit of both. I think there are fewer people who have the capability to be developers than we like to admit, and there are a lot more possible jobs than we have currently.
So why aren't there more people for these highly compensated jobs?
I remember seeing someone say 'Running is free, but not everyone can be Usain Bolt'.
A bit elitist to be sure, but being a good developer requires a certain type of thinking that simply isn't common in the general population.
Access to quality, free information isn’t enough, sadly. The average person the world over isn’t in a position to make the jump due to economic factors over intellectual limits.
Mostly correct, with one objection: time is also a necessary resource to become a software developer. Some people who may have the talent do not get the opportunity to learn simply by having to keep a full-time job (or two) since they were 18 (and getting a shitty education before that). Most of us have enough free time to learn things (otherwise we would not have enough time to discuss on HN), but it is not universally true.
That said, although giving everyone a realistic opportunity to become a software developer would be fair to the unlucky individuals, I do not assume that it would change the balance in general.
First off, what a terrible system. Why would we want to support that. Second off, this clearly isn't happening when you look at those taking in 8+ figures.
Until then, it will be like democracy. The worst system, except for all the others.
There's a continuous spectrum of things you can do, not discrete, and definitely not binary. So my suggestion is, and I'm far from being alone, is reign in the plutocrats. No one cares about them while the average person's life is getting better, but boy do we care when that stops happening. Especially when we see their lives continue to get better while the quality of our lives decrease.
>Government regulation matters because we want high competition. There's ways to have supply and demand price determinations without them being wildly out of control and without plutocrats.
is mutually exclusive to
>we pay people the lowest amount we can that is enough to keep them from going to another job.
This system is the same as shopping at a store that sells you the same goods at a lower price than another store. I do not see what this has to do with a “plutocrat”. Buyers have been buying goods and services at the lowest prices they can find for at least thousands of years.
Governments often set floors for wages. In fact, this is called the minimum wage.
> This system is the same as shopping at a store that sells you the same goods at a lower price than another store.
That's how it works in a perfect world, but not how it works in reality. In a perfect world monopolies wouldn't be an issue. The reason they are an issue is that with a monopoly it is very easy to manipulate the market that you control. The reason we generally break up monopolies is because they are actively manipulating said market and stiffing innovation. We tend to not go after monopolies that aren't doing this.
> I do not see what this has to do with a “plutocrat”.
A plutocrat is someone who's power is derived from wealth. A plutocracy is a form of government where that power, derived from wealth, is instrumental to political power. You may think that this is universal to all governmental systems, but it isn't. Often we see the reverse (wealth derived from political power vs political power derived from wealth).
Anti-trust laws, IP laws, the SEC, etc are all designed to prevent this from happening. I think the problem you're running into is that you're taking perfect models (spherical cow in a vacuum) and assuming that they work identically in the real world. This is naive just as it is naive to assume a spherical cow in a vacuum falls out of a plane at the same rate as a living cow. There's an approximation and you can get some useful planning from the simple model, but it is going to have significant errors in the real world experiment.
What it comes down to is a lack of sufficient complexity and nuance in the model you're using. An econ 101 course or even a B.A. in economics will not be enough to sufficiently understand the economy in high detail. It is really easy to overestimate the utility of our knowledge and mental models because we tend to not measure likelihood of events based on random samples but instead have a large selection bias (getting random samples is also quite difficult).
>we pay people the lowest amount we can that is enough to keep them from going to another job.
Minimum wages, labor laws, safety standards, anti trust laws, and all of that can exist, but I am still going to expect buyers to pay the least a seller is willing to accept. And conversely, a seller is going to demand the most a buyer is willing to pay.
What you're not getting is that this is theory, but not the world in practice.
Start using supply and demand to determine the price of money. Supply and demand elsewhere is a sham if you set ceilings and floors on the interest rate.
In CS, you trade social skills and social value to escape the worst of capital exploitation. Go to a bar, tell someone you make 300K, and watch their face the moment you mention to tech worker part.
Where and how you got your money matters. People don't respect us computer touchers.
> go to a bar, tell someone you make 300K
you must be having way different bar conversations than I've ever had - maybe they just don't like you as a person lol
Those darned smelly CS grads with their non-matching clothes, if not for them more women would be in CS!
for example you've got lots of people who would fall under the umbrella of software development that mostly just do web design and WordPress, they're about the least engineer-type people you can have.
You're describing many of those who are what we would call "non-normative", if you will. aspergers, autism, and the like. Yes, it's statistically understood those who choose this career are more likely to fall into that category.
So what's really being said here is that women are being chased out of well paying STEM field because they're too judgemental to deal with those who are non-normative.
Is that really the fault of men, or maybe we should blame these self-same non-normative folks?
----
Can you imagine if someone were to claim the reason so many men choose not to go into nursing is because of the smell that happens roughly once/month?
Think about why one is acceptable and the other is not.
IME doing this, many are happy with no regrets, but all have truly horrific stories to tell.
Unless the situation is different for women in law, or women in medicine, it still does not explain the lack of women in CS.
Sometimes I think the same. Like I can get $2k per month sitting in the office meanwhile road worker will wake up at 3AM, work 12 hours in rain and winter, trading his health for $300 per month.
Anyway I avoid mentioning my profession unless asked directly. It's not a question of respect, but rather question of envy which i don't like to be target of.
When I had TV appearances they were calling me "Pulli Traeger" (wearing casual outfit). In publicity you are respected how you look, not what you can. Experts are frequently looked down, as they rarely can express themselves to a TV audience. On smaller private TV it was fine though.
Also upper management in Europe used to disrespect us as overpaid "coders" or code monkeys.
There is a natural ceiling of the number of SWEs due to aptitude for programming. Some people simply don't have the grit, tenacity, persistence, or even intelligence for being able to learn to program, much less do it in a professional environment.
I've taught many people and of those, perhaps 80% just can't handle it. They see the money, start trying to learn programming, and they give up after a few lessons because they couldn't understand for-loops for example, or they just get bored and conclude it's not worth the effort. I've seen this firsthand.
I definitely think we'll see movement of work outside SV and outside the US to save costs. Musk could have made Twitter profitable simply by moving all engineering work outside the US.
Of course, because effort is only one variable in the formula. Money generally is a trade for the (value * time) someone returns to us. Valuation being affected by effort, risk factors, demand, etc. But fundamentally if a piece of software can return 5 minutes to 100k people/week, whoever designed that software has universally redeemed 18k+ days (50 years) of time to a population of people each year.
Software ultimately juices the time portion of the formula. A SW developer may not have put in the same yearly "effort" as a parent, but that's just not how the money<->time exchange works.
I call this "the magic of software." The reason is that it triggers magical thinking on the part of managers. But I think the magic can be fleeting, depending on the business use for the software, for instance:
* Software that's used internally within a business has a ceiling on volume.
* Platform obsolescence sets a ceiling on the volume that can be sold before a product has to be maintained or re-written.
* A bigger user base is more diverse, thus involving more "difficult" users, exposing more bugs, and discovering hidden features that become future maintenance requirements according to Hyrum's Law.
* A software product that's attached to hardware sales rides on the sales volume of the hardware.
* Higher volume attracts competitors, who force you to add features.
If any business could get rich cranking out copies of software, they wouldn't be prioritizing every other possible revenue model such as data harvesting, advertising, subscriptions, and so forth.
I think with good management, this feature can be sold with a close enough marginal cost of zero. There are costs, yes, you can't just sell it to 500 users without support, but over time as the feature matures, there should be less support and less engineering power required to power that feature. You should be working towards being able to sell this feature without incurring (much) additional cost per unit sold
Now in reality, we rarely sell individual features, and with every additional feature we add the overall complexity of the product increases and so development and support gets more expensive.
So along with "selling it infinitely", you can also think of it in terms of using it "infinitely" even though it's considered a tangible asset. It's kind of weird when you think about it, like a piece of equipment that in theory never wears out. Obviously in real life that's not entirely true due to changing business rules and so forth.
1. Control over the "distribution channel" is a major factor at least part of the time. The fields which are most notorious for low pay (e.g., books, music, photography) are the ones where the producers of the content are disconnected from the customers and instead sell via distributor. At least some of these middlemen are reaping the rewards of the low marginal cost (e.g. Spotify?), but I'm not sure if it applies to all of them (e.g., book publishers?). More to the point, software developers tend to have more direct control over the distribution channel (notably SaaS) and when they don't the distributor tends to takes a hefty chunk of the revenue (e.g. mobile app stores today, big-box retailers 20-30 years ago).
2. The "make it once, sell it infinitely" model doesn't really apply to newspapers (and maybe some of the other categories) in quite the same way. Yes, the marginal cost per view is essentially 0, so I can "sell" today's paper an infinite number of times. But the value of and interest in that content rapidly depreciates to 0 as soon as it becomes yesterday's news. The newspaper model isn't "write once, sell forever". You need to continue to "feed the beast". It's the ongoing production cost to continuously generate new content that dominates.
3. There may also be a correlation with "content" versus "services". Whether due to distribution mechanics or popular perception, it seems like application providers (e.g., Adobe, Microsoft) are able to enforce a pay-as-you-go subscription model but "pure" content providers are often trapped in a (lower-margin) advertising model because "information wants to be free" (or more to the point, is easily plagiarized by competitors or pirated by consumers). Digital or not, most of the "low pay" examples you cite fall into the content rather than service category.
It's a corollary to the Dunning-Kruger effect: don't assume programming is easy for _everyone_ just because you happen to be good at it.
I think "Chapter 1: The Tar Pit" of the venerable _Mythical Man Month_ (https://archive.org/details/MythicalManMonth) speaks to this in terms that are still applicable even after half a century. Here are some of the challenges Brooks describes:
1. "Most have emerged with running systems — few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty — any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem"
2. "One must perform perfectly. [...] If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it."
3. "Other people set one's objectives, provide one's resources, and furnish one's information. One rarely controls the circumstances of his work, or even its goal. In management terms, one's authority is not sufficient for his responsibility."
4. "The dependence upon others has a particular case that is especially painful [...] He depends upon other people's programs. These are often maldesigned, poorly implemented, incompletely delivered, and poorly documented. So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable."
5. "[D]esigning grand concepts is fun; finding nitty little bugs is just work. With any creative activity comes dreary hours of tedious, painstaking labor [...] [D]ebugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end. So testing drags on and on, the last difficult bugs taking more time to find than the first."
6. "The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. Already colleagues and competitors are in hot pursuit of new and better ideas. Already the displacement of one's thought-child is not only conceived, but scheduled."
I think it's notable that even with five decades of global-scale investment in this field we haven't really _fixed_ any of these challenges. Our tools and practices have improved, certainly, but at best in proportion to the increasing demands of scope/scale/complexity. Context-aware, cloud-connected, toolchain-integrated IDEs with features like programmatic refactoring, REPL-like interactivity (or whatever other modern tooling you'd like to point to) are a giant step up in both usability and productivity compared to the batch processing of literal punch cards workflow that Brooks based his observations on. But I suspect those "woes" still resonate with most people involved with software development today. Projects still regularly fail to hit scope, schedule or budget. Small, obscure errors still sometimes lead to catastrophic failures. Reliability continues to be expensive to and is often fleeting.
The global system of systems that comprise the modern "technology infrastructure" is an ever-expanding, ever-shifting, frequently-unreliable and increasingly-critical house of cards. It's almost certainly the most sophisticated and complex artifact that humanity has ever produced. It's easy for those of us with significant interest, aptitude or experience with it to forget that. But this shit is _hard_. It's a wonder that it works at all.
Toward that end, while you can wave your hands around "how [little] work it takes to become [a programmer]", the fact is it takes a substantial amount of time and effort (and an moderately uncommon degree of aptitude) to become a competent one.
Are some software engineers over-compensated? Probably. But the difference between software engineering and medicine (for example) has less to do with the degree of specialized knowledge or level-of-effort required and more to do with credentialing and our ability to evaluate competence. You can take a 6-week "coding bootcamp" and call yourself a "programmer". You can't take a 6-week first-aid course and call yourself a "doctor". But they are both pretty far removed (in terms of experience and learning) from even a competent "journeyman" in their respective fields (say, a "principal engineer" and "resident", respectively - i.e., someone you could trust to take on a non-trivial level of critical responsibility with relatively little oversight).
To be fair the stakes are generally higher for a typical doctor than for even the most "senior" software engineers, but there's plenty of literally life-or-death software applications, both direct (e.g., medical diagnostics, 911 calling infrastructure, GPS, computer vision) and indirect (even something as mundane as network availability or the reliability of data search and retrieval). Not to mention the enormous number of systems for which failures in delivery or at run-time can have a substantial financial impact. I can't really speak to relative compensation: I imagine many doctors should probably be paid more and many programmers could probably be paid less (and the med-school/residency pipeline should almost certainly have a more sustainable work/life balance). But it's foolish to think that the upper-ish tier of software engineers (say, 40th+ percentile maybe?) doesn't represent a skilled, specialized, and therefore valuable labor force.
It's no surprise that there's a large number of highly compensated software engineers. There's a lot of extraordinarily valuable (from a financial perspective) work to be done and it takes substantial knowledge, experience, and aptitude to be able to do it well.
What is really driving how well programmers are getting paid is several companies (google, meta, microsoft, apple, et al) managed to get big enough (probably temporarily) to gain vastly outsized profits from the mechanism you outlined above and they all had a policy of drastically overpaying for talent in order to keep said talent from going to a startup that creates the next idea that destroys their outsized profit machine. This was supercharged by way too low interest rates driving private equity valuations on companies that have no hope of actually achieving profits commensurate with their valuations also desperately overpaying for talent in the hopes that they can create the next big thing fast enough to catch up to their valuations. They weren't that worried about their burn rates because the low interest rates made it easy to raise more at very favorable terms at a higher valuation so everyone was happy.
The latter trend is coming to a hard stop right now with higher interest rates (likely higher and for longer than most people think) and the former is also starting to change, so expect broad material weakness in programming salaries going forward.
I understand why developers are paid this well. The marginal cost of software is (close enough to) zero [0]. This means that once you make software once, you can sell it infinitely (minus some scaling costs, hence being close enough.
We don't pay people based on how hard they work. If we did, stay at home parents would be filthy rich.
Sure the very very top end pay will fluctuate depending on stock market conditions since those include a significant portion of equity, but the reality is programmers deliver expensive products that businesses can sell easily that pretty much everyone wants. Trends will come and go, but making high quality tech products will continue to be profitable in my lifetime (barring WW3) and thus programmer salaries will stay high.
[0] https://ckluis.com/the-marginal-cost-of-software-approaches-...