8 ms·

> What makes me nervous, though, is that we don't really understand why programmers are paid this well I understand why developers are paid this well. The marg

> What makes me nervous, though, is that we don't really understand why programmers are paid this well 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-zero-7fda166f219f https://ckluis.com/the-marginal-cost-of-software-approaches-...

eagsalazar2 4y ago
I can probably afford to pay 200% of what I currently pay to go out to dinner, but I don't because there is sufficient supply and competition. The lack of supply is why you are paid more, not because startups are rich.
- lotsofpulp 4y ago
  It is both. A buyer needs to have the funds to be able to pay.
- shrimpx 4y ago
  > The lack of supply is why you are paid more, not because startups are rich. It's both. If software companies were poorer across the board, without changing the supply/demand ratio, salaries would be lower.
  - randomdata 4y ago
    If the supply/demand ratio stayed the same, salaries couldn’t go lower. But you are right that if software companies were poorer that there would be a necessary reduction in demand.
    - shrimpx 4y ago
      I’m not totally convinced. It seems that sometimes when profits fall across an entire industry, the best thing to do is to operate at the tighter margin instead of firing workers to maintain the previous margin. I concede that might be rare, but the restaurant industry comes to mind. If rice gets more expensive, you could fire workers, pass the increase to the customer, or eat the cost. Often the best choice is to concede and eat the cost and say goodbye to the “cheap rice bubble”.
      - randomdata 4y ago
        I expect a lot of software companies don't make any money, only living on investment dollars in some hope of making money someday, so margins may not matter much. 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.
        imtringued 4y ago
        Silicon Valley can only exist because a software business can be located anywhere but investors and workers must utilize agglomeration. What this means is that software companies are closer to the money than other businesses.
        randomdata 4y ago
        Investment and workers can be located anywhere. Even Silicon Valley companies list themselves on New York stock exchanges to access capital from around the entire country and the globe. 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.
stephc_int13 4y ago
>We don't pay people based on how hard they work. 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 to do that.
- godelski 4y ago
  > Something being difficult to achieve does not make it valuable. 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.
  - threatofrain 4y ago
    There’s a difference between valuable to the market and valuable for society. For all we know ecological research will become an existential issue but that doesn’t mean consumers or businesses give a damn. Meanwhile advertising is worth trillions.
    - nopenopenopeno 4y ago
      Be careful. You’re approaching communist thought crime. https://en.m.wikipedia.org/wiki/Use_value https://en.m.wikipedia.org/wiki/Use_value
      - Viliam1234 4y ago
cortesoft 4y ago
I mostly agree with you (and made a similar comment), but there is something more going on I think... since developers are so valuable, shouldn't more and more people become developers until the cost for paying a developer goes way down? 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.
- Der_Einzige 4y ago
  A lot of potential developers opt out of CS for social reasons. Large swaths of women won't want to do a 4 year major with a 5-9 to 1 ratio of men to women, especially when the men skew so unkempt. This is just one example. 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.
  - borski 4y ago
    This is a pretty cynical view of things, and definitely isn’t nearly as true anymore. Software engineers, depending on where in the country you are, are often extremely well respected now.
  - ativzzz 4y ago
    Luckily tech is one of the few fields where having the corresponding degree is not necessary and you can make a good life for yourself without following a traditional path to upper middle class (like law, medicine, finance etc) > 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
IshKebab 4y ago
I think that is definitely true, but it doesn't explain the wild geographic variation in pay. Why are SV programmers paid maybe 5-10x what programmers in Europe are. They definitely aren't 5-10x better and the cost of living isn't 5-10x as much. 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.
deleted 4y ago
[deleted]
analog31 4y ago
>>>> The marginal cost of software is (close enough to) zero 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.
- ativzzz 4y ago
  The way I look at is that each piece of software, lets call it a feature, has a non-zero operating cost associated with it. Maybe that's a team of engineers that build and maintain it, a team of marketers/salespeople who get it out to customers, a team of designers/product managers who decide what should get built and how, and a team of customer support that then supports this feature. AWS bills, etc 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.
cgh 4y ago
While I agree with this in principle, it should be mentioned that a great deal of software, perhaps even the majority of software written depending on who you ask, is used internally and is never sold directly. In fact, there are accounting rules in the US that deal directly with internal use software that classifies it as a long-term tangible asset[0] (software is normally classified as an intangible asset). 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. [0]: http://files.fasab.gov/pdffiles/handbook_sffas_10.pdf http://files.fasab.gov/pdffiles/handbook_sffas_10.pdf
jrm4 4y ago
Add to that something like "the fog of development," namely that, in the beginning, software can be sold as "magic" but one can expect that this is likely to have a strong tendency to drop off as open source etc. alternatives become more widely known, especially by "regular" users.
lokar 4y ago
I agree. Also, observe that companies that employ programmers for internal use (not part of the product) don’t pay nearly as much.
jtsiskin 4y ago
Everything digital has marginal costs near 0. Books, TV, movies, art, newspapers, photos, etc. (obviously, talking about the digital version of all these). Yet a lot of these fields are known for low pay.
- rodw 4y ago
  I don't think this fully explains the phenomenon, but I do think there are a couple of factors you're overlooking here: 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.
rodw 4y ago
Not only is the work extraordinarily financially valuable in many cases, software is actually pretty hard to do _well_. It's based on highly specialized knowledge and experience. It requires sustained, high levels of discipline and effort. And it is often tedious and/or frustrating work in practice. 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 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.
snapplebobapple 4y ago
This isn't really true in the sense you think it is because the corollary of the marginal cost of software being close to zero is that someone only needs to code a quality opensource competitor once to materially impair the value of some software. 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.

