Ask HN: Do software engineers have leverage?
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?
209 comments
[ 0.26 ms ] story [ 285 ms ] threadSoftware Engineers have some leverage, but not a lot and not uniformly. The way to get more would be to get better at organizational politics, but that isn’t typically of interest to many software engineers.
In terms of negative effects the companies who resell or provide competing services without approaching the maintainers first are even worse. It's technically legal, but it's effectively a giant fuck you to the spirit and community.
In terms of leverage it's the ability to put food on the table and maintain a decent standard of living that has the most effect. To this end I'd rather see UBI and unionisation over everyone continuing to play stupid games where we all pretend we aren't there to maintain a decent standard of living.
At my company we have a policy of upstreaming changes where possible just for the pragmatic stance of reduced engineer time maintaining forks.
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.
> Do software engineers really have leverage?
I would say yes the sense of real impact, but only somewhat in the sense of actual power within the given economic system.
A more extreme example would be scientists who work on foundational science. They have been discovering things that are of such high impact that they transform the way we live.
Such scientists are typically (not exclusively) well off. But they don't inhabit the most powerful places in our societal hierarchy at all, nor are they compensated in terms of their real world impact. One reason might be that these people are intrinsically motivated, they simply don't seek that power or leverage.
> How could we increase our leverage?
By not selling our labor and instead (partially) owning our products and services or at least by (collective) bargaining.
The smallest but still impactful thing we can do is to not accept employments or clients that don't value our craft.
There are also many engineering focused companies that eventually 'sold out'. Their power structure changes, their engineers lose agency and so on.
> 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?
Because the positive impact of open source software can be much greater.
Some projects are simply not fit to be sold on a market, but still have possibly immense value.
This doesn't mean they cannot or will not be compensated. Foundations, donations and so on are used for that.
Many things simply cannot work this way, because they are based on being open and free. Wikipedia or Linux wouldn't be what they are otherwise.
The fact that Python exists and most of the details of its design for example were decided by engineers.
The greater demand for software engineers stems from the pervasive adoption of software in billions of peoples' lives. With less powerful open abstractions, innovation would have happened more slowly (which it sounds like you agreed with in your point), leading to less pervasiveness of software => less live software applications => less demand for software engineers.
Our leverage in fact comes from building abstractions that enable more rapid product development that leads to greater software pervasiveness in all of our lives - leading to greater demand of the engineers needed to maintain these abstractions and build on top of them.
Now, I agree with you that open sourcing might not be the best way to maximize the value you capture with your work. That's a problem worth solving - I see great value in better incentivizing valuable open source project creation and maintenance w/out overreliance on a couple of large cos.
Do you think there's a way to use the leverage of these abstractions to get better (aka decent) compensation for open source contributors
I'm thinking of for instance the maintainer of Faker, who posted that he would not continue maintaining the project unless he got compensated adequately for it going forward
Making money from open source often involves building an owning a large ecosystem.
Apple, Facebook, etc. all the big tech companies does lots of open source software. But the play isn't to make money from the software, but from the platform.
Perhaps, it's that money from open source requires huge investments. Because sometimes you're basically building an ecosystem.
Notably, these are two different kinds of demand. As sectors of the industry move from standard-creating software to standard-applying software, I would expect there to be less leverage for certain kinds of software development as those parts of the market mature.
It's not an either or since there are layers (Unix vs Kubernetes), but the guys that are paid to build the next Kubernetes vs learn to apply Kubernetes are going to, or if their pay is correlated with productivity, they should be valued differently.
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.)
Coasting means I can spend my best time & effort on stuff that isn't boring. I'm not coasting when it comes to my personal goals and dreams :)
Not everyone is up to writing textbooks and compilers all day.
You are waiting for death. That is the only thing wrong.
It's living.
evidence required.
People pursue coasting so they can do other things.
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.
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.
I think one contributing factor to this is it has become increasingly easy to be a math major and easily get a CS degree by dipping into a few CS courses at a lot of schools.
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.
A union and a strike.
“What do we want? Reimbursement for home office expenses! When to we want it? Time.now.utc! #unpaidhomeoffice”
a floor on pay defined roles
And it's working. In the last 10 years, CS has gone from an obscure group of nerds to the number 1 major on many campuses. I literally can't imagine having to compete with the sheer volume of new grads today for a junior position as a self taught developer.
I graduated undergrad in 2006 where many of my peers were passionate about their courses, had side projects, etc...Now it's just a means for a job and no need to learn beyond what is taught - and the kids (that my company hires, at least) expect the same of their mentors.
When I personally interview I see if they have a github. If they have one, I check if they actually have commits or they just uploaded all their school work without know what exactly version control is. It's not how I purely judge the candidates - but it is something I consider. If they don't have a github to show off their work, they better nail the technical part of the interview. But not everyone at my company interviews like that.
Since I had trouble finding a fulltime software job at the time, I ended up going to graduate school for a few years instead. That period (2002-2006) was a kind of golden era of people studying CS because they were interested in it. A popular mythology had set in for those few years that "tech was over" and studying CS was no longer worthwhile. Enrollments cratered.
By about 2006 or so, things had already began to pick up and were accelerating before the financial crisis started in 2008. There was a blip there with some layoffs and no raises, but things really started accelerating after that. More students eventually flooded back into CS programs, with increased dreams of striking it rich.
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.)
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.
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.
Income from work is obviously a prerequisite to maintain a good life for the vast majority, but in my experience (anecdotal evidence), there's a pretty sharp decline in life quality improvement after a certain threshold (which varies depending on life style and geographical placement)
After this point things like work/life balance, challenging tasks, ethical impact, and other, I dare say, less tangible benefits become more desirable
I think software engineers definitely have a lot of leverage, but it is probably hard to use it directly. My experience has been that many companies still operate under the antiquated assumption, that there's more supply than demand for software developers
Using the leverage directly doesn't work as they consider developers expendable
The best way to use this leverage then becomes to find another position that provides the desired benefits
I'm personally doing this at the moment, as I think my employer's business practices are unethical and I don't want to sell my services to projects I consider harmful to the world
So in conclusion I think the best way to use this leverage is through market forces. Consider whether you're selling your services at a value you're happy with and that you work at a business/project that aligns with your convictions
Since there's a shortage or developer skills, businesses who do not provide jobs that are desirable for engineers will simply go out of business, as they can't develop or maintain their product
The company didn't fix it because they were profiting from it, and so I left, which cost the company >10x those profits. Either they didn't care, weren't aware of the tradeoff, or simply didn't want a lowly engineer tell them anything about ethics.
A great developer can fix the codebase with a single line of code. A mediocre developer adds hundreds of lines of code to achieve the same thing.
It's definitely hard to measure, and requires some level of understanding before it's even possible to properly valuate.
If that were the case, the companies that did not treat every individual engineer as a special and unique snowflake would have been doing badly. They do not. Hence, it can be derived that while the engineers believe that they are unique super special snowflakes, in reality they are more like electricians - totally interchangeable at a given level of skill.
A closer analogy would be something like.. these companies are employed to unload cargo on ships from the dock. Some engineers can unload ships very quickly, and some propose using shipping containers and cranes. These are much more efficient. But the unloader companies don’t care, because they know they have the contracts locked up anyway. They are not especially intelligent or ambitious other than in the sense that they have some cleverness in the sneaky sense. The company continues to make money, the managers get their bonuses, and there’s still billions in economic waste happening but nobody with the ability to change it cares.
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
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.
https://news.ycombinator.com/item?id=27559804
With licensure comes regulation. Oddly there seems to be more demand and better pay for unlicensed computer programmers than there is for engineers in the licensed fields. Every electrical engineer I know, who can program well enough to do it for money, eventually becomes a software developer.
At the same time, I don't regret not making a career of programming, because I'm not sure that I would have been happy or successful in a pure software job. When I was a kid, I had a summer internship at a computer facility, and programming struck me as something that would be interesting if I was doing it in the service of my own interests, but pretty dull if doing it all day for someone else. Granted, that was a very narrow perspective, and possibly obsolete, but it was the best I could figure out at the time.
Working on that system has had significant impact on the D programming language and my ideas about programming. Who'd have thought that would happen?
pg has a good article on doing things that don't scale[0] and showed how the AirBnB guys went and setup the first listings manually, but it's actually far more general than just kicking off the network effect. Moats are things that don't scale. Open Source software scales perfectly. Billion dollar companies are billion dollar companies because they can use Open Source software wrapped around some Moat-able structure. The more Open Source Software that exists, the bigger the walled garden.
When Google spends a billion dollars sending cars all around the world taking pictures, they are doing so in a way that the Open Source world can't centrally compete against, as they don't have the billions to get that done. This means that all Open Source mapping software will be missing a crucial feature that users rely on, and will therefore go unused. But meanwhile the libraries that those Open Source Software use, Google can freely use within their walled garden. On the other hand, Microsoft paid a great deal of money to researchers with Encarta and had this same exact structure and Wikipedia came in and disrupted them. It takes more time for the decentralized approach to come online, but as long as it's possible and the data is kept high quality Google Maps will slowly lose market share to OSM.
Open Source software is generally created as libraries, whereas most companies build frameworks. Frameworks are easier to setup and give control to the makers, but they do not scale. Why is it that Microsoft Windows has 13 different dialog generations? Because each is a framework on top of a framework on top of a framework. It's amazing that they can even get that done.
On the other side, OSS is generally built on libraries. When the 2 UNIX devs were in a basement building UNIX and were able to out-compete Multics[1], they did it because they were building libraries that could talk with each-other using pipes around the boundary. Applications that communicate based on input-output with no internal state behave just like pure functions do. Pure functions compose. When Linus built git in 10 days, he was able to do this because the core idea of git isn't actually that much work. The library is built out of composable blocks that neatly come together. Microsoft's TFS Source Control is a framework that acts on your behalf and therefore the bigger the project gets, you need n^2 people to work on it.
You don't get paid for your value. The libraries create value but by definition that value goes to the user, not the creator. When you build a framework on top of a library, that value goes to the framework owner. Who owns the moat? The capital owners. Why don't you use your ability to create programs? Because the moats cost money to build and while you can create value building software, that value doesn't go to you. But by all means, make the world a better place.
[0]:http://paulgraham.com/ds.html
[1]: https://www.youtube.com/watch?v=3Ea3pkTCYx4, thanks to this HN comment(https://news.ycombinator.com/item?id=27494671) for this reference.
Every company _should_ be a technology company. If developers had authority over parts of running the organisation, just imagine the innovation that could come out of that.
If there was less open source, developers would have to be better at what they do (more skilled). And yes, lots of money could be made with proprietary web servers, languages etc.
In my experience, this is absolutely not true. Everyone I know struggled to get interviews. If you got an interview, a single mistake would end any chances of getting another interview.
The algorithm rounds were brutal, esp online coding tests. I have been grinding leetcode but I'm mentally exhausted now, and working an unpaid job at a startup to at least stay in the game for now.
https://www.dol.gov/general/topic/wages/minimumwage
If it’s F-1 OPT or J-1 I get it.
Even a TN would put you in the same place as the H-1B.
I would just give up and get some other job with less requirements, but I don't know what that would be. There were a few sales jobs that I was considering.
Unpaid work at a startup is possible if you have an equity stake or some other arrangement. Plenty of startups would never exist if a couple people hadn't gotten together and worked for free (and additionally invested their own money) to bootstrap. But it doesn't sound like that applies to GP's situation.
I'm not sure what GP is doing wrong, but it sounds like they're only applying to places out of their league and/or only FAANG. The vast, vast majority of paid software job interviews don't involve ANY algorithm whiteboarding or online test-taking. That happens at a minority subset of companies, and there's a huge range of jobs in between "working for free" and FAANG that are trivial to get with any qualifications.
[0]: https://www.dol.gov/agencies/whd/fact-sheets/71-flsa-interns...
As someone who took over a year to get a job in software after graduating C.S. from a local university, I hate this myth. I was applying absolutely everywhere. It's easy to get a job if you have some kind of name recognition, but if you've graduated with a mediocre GPA, no internship, and no "real-world" experience, it can be very, very hard.
In the time after graduating, I took online courses that taught me things actually relevant to the job postings I was seeing, applied to tons of jobs, learned git, worked on personal projects, and attempted to network through user groups and tech conferences.
Finally, 9 months after graduating from CS and loads of rejections later (I think I only got 2 or 3 interviews in that time), I was able to get an internship with someone I met at a conference who took pity on me, which paid $15/hr (and with very limited work available).
Finally, after doing this for a bit, and continuing the self-education, I was able to get another job (which paid about the same), and then another (which paid a little bit more), and finally an actual full-time job in QA/support which was salaried with benefits. The salary was still low (like $42,000), but improved quickly within the company as I put in a couple of years and proved myself.
Before looking for work in my field, I did have very good references as a waiter in several restaurants. I had a CS degree, and was able do basic programming (fizzbuzz and similar-difficulty problems were trivial). And everyone said it's so easy to get a job. But this wasn't my experience, and if I didn't have help from family I wouldn't have been able to put the time and effort in to actually learn the things I needed to find work in tech.
> The vast, vast majority of paid software job interviews don't involve ANY algorithm whiteboarding or online test-taking.
Not my experience in the least.
Good luck in your ivory tower, and piss off.
I think the determining factor is just "recognizable big brand on resume".
Outside of FAANG (and FAANG wannabes) I have never seen leet code stupidity. Nor has any of the people I know in the SW field (across multiple industries, fintech, aerospace, data analytics, etc.)
Whiteboard system design -- sure. Small practical example project, sometimes. But never that type of brain dead, artificial realtime algorithm coding.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 only leverage an SE really has is asking for more money after they've delivered a lot of value -- it's not a lot of leverage, and it's conditional.
What if there are actually two independent markets in play but they're masquerading as one?
Everyone is captivated by Big Tech (a slightly larger, more inclusive, subset which includes FAANG) pay. There's no doubt any engineer would love to be making $250k+/year. However, this market is selecting for something very different from the larger, common, market.
We need to ask why Big Tech pay is as high as it is. I don't believe it's driven by supply and demand in the classic sense. Instead, Big Tech sees its candidate pool as "free agents" [0]. This is an important distinction if you view these free agents as a source of potential competition, either individually or signed to another "team".
What if Big Tech pay is a form of greenmail? [1] Much like sports teams -- where pay is also extremely high -- the owners are aware that they're possibly overpaying for these people to sit on the bench. However, their risk analysis tells them that the cost is worth the small loss. [2]
This, to my mind, explains why Big Tech is focused on a very specific sliver of the engineering talent pool: graduates from top 10 schools. These people tick all the boxes: young, smart, fast, energetic, and unattached (typically). With this model in my mind, Big Tech interviewing practices make perfect sense. They aren't looking for "CRUD-a-day" programmers. They're looking for those few engineers who, even under immense pressure, still rise to the occasion and perform. This signals that they could be serious competition if left alone as a free agent. Note: I'm not saying that any one of these candidates will become competition. I'm sure the probability distribution is low but it isn't zero. Unlike other fields -- where barrier to entry is extremely high -- one of these hot shots might -- once every 10 to 15 years -- pull a miracle out of the ether and disrupt Big Tech to the point of destroying them. [3]
The other market is everyone else who uses and requires software to run their business, but software isn't their business. Unfortunately, this market -- if they could get it -- would just as soon buy something off the shelf instead of hiring software engineers. It's only because such COTS doesn't yet exist that this market still requires software engineering talent.
However, unlike Big Tech, this market doesn't see engineers as competition (and, generally speaking, they aren't). This severely limits the leverage that engineers have when negotiating with these companies. Being blunt: this market is looking for factory workers who shut up, sit in the fishbowl, and do what they're told. The cheaper the better. [4]
It seems to me it benefits Big Tech to blur the differences between these markets. However, engineers need to wise up to the reality of the bifurcation and plan accordingly.
[0] https://www.collinsdictionary.com/us/dictionary/english/free...
[1] https://en.wikipedia.org/wiki/Greenmail
[2] Small loss is relative, of course. Individuals have a difficult time understanding how this math makes sense because a) the numbers are far larger than they're used to seeing and b) they can't see all of the other numbers at play which balance out the strategy.
[3] https://youtu.be/oD65g2RFSHI?t=582
[4] Yes, not every company in this market is like this. However, it's extremely difficult to know this from the outside when you're trying to f...
The value of OSS and being part of its development is that it's done in the open and that the active contributors are undeniably very good at what they do if that is apparently keeping a lot of OSS users happy. If I have to choose between two engineers and one of them is behaving professionally on Github with a nice track record of issues, pull requests, perhaps a few nice repositories with lots of stars, etc. It's no contest at all. I'll be extremely biased towards the latter given their proven track record and not really interested in why that other person might feel above doing that.
IMHO it's impossible for good developers to engage with the OSS world and not contribute to it. At minimum, you are going to run into issues and act professionally by investigating and engaging on the issue tracker. It's just basic due diligence. And it includes looking through existing issues, the comments, and where necessary the code. A lack of any Github activity whatsoever for me is a red flag when it comes to seniority. You can't be senior and not do that.
Leverage in business negotiations comes from understanding your customer and being able to address their real needs (as opposed to what they are asking for). A simple strategy is to ask for more than they are offering. This puts them on the defensive. Now they need to argue your value down and they are actively thinking about what you could do for them. When they say no, it needs to hurt them a little because they are missing out. They have to actively regret the decision. You won't always get what you want obviously and if you consistently don't either your sales skills suck or you are the problem and you need to own that. Either way, try to level up. If it's the latter, engaging with some OSS projects isn't the worst plan.