Some other people say it's actually a sucker shortage, meaning that employers do not compete on salary.
Then Triplebyte wrote (1): "Engineers are almost completely unique as a labor force. There is far more demand for engineers than there is supply, and that makes engineers powerful in a way other professions are not."
A handful of software engineers produce software used by millions, and therefore generate an immense amount of value.
Open source contributors give away a lot of value, since if everyone had to re-create their work (including its dependencies, its dependencies' dependencies, and so on), there would be 1,000,000 times the demand for software engineers than there is today and innovation progress would be much much slower.
Do software engineers really have leverage?
How could we increase our leverage?
Why don't we choose to use our rare skills for our own profit (as everyone else does), and instead many of us give away immense value (and power/leverage) by open sourcing our work?
This is a misconception. Imagine everyone had to write everything in FORTRAN. Would there be more or less work for SWEs? There would be less because each one would be far less productive and the value you could get out of hiring one would be small.
You’d never hire someone unless you can make more money off of their employment than you have to pay them. SWEs get paid a lot because they are able to generate a lot of marginal value. Without the tools that make us productive, we don’t have that value.
Each time we win by having better tools, but we lose by dropping all the optimization already done. And things like lisp or ada show there were better tools than the industry average available in the past, except their ecosystems didn't grow enough and/or died.
Then if enough developers use the new “better for task X,Y,Z” thing then there is incentive/resource to gradually grow the stdlib capabilities to cover all the old use cases. And in doing so, often some of the initial expressiveness/focus is lost, so there’s now a bit more room for a new focused competitor to come in and repeat the process.
Some find this exhausting, or think that it represents “fad chasing” without creating any new value, but I think it’s just what progress/evolution looks like in a community-based system of knowledge like software languages.
To your point about lisp or ada being better - using an evolutionary metaphor, it’s possible for fitter genotypes to lose to less-fit ones through random chance. But in these cases it’s hard to tell whether it’s not actually the case that these languages, while better for some users/use-cases, are actually lacking something that makes them suitable for broader usage. (For example - if a paradigm was incredibly productive, but requires you to have a maths PhD, then you’d expect to see some users claiming the tools are better, at the same time as those tools failing to get broader adoption. I’m not making a specific claim here about lisp, just painting some possible fact patterns that could explain the phenomenon.)
What would happen is that all different companies would end up implementing the same functionalities over and over again. I know companies that don't rely on OSS for security reasons and that's exactly what happens.
Maybe some companies would step up together and publish a shared
There would be a tiny bit more of demands compared to nowadays, SWEs would find it harder to move companies - but I don't think SWEs productivity wouldn't be affected, once they finish onboarding and learning whatever the standard library in a specific company works like.
Deleted Comment
This combined with relative lack of government regulations.
I'd hate to see the day when you'll have to complete 3 separate training programs/licenses just to be allowed to deploy code on the Web.
A skilled engineer starting out in their career will begin with zero leverage, but ideally will possess the means to increase it substantially over time.
Software engineers on average have tons of leverage, but the distribution underneath that probably looks like a bathtub. On one end you have a pit of despair, confusion and failed business, and on the other you have the likes of Linux kernel maintainers, Microsoft Distinguished Engineers, et. al. Remember, this is the leverage distribution, not perceived skill/experience distribution - I have never really seen someone with a "medium" amount of leverage in the business. You are either the manager or the managed.
If you want to quickly move from one side to the other, the best way I have observed is to relentlessly chase the end business value and make it clear that you can deliver something that people with $$$ or power care about. Whether this means actual customers that pay you, or your open source community, it doesn't really matter. Everyone knows the skills transfer almost universally between styles of project.
Spending a majority of your time chasing shiny technology just for the sake of cool new things is how you stay on the drain-side of the software engineering leverage bathtub curve.
I think having a "medium" amount of leverage is just not usually explicitly signaled. But it's definitely there.
An engineer can know they aren't at any risk of being fired barring a huge screwup, and use that leverage to coast (and if they're remote, that means working fewer hours -> getting paid a higher effective wage.)
This is true, but it's important to recognize the huge industry shift that has happened in recent years. There used to be a lot of starting leverage. For folks who remember the early 00s and late 90s, it used to be that just by being a kid who knew stuff about computers, it was assumed by the general public that you were super qualified and possibly more qualified than most people already in the field. You could literally be the "hacker kid" from your high school, and walk into a high-paying software engineering job with a 401k, or become a company's first technical hire. Then as software engineering became more formalized and in-touch with industry on the academic side, people with a CS degree started getting the best entry level positions in the mid 00s. Now things are shifting again, as frontend and backend frameworks have increased exponentially in complexity, recent CS grads often no longer have the domain knowledge to jump into the field without prior experience, so we're seeing a shift towards bootcamp grads, who have some actual practical experience in developing software.
The value prop of getting a CS degree is rapidly diminishing at least in a short-term, start-of-career sense, and I say this as someone with undergrad and grad degrees in CS. At the same time, if you manage to get a CS degree _and_ be a major open source contributor or graduate from a bootcamp, you'll beat out most of the competition, and this will also be a benefit later in your career when you are vying for CTO positions.
Is this true? I have nothing against bootcamp grads and have known a few great ones, but anecdotally people who graduated from CS degrees are much better at adopting to software engineering roles than bootcamp grads.
And I think the reason is the fundamentals. People with CS degree know about concepts like contention, memory models and the difference between pass by reference and value. These things take a while to grasp for someone that just went through the firehose that is the bootcamp.
Talk to business people about their business and you'll be talking their language. The technology is just a tool. Your job is to use the right tech to keep costs down, while keeping agility and reliability up. Do this and you'll have more leverage compared to the competition.
You have to port it to some other framework, and usually I ended up wanting to clean up a few things in the process (or in Kindle's case, I needed to, because it had so many constraints), or have to add new features for new expectations (480P->720P->1080P->1440P resolution, 2D->3D, add online multiplayer, streaming features, maybe the market shifted to expecting mobile apps to be free so now you need to rework the design, etc).
When you're working on it in your spare time, sometimes those things happen before you get a chance to finish the project and get it out there.
Do you actually think so? I'm actually feeling that compared to other professions domain knowledge and specialization is less valued and searched for, since more companies look for generalists and operate on higher levels of the stack.
My personal experience is I get 99% of linkedin messages for generic "React" or "Java" jobs, where leverage would certainly be low. That is despite having a huge amount of expertise in fundamental technologies that these companies are using (and sometimes even having written the code for those). But those are not the immediate problem for the recruiter and manager, so they usually don't care.
This is apparent in the UK, where there is a two-tier market (IMHO). Those that are good at what they do and recognise their value, go semi-independent and sell to the highest bidder on a day rate.
Then there is the perm market, which pays very few people all that well, and is a constant source of complaints - "we can't fill our vacancy for X niche skill at £30k per year!". Well no, you can't, because that niche skill commands four times that, and you're thinking about software engineers as if they were office juniors, not highly skilled professionals. At this end, it is a sucker shortage.
They'll fill that role, eventually, and they'll get someone with low productivity that produces unreliable software, and they'll feel justified in their vicious low-pay, low-expectations cycle.
If you are a engineer on say 70k and see a senior role at another company for 90k and expect, once promoted at your current company, to see your salary go up, you might be surprised. Some companies just take the lowest band price if the market, 77k for example and will claim that is market rate.
I have seen this many times and if the employee leaves, the company will spend months and thousands plus 10% first year salary to get a replacement and will most likely end up paying more than the original employee was on. I find this kind of process so frustrating as a hiring manager, the amount of time and effort required to go through candidates and interviews just to replace people you shouldn't be losing.
Of course there are minefields to negotiate (IR35, administrative overheads of running a company etc) but it's a completely different world to working as a permie.
> They'll fill that role, eventually, and they'll get someone with low productivity that produces unreliable software, and they'll feel justified in their vicious low-pay, low-expectations cycle.
In my experience they then come crying to contractors to try and fix the mess made by the low-paid staff. The whole debacle costs more than it would have cost doing it right to start off with.
Recruiters will rarely find you well paying contracting gigs but they can find you some good employee contracts.
Contracting is more tax efficient with some planning and an investment strategy (for now, tax hikes and new ir35 are incoming).
Last time I hired I couldn't find a junior with more than zero coding skills for less than 30k, so not sure what are you talking about. I assume there must be a market for cheap developers who can't code - probably all those guys that try to squeeze in during interviews without knowing how to code.
I've also seen a bunch of seniors being underpaid on salaries that haven't been updated for literally 15 years - but if you're not job hopping in this industry, you won't go very far.
I have virtually never seen an employed software role break six figures, let alone go significantly over. With contracting that's maybe not commonplace, but definitely achievable.
> I couldn't find a junior with more than zero coding skills for less than 30k
£30k might have been an exaggeration, but I frequently get inbox spam looking for experienced people in the £40-50k range.
> if you're not job hopping in this industry, you won't go very far.
I definitely agree with that.
I was thinking about this while working on a compilation of companies that have a four day week[0]. I even added a section with suggested replies to recruiters, along the lines of "While I'm not actively looking I'd be much more willing to talk if you had a four day work week like the companies on this list."
If instead of limited to no responses to cold messages there was a consistent thrum of "we want X", firms might get the message.
[0] https://thelistofcompanies.com
I disagree about the open source effect. I think the rise of open source has been a great catalyst for advancing the industry. If every company had to do everything themselves, the Internet would still be stuck in the 1990's.
Programmers are on the same terms as session musicians, only much better paid: we come in, get a fixed payment, but not royalties or (rarely) individual credits. At least the game industry does credits.
The trouble with copyright is that you won't get paid without a fight.
Broadly what you are asking for is power, which can only be taken, and only by a positive understanding that that's what you're doing and the cost associated with defending your position.
Software changes all the time (for better and worse). If git blame said I wrote 100% of the code 5 years ago, but only 10% today, do my royalties change over time to reflect that? What if my remaining 10% code is extremely business-critical, or what if it's dead code that just hasn't been cleaned up yet? Would new programmers intentionally refactor departed employees' code to take over that share of the royalties?
The closer approximation to royalties are the low touch/highly automated side businesses we hear about now and then, like some programmer setting up a small self-contained SaaS business. But economic and legal forces tend to push successful SaaS businesses to grow or be replaced (in-house), so sadly they're the exception rather than the rule.
Besides most software is written in a way to be useless outside of the original business. Having the copyright does very little unless I start the project with this in mind and keep a more generic base.
The reality is that a hit show may have 7-10 core writers and reach hundreds of millions of people. Software engineers working for a few years as part of a company with 1000 or more other engineers doesn't isn't really going to produce comparable upside per engineer.
Given the choice, most people would prefer higher up-front pay over lower up-front pay with an option to have more royalties on the back-end.
As a software engineer, I’ve had sales based bonuses on films and on games, which isn’t exactly the same as royalties, but it’s fairly close.
> Why isn’t software the same? If I write code that is still producing value for the company after 10 years, shouldn’t I get royalties for that?
It depends; there are multiple different answers.
Some people do get royalties, so sometimes it is the same.
Royalties are contractual, they typically get negotiated before the software is released. You can request royalties from your employer, and/or hire a lawyer or manager to ask. Employer might say no, but if you have a specialty or leverage, they might agree to it.
Royalties are common for very small teams and solo contributors, and not very common for large teams.
Continued employment, promotions, and bonuses can be considered a form of royalty.
It’s not common anymore for a piece of software to get released and never change again, which is the only way royalties really make sense. If a company is continually upgrading software for those 10 years with new releases, and new people, then how can the company figure out your royalties?
Best way to get passive compensation from future sales is to own the software or own the business.
Which leads to the second point: Hollywood is heavily unionized. If we unionized our industry it would look more like the Writers Guild and Screen Actors Guild than the Teamsters.
I haven't seen statistics, but there are a lot of Amazon mansions around here.
Tech companies are famous for turning low level employees into millionaires.
But if a writer is hired as a salary writer for a show, they're very likely to just get a salary. Same for a programmer.
Big name writers can negotiate a better deal for themselves and are a different story.
Thank you for eloquently stating this. I've thought a lot about this as well.
Except none of the revenue goes to FOSS contributors.
Even worse: the SaaS provider eats away any revenue from paid support from the authors.
Sales / Marketing is another huge chunk of the final product
Ask HN: Royalty based compensation for software engineers? https://news.ycombinator.com/item?id=20187775
Unfortunately it did not receive any traction. Royalty based comp would be an awesome step forward for engineers.
Similarly in software, you can't buy an OS on a per system basis for anywhere near the portion of its cost to produce and keep competitive. The large number of jobs customizing free software exist but they would also exist in a world where there were many competitive profitable stacks bellow them, and they would be buying or creating more expensive middleware instead of expecting anything not specific to their niche to come for free in the next OS release.
Usually it’s couched in terms of arbitrarily assigned levels/titles with status and exclusivity assigned to them. Or certain kinds of work from the employee favored over others. If you read the book Influence, you’ll recognize things like social proof and scarcity that can be used to manipulate us.
It _isolates us_ in our negotiating position with the organization. We have no idea, really, if we compare favorably or not to our peers. Hearing criticism without understanding how our contribution compares to others, how our _compensation_ compares to others puts us in an unfair negotiating position.
But at the end of the day, you don’t have to buy into that regime. If you’re competent, you can just vote with your feet and you will get another job.
The trick is to frequently exercise your power away from your employer. Write the occasional blog article, speak at a conference, or contribute to open source. You can use these as external signals to make your own decisions about your performance, and also get signal from the community about the marketability of your skills. This can come fairly directly in the form of hiring interest from other companies based on your activities.
In short, don’t wrap all your career options in your job. Keep a toe outside the company and always test those waters in case your situation at your job goes unfavorably.
Implicit in the question was a jump from having value to having leverage. It’s possible to have high value and low leverage. Software does produce high value, but there are also many many capable software engineers.
On a side note, I think software engineers have huge amounts of leverage within a given company, in the sense that they often have considerable control over what gets made, how things get made, how long they take, etc. I’ve watched engineers hold up projects they didn’t want to do by sandbagging estimates and building narratives of why it won’t work, and conversely working on the fun problems that interest them and express confidence and optimism that it’ll be great and get done fast. This happens in groups sometimes too.
> How could we increase our leverage?
Most important question to answer is not how to increase leverage, but to clarify what you want. To what end is an increase in leverage? More pay? More time off? Better working conditions? What exactly do you wish to negotiate, and who do you wish to negotiate with?
Speaking about engineering value and leverage is also myopic and seemingly forgets about the value and leverage of other people involved in selling software. Marketing, design, management, sales, QA, and all the other types of jobs that are required to produce and sell high profile software. All of them have value, and software companies can’t do without them.
To increase leverage as a group, software engineers would need to organize as a group. In order to have the leverage to make requests or demands, the entire group needs to be willing to hold out their value until the requests are satisfied.
> Why don’t we choose to use our rare skills for our own profit
Some of us do, by starting a business. Others of us do by taking high paid jobs. You’re in the right place; Hacker News is a forum attached to a well known and competitive seed fund, and much of the News is historically about how startup companies succeed and fail.