The Failed Commodification of Technical Work
ludic.mataroa.blog
The Failed Commodification of Technical Work
1–10 of 210 posts
Re: The Failed Commodification of Technical Work
#2He doesn't explicitly cover the whole AI angle to this - in the spring I wrote something about the obvious parallel between AI tools and low code programming which I think is relevant, basically that both make something easier but anything outside of that something harder so they don't really add efficiency
https://gist.github.com/rbitr/3294819148316df3ed90a2a1ce8a91...
Re: The Failed Commodification of Technical Work
#3I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified.
I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century.
Double-entry book-keeping was technical work and was usually run by highly trained individuals. Nowadays every shop keeper just scans a barcode and has the customer tap-to-pay.
There's not yet a drag-and-drop like interface for anything more complex than Scratch (wither Visual Basic!) but the hard part isn't the technical work of stringing together libraries; it's requirements gathering.
Speaking of which, it has never been easier to drop in a high-quality cryptographic library, or import an interactive map on a website, or WYSIWYG edit a website.
So, the author is right that you can't stick a bored 18 year old in front of an IDE and have them create you an ERP. But a lot of the "grunt work" of IT is now firmly a commodity.
Re: The Failed Commodification of Technical Work
#4I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
I guess the point may be that after 30-40 years of this, the low hanging fruit of commodification may be gone. Further, the more we commodify, the higher order our problems become and the specialist engineers you hire move further and further up the stack.
Also, not sure if it's always been the case.. but the latest vintage of SaaSified startups have a high % of products that don't actually do any of the things you want them to do yet. They want you to pay them for their service, so they can capture your use cases for implementation and then commodify them for other customers. So you end up with long lead times and IP leakage. Neat!
I think the example of templating SQL is always this misunderstood target for management. I dunno, the language in particular has survived an incredible length of time in our industry... it actually does a pretty good job. 99% of wrappers/DSLs/etc put on top of it make it far worse and still require you to dip into SQL for anything remotely non-vanilla. Further, instead of hiring SQL experts (there's many) you need to train up SaaSified DSL SQL wrapper X experts (none exist).
Re: The Failed Commodification of Technical Work
#5I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
to bounce on your point, there's the distinction between creative & non creative work. Sure, tools might help the creativity, but it can't replace it, and their article discusses how it can make it worse.
Accurate requirements gathering requires a spark of creativity...
Re: The Failed Commodification of Technical Work
#6I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
What you say is true, but the amount of "grunt work" is not constant over the years. In fact, I think the amount of "grunt work" in teh tech industry is just growing and not shrinking; I think the following look is quite obvious:
- amount of current grunt work: X
- new tech Z appears that makes X be reduced to 0.1X
- at the same time Z enables new ways of doing things. Some things become grunt work because they are a byproduct of Z
- amount of current grunt work: Y (where Y ~= X)
- ...
If the technological progress had stopped in the 2000s, then all the grunt work (originated in the 90s) would be esentially zero today. New tech just brings automation and grunt work. I don't think we will live in a society where there's practically no grunt work.
The most recent example is AI: there are AI tools that generate sound, images, video and text... but if you want to create a differentiating product/experience, you need to combine (do the grunt work) all the available tools (chatgpt, stable difussion, etc.)
Re: The Failed Commodification of Technical Work
#7I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
What you say is true, but the amount of "grunt work" is not constant over the years. In fact, I think the amount of "grunt work" in teh tech industry is just growing and not shrinking; I think the following look is quite obvious: - amount of current grunt work: X - new tech Z appears that makes X be reduced to 0.1X - at the same time Z enables new ways of doing things. Some things become grunt work because they are a…
Right!!
10/20/x years ago we didn't have DevOps, CloudOps, CloudFinOps, CloudSecOps, IaC experts, Cloud Architects, Cloud transformation experts, Observability architects, SREs, plus all the permutations of roles around "data" that didn't exist discretely, etc etc etc.
Re: The Failed Commodification of Technical Work
#8I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java).
But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well.
As the author notes. The only real fix is talented devs that care.
You can make a career out of that.
Re: The Failed Commodification of Technical Work
#9I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java). But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well. As the author notes. The only real fix is talented devs that care. You can make a career out of t…
The problem is that beyond the boilerplate we aren't solving commodity problems most of the time.
If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do.
That's why no two products are exactly alike and we don't just have 1 giant all world megacorp producing everything.Re: The Failed Commodification of Technical Work
#10I think he’s right. The tech industry has been trying to commodify devs for a long time (COBOL, Java). But there’s a sort of essential quality that reasserts itself no matter what you abstract. Despite the seemingly simple requirements paired with high level frameworks, a lot of our software still doesn’t even work well. As the author notes. The only real fix is talented devs that care. You can make a career out of t…
The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…
The problem is that beyond the boilerplate we aren't solving commodity problems most of the time.
The only people that see it is a problem are the ones that wish programmers were commoditized. Your complexity is my salary.