eagsalazar2 4y ago

I can probably afford to pay 200% of what I currently pay to go out to dinner, but I don't because there is sufficient supply and competition. The lack of supply is why you are paid more, not because startups are rich.

lotsofpulp 4y ago
It is both. A buyer needs to have the funds to be able to pay.
shrimpx 4y ago
> The lack of supply is why you are paid more, not because startups are rich. It's both. If software companies were poorer across the board, without changing the supply/demand ratio, salaries would be lower.
- randomdata 4y ago
  If the supply/demand ratio stayed the same, salaries couldn’t go lower. But you are right that if software companies were poorer that there would be a necessary reduction in demand.
  - shrimpx 4y ago
    I’m not totally convinced. It seems that sometimes when profits fall across an entire industry, the best thing to do is to operate at the tighter margin instead of firing workers to maintain the previous margin. I concede that might be rare, but the restaurant industry comes to mind. If rice gets more expensive, you could fire workers, pass the increase to the customer, or eat the cost. Often the best choice is to concede and eat the cost and say goodbye to the “cheap rice bubble”.
    - randomdata 4y ago
      I expect a lot of software companies don't make any money, only living on investment dollars in some hope of making money someday, so margins may not matter much. 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.
      - imtringued 4y ago
        Silicon Valley can only exist because a software business can be located anywhere but investors and workers must utilize agglomeration. What this means is that software companies are closer to the money than other businesses.
        randomdata 4y ago
        Investment and workers can be located anywhere. Even Silicon Valley companies list themselves on New York stock exchanges to access capital from around the entire country and the globe. 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.

stephc_int13 4y ago

>We don't pay people based on how hard they work. 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 to do that.

godelski 4y ago
> Something being difficult to achieve does not make it valuable. 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.
- threatofrain 4y ago
  There’s a difference between valuable to the market and valuable for society. For all we know ecological research will become an existential issue but that doesn’t mean consumers or businesses give a damn. Meanwhile advertising is worth trillions.
  - nopenopenopeno 4y ago
    Be careful. You’re approaching communist thought crime. https://en.m.wikipedia.org/wiki/Use_value https://en.m.wikipedia.org/wiki/Use_value
    - Viliam1234 4y ago

cortesoft 4y ago

I mostly agree with you (and made a similar comment), but there is something more going on I think... since developers are so valuable, shouldn't more and more people become developers until the cost for paying a developer goes way down? 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.

Der_Einzige 4y ago
A lot of potential developers opt out of CS for social reasons. Large swaths of women won't want to do a 4 year major with a 5-9 to 1 ratio of men to women, especially when the men skew so unkempt. This is just one example. 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.
- borski 4y ago
  This is a pretty cynical view of things, and definitely isn’t nearly as true anymore. Software engineers, depending on where in the country you are, are often extremely well respected now.
- ativzzz 4y ago
  Luckily tech is one of the few fields where having the corresponding degree is not necessary and you can make a good life for yourself without following a traditional path to upper middle class (like law, medicine, finance etc) > 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

IshKebab 4y ago

I think that is definitely true, but it doesn't explain the wild geographic variation in pay. Why are SV programmers paid maybe 5-10x what programmers in Europe are. They definitely aren't 5-10x better and the cost of living isn't 5-10x as much. 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.

deleted 4y ago

[deleted]

analog31 4y ago

>>>> The marginal cost of software is (close enough to) zero 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.

ativzzz 4y ago
The way I look at is that each piece of software, lets call it a feature, has a non-zero operating cost associated with it. Maybe that's a team of engineers that build and maintain it, a team of marketers/salespeople who get it out to customers, a team of designers/product managers who decide what should get built and how, and a team of customer support that then supports this feature. AWS bills, etc 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.

cgh 4y ago

While I agree with this in principle, it should be mentioned that a great deal of software, perhaps even the majority of software written depending on who you ask, is used internally and is never sold directly. In fact, there are accounting rules in the US that deal directly with internal use software that classifies it as a long-term tangible asset[0] (software is normally classified as an intangible asset). 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. [0]: http://files.fasab.gov/pdffiles/handbook_sffas_10.pdf http://files.fasab.gov/pdffiles/handbook_sffas_10.pdf

jrm4 4y ago

Add to that something like "the fog of development," namely that, in the beginning, software can be sold as "magic" but one can expect that this is likely to have a strong tendency to drop off as open source etc. alternatives become more widely known, especially by "regular" users.

lokar 4y ago

I agree. Also, observe that companies that employ programmers for internal use (not part of the product) don’t pay nearly as much.

jtsiskin 4y ago

Everything digital has marginal costs near 0. Books, TV, movies, art, newspapers, photos, etc. (obviously, talking about the digital version of all these). Yet a lot of these fields are known for low pay.

rodw 4y ago
I don't think this fully explains the phenomenon, but I do think there are a couple of factors you're overlooking here: 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.

rodw 4y ago

Not only is the work extraordinarily financially valuable in many cases, software is actually pretty hard to do _well_. It's based on highly specialized knowledge and experience. It requires sustained, high levels of discipline and effort. And it is often tedious and/or frustrating work in practice. 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 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.

snapplebobapple 4y ago

This isn't really true in the sense you think it is because the corollary of the marginal cost of software being close to zero is that someone only needs to code a quality opensource competitor once to materially impair the value of some software. 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.