The labour arbitrage theory of dev tool popularity
baldurbjarnason.com
baldurbjarnason.com
For instance, I don’t think the component model in UI frameworks is popular because it commoditizes UI developers, but rather because professional developers seek to commoditize aspects of their own work which are rote or neatly fit an abstraction that frees them up to think about more pressing concerns. The same logic would apply to basically any layer of technology which has the same leverage… the only reason we’re discussing this one is because the agreement of its utility is slightly less than unanimous.
None of the ideas here stand up to scrutiny. For example, Angular with its more opinionated design and framework approach was a much better choice for regularizing developer effort and making devs fungible. But by all accounts it lost to React, which is frequently criticized in comparison for allowing too much individual variation in development style.
React itself has become increasingly more complex over the years as it's moved up the S curve and the design direction is driven towards more and more remote parts of the problem space. More than ever, it requires specialized knowledge to use correctly.
Svelte - of which the author is a fan - fits his thesis much more than React. Svelte is billed as simpler and easier to learn and use than React, without requiring developers to wrap their heads around concepts like hooks, reducers and suspense.
Nope. Because they allow people to be easily replaced. Nothing to do with how easy or good the framework is. That's the whole point of the article.
Having frameworks that allow more devs to do more things means correspondingly that more people can be hired for those things with less training. In this respect, there is an obvious overlap between employer and developer interests.
Take MongoDB from the article. IME the biggest advocates for MongoDB are not managers (who barely have any idea what it is). It's developers who just want an "easy" way to store data that corresponds closely to the JSON document format they are used to, and doesn't force them to think about "annoying" and "outdated" things like relational modeling, joins and schema migrations.
If fungibility and lowest common denominator hiring drove the popularity of dev tools, then .NET and Angular would be ruling the roost.
I'm in a position where at times I select a framework for a new product. I'm often picking these frameworks just as much based on the ability for everyone to effectively work with and communicate with other developers easily, as much as the framework's technical aspects.
Franky I'm more concerned with developers being able to work happily and efficiently than "labour arbitrage".
I feel like the author could write off any found efficiency as "labour arbitrage".
Standardized frameworks makes recruitment easier – but it stops there. Once you onboard an employee and they spend considerable time integrating into the company and developing specific knowledge, they are no longer easily replaceable. If they are a key component of the team it will be painful to replace them, it will take years to hire someone new and get them back up to that same level. It’s better to just suck it up and pay them more than endure the costs and risks of hiring new labor.
And somehow at the end of this he comes to the conclusion that software engineers need a union? We're on of the highest paid, most flexible professions ever.
It seems like the thing missing here is the simple fact that engineers DO have significant bargaining power already, and have CHOSEN to use standardized solutions because they are good, well supported, and have wonderful communities of helpful people.
What happened to this guy? Seems incredibly bitter.
"No react, that's too much labour arbitrage!" ?
As I read it, the writer thinks that a union can somehow bargain with management to get different technical tools adopted that will not commoditize developers.
I don't agree with him because the incentives pushing management to commoditize developers are real business incentives. Management doesn't care about technical quality per se; it only cares about technical quality that makes a difference in how much customers will pay. And customers don't care what technologies you use for your app under the hood; they only care about whether it does what they want. If management can make the app do what customers want using interns pulling code from ChatGPT and tweaking it until it stops crashing, at a fraction of the cost of actual expert software developers, that's what management will do.
Developers having a union doesn't change any of that, and if the union succeeds in keeping management in that particular company from using interns and ChatGPT, that just means that company will be out-competed in the market by some other company that doesn't have a developers' union and can give the customer a lower price. The only way for developers to break that cycle is to take on the business risk themselves and start their own developer-owned company that succeeds in the market by leveraging the developers' expertise to provide cheaper solutions to the customers' needs.
How much is this actually true, though? It's probably true in small companies where the engineers might also be the technical managers. But is it true in a large company where management might have little or no technical expertise at all, but still insist on making technical decisions?
Good thing I don't particularly care about this rando's opinions of me!
Work from home very much encourages it long term, even if not so much short term.
I strongly disagree with the authors conclusions about the technologies and the premise.
This is truly peak HN content.