We're not innovating, we're just forgetting slower
113 comments
·July 4, 2025raincole
cherryteastain
> THE GREATEST IMPROVEMENTS in the productive powers of labour, and the greater part of the skill, dexterity, and judgment, with which it is anywhere directed, or applied, seem to have been the effects of the division of labour.
> To take an example, therefore, from a very trifling manufacture, but one in which the division of labour has been very often taken notice of, the trade of a pin-maker...a workman not educated to this business...could scarce, perhaps..make one pin in a day, and certainly could not make twenty. I have seen a small manufactory...where ten men only were employed...Those ten persons, therefore, could make among them upwards of forty-eight thousand pins in a day.
- An Inquiry into the Nature and Causes of the Wealth of Nations, Adam Smith, 1776
alganet
When you divide and specialize manufacture, you get efficiency.
When you divide and specialize design, you get design by commitee.
marcosdumay
You clearly don't.
If you design a desk lamp, it wasn't designed by a committee just because a person designed the screws, another designed the plate stamping machine, another designed the bulb socket and etc.
jjmarr
I can design a simple op-amp circuit and deploy to a Kubernetes cluster because Canada has a "Computer Engineering" degree that's a hybrid between CS/Electrical Engineering.
It doesn't work in practice. CS graduates from my school are trained on git and Linux command lines. CE teaches none of this and students discover in 3rd year they cannot get an internship because they share all their code as IDE screenshots in Google Docs.
But we do know how the entire process of building a computer works, from quantum physics, semiconductor doping, npn junctions, CMOS logic, logic gates, hardware design languages, assembly, C, and Java.
If only all of this "important" knowledge didn't crowd out basic skills.
bee_rider
I think designing the EE and computer engineering curriculum is pretty tough. Because:
* the EE’s need to learn matlab or numpy, to use as a tool
* so do the computer engineering students, probably
* the computer engineering students also need to learn low level stuff, because they might reasonably end up writing drivers or embedded code
* separating out what should be in which classes is kind of tricky; keeping in mind that the students don’t necessarily know anything about programming at all, you probably need some kind of “intro to the general idea of programming” class
* realistically when they start the program they don’t know much about what the jobs look like, so it is good if they are able to switch paths, for the first couple years
* realistically a lot of people just want to get a stem degree and then go be a programmer anyway
WillAdams
Time was that this sort of thing was covered in courses such as:
https://ocw.mit.edu/courses/6-001-structure-and-interpretati...
but they've since switched to Python for reasons:
alephnerd
> CE teaches none of this and students discover in 3rd year they cannot get an internship because they share all their code as IDE screenshots in Google Docs.
Which CE program did you study at? I've worked with Waterloo, UBC, and UT ECE grads and they have similar levels of knowledge of programming fundamentals as their CS grads. I would be shocked if a first or second year BS ECE cannot use Git or some alternative VCS - that means there are more fundamental issues with your university's engineering curriculum.
> I can design a simple op-amp circuit and deploy to a Kubernetes cluster because Canada has a "Computer Engineering" degree that's a hybrid between CS/Electrical Engineering.
Same in the States, ECE and EECS programs tend to teach both fairly equally, and there are plenty of top programs with a strong reputation in this (Cal, MIT, CMU, UIUC, UT Austin, UW, UCSD, UCLA, GT, etc)
The issue I have noticed though is the decline of "CSE" programs - CS programs with an added CompArch or OS internals focus. CS programs are increasingly making OS internals and CompArch optional at the undergrad level, and it is having an impact on the pipeline for adjacent fields like Cybersecurity, Distributed Systems, Database Internals, etc.
I've harped about this skills gap multiple times on HN.
no_wizard
I agree with your general thesis, but I will say someone who understands the conceptual and at least simplified way everything comes together are usually better at their speciality than those who know their speciality but don’t have some understanding of how things come together
9rx
> And probably none of them knows how to grow and fertilize the crop to feed themselves.
As a farmer and software developer, with a electronics hobby (and it being a part of the job of being a farming these days), I can check off growing crops, op-amp circuits, and Kubernetes deployments.
I don't own, or have reasonable access to, the necessary capital for laminating circuit boards and synthesizing minerals.
> No one knows everything.
But, really, access to capital is the real limiting factor. Getting to know something isn't usually all that difficult in and of itself, but if you have no way to do it then you're never going to get to know it. Collaboration is less important to efficiency than optimizing use of capital. Its just that we don't have many good ideas about how to optimize use of capital without also introducing collaboration.
anonzzzies
It was not a great remark indeed, however, most modern devops we meet (all seniors, big corps) know nothing lower level, often not much about Linux or what the coding etc. And it is always terrible: like LLMs, they like adding complexity: just put a nlb with an alb and private link with a gateway with a nlb with an alb! These guys (sorry, it is generally guys) believe they are experts but they are terrible. Get paid as experts though.
You don't have to know everything but BASIC understanding about the what is underneath would be nice.
SkyMarshal
Humans congregating into cities, specializing and developing expert capabilities in particular fields, and collaborating and relying on others for what they're not specialized in, is a big part of the story of the Enlightenment -> Industrial Revolution -> Electricity Revolution -> Information Age.
kragen
If I remember correctly, one of the first white people to successfully visit the Māori reported that when he told them he didn't know how to make pistols, black powder, porcelain, hemp rope, etc., they thought he was lying, because in their culture everyone knew how to make everything. There was a division between men's work and women's work, that was all. They had specialization, but not of the kind you are talking about.
The Little House on the Prairie books fictionalize the childhoods of Laura Ingalls Wilder and Almanzo Wilder in the US in the late 19th century. They expected their readers, whose grandparents had grown up in similar conditions, to believe that one or more of their parents knew how to shoot a bear, build a house, dig a well, poultice wasp stings, cast bullets, fertilize and grow crops, make cheese, whitewash walls, drive horses, run a business, read a book, play the fiddle, dance a jig, sing, keep bees, clear fields in forests, harvest honey, spin thread, weave cloth, thresh wheat, and many other activities. There were "store-bought" goods produced by the kind of specialization you're talking about, but Laura's family had a few durable goods of that sort (Pa's rifle and ax, the family Bible) and mostly they just did without.
More recently the Lykov family survived 40 years of total isolation from society, missing World War II completely, but did suffer some heartbreaking losses in material standard of living because they didn't know, for example, how to make ceramic or iron. Agafia Lykova is still living there on her parents' homestead, nearly a century later.
Specialization is indeed very efficient, but that answers the questions, "What can I do for others?" and "How can we survive?" Historical answers bespeaking specialization are archived in many of our surnames in the West: Cooper, Fuller, Goldschmidt, Herrero, Nailer, Roper, Molnar, and, of course, Potter.
But for those questions to matter, we also need to answer the questions, "How can I be happy?" and "How can we be happy?", and for thousands of years it has been at least widely believed that devoting your entire self to specialization runs counter to those goals—among other things, because it can open doors to the kinds of exploitation, unfreedom, and insecurity the article is lamenting. And sometimes regional specialization leads not to prosperity for every region but to impoverishment, and regaining the lost skills is the path out of the kind of abysmal poverty that produces regular famines; that's why there's a charkha on the Indian flag.
TI was no exemplar here; you can't even write your own machine code to run on the TI-99/4A, but the situation with Nest is in many ways far worse. I think it's worth distinguishing between situations where someone chooses not to learn about, modify, or repair artifacts, and situations like these where they are not permitted to learn, especially when the prohibition is established in order to exploit them economically, as in both the TI case and the Nest case, or as in medieval guilds.
Some specializations are thousands of years old; tin mining in Cornwall supported much of the Bronze Age, and silicosis was already known as an occupational disease of potters in Classical times. But 80 hours a week breaking rocks in a tin mine is not a path to human flourishing, nor to economic prosperity for the person doing it. Neither is buying thermostats you aren't allowed to understand. We shouldn't idealize it just because it's profitable.
WillAdams
Similarly, there were the _Foxfire_ books which attempted to document the knowledge and skills of Appalachians, or W. Ben Hunt's writings on woodcraft and his interpretation of Native American Indian lore which was shared with him.
For a mechanical approach to this, see the "Gingery" books which start with the basics of investment casting in the first volume, then using castings to make a lathe in the second (operating on the premise that a lathe is the only tool in a machine shop which can replicate itself), then using the lathe to make the balance of tools needed in a machine shop.
corimaith
>and for thousands of years it has been at least widely believed that devoting yourself to specialization runs counter to those goals.
Well no, civilizations like the Maori are the exception, not the norm. Rigid class roles and specialization have featured prominently in essentially every Eurasian civilization from Egypt to Han China, which held the bulk of humanity and uts developments. Nor did questions of individual happiness matter, what concerned people at the times were questions of martial duty or religious worship.
kragen
The Māori weren't civilized (they didn't have cities at the time) and were far from the exception; cities didn't hold the bulk of humanity until 11 years ago. We remember Middle Kingdom Egypt and (1500 years later) Han China because they were civilizations and consequently were literate. But throughout almost all of human history, only a small fraction of the population has lived in the civilizations we see looking back. Even in Eurasian civilizations, until the Industrial Revolution, 90+% of the population were relatively unspecialized peasants with skills nearly as broad-based as Laura Ingalls Wilder's parents. It's easy to forget about them because they weren't literate and so can't speak to us from beyond the grave like Epicurus, the Egyptian Book of the Dead, Sima Tan, or Marcus Aurelius.
And most people lived outside civilization entirely. They had very diverse lifestyles, but we can make some generalizations. Even when they didnt leave diaries for us to read, we can infer that they had much less specialization, both from economic principles and from archaeological evidence.
It's certainly true that people in civilizations are, and have always been, focused on martial duty, and everyone everywhere is concerned with religious worship, though they may call it something else for social reasons. But people have always been strongly interested in individual happiness, even in civilizations. The Buddha founded one of the most important religions 2500 years ago on the basis of individual happiness, to the point that after he died, one of the most contentious issues among his followers was whether holy people had any duty to help other people achieve happiness as well, the origin of the Mahayana bodhisattva vows. Epicurus's philosophy and Marcus Aurelius's writings are also centered on the pursuit of individual happiness, as is much of Plato and of course the Mohists. Even religions and philosophies that preached lifelong duty and sacrifice above all else, like Christianity and Islam, offer it as a path to individual happiness in the afterlife.
dingnuts
as you've identified, specialization of roles is a common trait in advanced societies, but not in pre-historic ones. And yes, American frontiersmen participated willingly in one of the last pre-historic societies. Specialization is what allowed us to stop subsistence farming and/or following herds.
kragen
Maybe people participating willingly in those societies—indeed, fleeing civilization en masse to the frontier and to join "Indian" tribes, while migration from the tribes to the civilized colonies was almost nil—should tell us that civilization isn't all upside?
Economic productivity is an important means to happiness, because it sucks to go blind or subsist on soft foods because you can't get the necessary medical and dental treatments. And it's terrible to never see your parents again because you don't have the material means to visit them. But there's a point of diminishing returns beyond which sacrificing more of your happiness for continued economic gains amounts to cutting off your nose to spite your face.
tspike
You could replace the word "advanced" with "unsustainable" and the thought still holds.
dev_l1x_be
To a certain extent yes. However, when i get rid off a layer of abstraction from my supply chain I usually get better results. That is the scary part to me.
thinkingtoilet
> Software has followed the same trajectory, piling abstraction upon abstraction until we’ve created a tower of dependencies so precarious that updating a single package can break an entire application.
This is like saying old software is so simple that updating a line of code can break an entire application. It's a silly thing to say. No matter how complex or how simple a piece of software is, you can easily break it. If you have a program that prints out "hello world", guess what? Updating a single character can break the entire application!
The world is more complex now. We've stood on the shoulders of giants who stood on the shoulders of giants. A few centuries ago a renaissance man could make advances in multiple fields. Now people are specialized. It's the same thing with software. Of course, people take it to an extreme. However, you go ahead and write your own crypto library, I'll use a vetted one created by experts.
JanneVee
A crypto library is "essential complexity" and running a node.js runtime inside a container in kubernetes node in a virtual machine on a server owned by a hyperscalar cloudprovider is "accidental complexity". I'll take the crypto library any day of the week but if I get to decide how to host a webapplication I'll stay away from that fragile tower of abstractions. As it happens I currently make a living from that "accidental complexity" so it is not a matter of skill, I just see it as unnecessary.
softfalcon
This is exactly my take on folks bemoaning the evolution of complexity in software (and hardware) worldwide.
To lend some credence to other folks points of view, there are arguments I can agree with that are adjacent:
- "We don't need that complex framework for our needs, we stick to a simpler, older library."
- "We decided to not use <shiniest_new_toolkit> it had performance issues that the maintainers are still sorting out."
- "Working with the new framework showed a lot of promise, but there is still a lot of instability in the API since it's so new. We couldn't commit to using a toolkit that hasn't been nailed down yet."
These are actual concerns and shows caution towards adopting new things until they match your use-case, dev-timelines, and performance requirements.
shermantanktop
I’d add “The DOM api probably already has everything you need and has zero dependencies.” That applies to many lower-level APIs which have gotten smarter and better over the years—often in response to the needs of fancy frameworks, but now they are pretty rich by themselves.
“I don’t have time to learn a new framework, I have things to do.” Everybody’s cool new abstraction is a cognitive burden for someone else.
citrin_ru
A complex software much much easier to break accidentally. While one character can break "hello world" is not something one would do while trying hard not to break it. And potential bugs in a simple application much more likely will be cough during a review. For a complex application no-one have a good mental model to predict what a given change would do reliably. For a simple one it's possible.
alganet
If I break some source code by messing with it, I know what happened. I might even learn from it.
Now if npm breaks it, or Claude breaks it, a developer might not even know what was broken.
He's talking about that kind of thing, not the resilience of code to take random character deletions.
IT is very much non-specialized compared to older disciplines. It's so young. Every single one of us is still a jack of all trades in some degree.
You're relying on the "don't roll your own crypto" popular quote to drop the mic. That's misguided. This advice comes from an argument of strength by numbers, not anything related to abstractions. It tells me you don't understand it.
darig
[dead]
1718627440
Doesn't it mean more that some packages aren't conforming to common sense like semver?
unyttigfjelltol
> (Google is less than helpful with a dumbed-down user interface that basically tells you that “something went wrong.")
This UI trend of denying access to under-the-hood complexity is deeply unsettling. It creates a cliff edge failure mechanism where the system (which often is essential) works and then suddenly doesn't. No warning approaching the failure state, no recourse on the far side, completely baffling how this became an industry standard.
convolvatron
the best part is when you look at the from the perspective of composition. if I build a thing using complicated 'industry standard' components that are just supposed to work, then when something happens I'm pretty much lost. now take my thing, add some marketing about how it 'just works', and have someone else use it in a high level concatenation of other such functions and pretend it 'just works'.
now we are actually employing large numbers of people just to babysit these half-assed things, and everyone is fine with it because we all used 'industry standard' components, and thats really the best we can do isn't it. armies of on-call system resetters are just part of the picture now.
bee_rider
> The VHS player in my basement could be fixed with a screwdriver and a service manual (OK, sometimes an oscilloscope). Meanwhile, my Wi-Fi router requires a PhD in reverse engineering just to figure out why it won’t connect to the internet.
This seems like a pretty weird example, right? WiFi routers don’t connect to the internet. If your modem can’t connect to the internet, something has probably broken outside your house. That’s the sort of locally-unsolvable problem that everybody last century was familiar with; the crappy copper telephone wire that was never designed to let the Internet blast through it and it will eventually rebel and start giving you noise.
If your router doesn’t work, I don’t know. Cheap routers are not a new invention or sign of the times, I think.
VHS players, if I remember correctly, often died in mysterious ways (they have all sorts of little motors and finicky sensors in them).
SoftTalker
VHS players went through a typical consumer electronics evolution. The first ones were large, heavy, and repairable if you knew what to do. By the end they were lightweight plastic and you didn't even consider repairing one, as an hour of time at a repair shop would cost you more than buying a new one. They were disposable.
freshtake
I don't know, I think the point of the example is one of transparent engineering. VHS players could break for any number of reasons but the manufacturers used to put in effort to make them repairable. Obviously a much simpler piece of hardware, but the relative effort felt much greater.
When I used to use Google Wifi, it regularly struggled to connect or establish/maintain connectivity to the outside world, even though my modem was successfully connected. Similar to nest devices, you often have to power cycle them several times to get them into a good state
FilosofumRex
Abstraction explosion is surly detrimental to innovation, but so is "mathification", propelled by rapidly declining computational costs.
Romans tremendously progressed, despite using inferior "math" compared to the Greeks, and Americans compared to the English & French. Note how willingly China ships its top mathys to the US grad school while retaining its best engineers at all costs.
Only technologies that make it into tools/hardware (realware) will survive, the rest are destined to be e-wasted.
ryukoposting
> They can deploy applications to Kubernetes clusters but couldn’t design a simple op-amp circuit.
If the thesis is that we should understand the systems we work on, then sure, I can get behind that. At the same time, I wouldn't expect a mechanic to know how to process iron ore into an ingot.
alganet
Machinists know their materials. They might not know every step to process it, but they understand the manufacturing process of different kinds of metals and their properties.
They definitely don't "vibe machine" without thinking about underlying concepts.
MountainMan1312
As a redneck I think you vastly underestimate the prolifity of vibe machining
alganet
I am sure hobbysts vibe machine a lot, and there's nothing wrong with that, but that's not supposed to be representative of the industry.
827a
Software engineers aren't to computers as mechanics are to cars. The closest correlate is, like, automotive engineers working at Ford or Toyota; and I would 100% expect that someone involved in the process at those companies has reasonably deep knowledge about, for example, the structural characteristics of casted metal.
xenocratus
I'm sure he wrote all of this on, sent it over, and now is re-reading it from his Texas Instruments TI-99/4A Home Computer.
phendrenad2
If everyone could do Bode plots, design an op-amp circuit, design their own programming language and wrangle kubernetes clusters, would it really improve the world? Or would we just have a lot of useless knowledge?
thadk
idk, if you're going to center that good old TI computer, you gotta contrast the Conways law of that company, and the semi-solo person sharing 'grammable tidbits. The desired carrying capacity lies in that institution. Today it's in Shenzhen.
But the ~1980s corporation is no longer and it was driven by the hype cycle too, it's just not a recognizable one. You can google the adverts or read Soul of a New Machine.
analog31
Ironically, the technology that amazingly still works after 40 years is shown in front of a shelf full of books.
paulryanrogers
Books are fragile. Their pages often include acid in order to self destruct. For resilience we should be recording on clay tablets. /s
analog31
Oddly enough, I've read that the clay was originally re-usable, and the ones that are preserved were baked in accidental fires.
Kind of a weird opposite meaning of book-burning.
david927
Someone made a video clip showing the Crumbl Cookies ingredients list and each one has around 100 ingredients
https://x.com/WallStreetApes/status/1940924371255939236
Our software is like that. A small system will have a crazy number of packages and dependencies. It's not healthy and it's expensive and it's stupid.
Culture tends to drive drunk, swinging wide to extremes and then over-correcting. We're already fully in the wrong lane when we start to have discussions about thinking about the possibility of change.
BiteCode_dev
Everything in the physical world is the same. There are hundreds of pieces even in the smallest toaster, and no one in the world knows how to make half of one without all those external dependencies:
https://www.youtube.com/watch?v=5ODzO7Lz_pw
It's not a software thing, it's just how humanity works.
SketchySeaBeast
Even if you consider something like "build a bridge", that classic comparison of software and traditional engineer, all the components of said bridge have been created by someone else with particular expertise. The civil engineer who designed where the iron beams will go played no part in the metallurgy of those beams.
hiAndrewQuinn
Milton Friedman put it best, in "I, Pencil". Everything around you is the result of hundreds to thousands of economic actors, loosely but robustly coordinated in a way to get you what you actually want at as low of a price as you can get away with. The complexity of the supply chain is the price of admission to the game.
nobodyandproud
Yes and no.
The physical world is bound by rules that are unchanging (more-or-less). Above this layer we’ve also devised and agreed upon standards that remain unchanging, though it’s regional: Voltage, screw/bolt sizes, tolerance levels, materials, material measurements, etc.
At this layer, we’ve commoditized and standardized because it’s useful: It makes the components cost-effective and predictable.
In software and computing, I can only think of the low-level networking standard that remain stable. And even that has to be reinvented somewhat for each OS or each nee language.
Everything else seems to be reinvented or rewritten, and then versioned.
Imagine having to upgrade your nuts and bolts in your car to v3.01 or lose support?
david927
I'm not arguing against component-based architectures. I'm saying we're over-engineering, and it shows. Even toasters are less maintainable than they used to be.
Ingredients in the cookies? Yes. 100? No.
MontyCarloHall
>That TI-99/4A still boots because it was designed by people who understood every component, every circuit, every line of code. It works because it was built to work, not to generate quarterly revenue or collect user data or enable some elaborate software-as-a-service business model.
The methods and algorithms powering advances in modern science, medicine, communications, entertainment, etc. would be impossible to develop, much less run, on something so rudimentary as a TI-99/4A. The applications we harness our technology for have become much more sophisticated, and so too must the technology stacks underpinning them, to the point that no single individual can understand everything. Take something as simple as real time video communication, something we take for granted today. There is no single person in the world who deeply understands every single aspect, from the semiconductor engineering involved in the manufacture of display and image sensors, to the electronics engineering behind the communication to/from the display/sensor, to the signal processing and compression algorithms used to encode the video, to the network protocols used to actually transmit the video, to the operating system kernel's scheduler capable of performing at sufficiently low-latency to run the videochat app.
By analogy, one can understand and construct every component of a mud hut or log cabin, but no single person is capable of understanding, much less constructing, every single component of a modern skyscraper.
alganet
You're misdirecting.
He's criticizing the act of _not building_ on previous learnings. _It's in the damn title_.
Repeating mistakes from the past leads to a slow down in such advancements.
This has nothing to do with learning everything by yourself (which, by the way, is a worthy goal and every single person that tries knows by heart that it cannot be done, it's not about doing it).
> They can deploy applications to Kubernetes clusters but couldn’t design a simple op-amp circuit
And the ones who can design a op-amp circuit can't manufacture the laminate their circuit is going to be printed on. And the ones who know how to manufacture the laminate probably doesn't know how to refine or synthesize the material from the minerals. And probably none of them knows how to grow and fertilize the crop to feed themselves.
No one knows everything. Collaboration has been how we manage complexity since we were biologically a different species than H. sapiens.