> 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.
> 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
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.
If you start designing hardware for AI, together with AI designed to run just on that hardware, and tie those design cycles together, you'll get a design by commitee. It is very likely that requirements will make an overall bad hardware (but slightly better for AI), and an overall bad AI (but slightly better in some hardware).
Eventually, these shortcuts lead to huge commitees. Sometimes they're not even formally defined.
The screw company should make good screws, not good screws for a specific desk lamp model. A good designer then _chooses_ to use those screws _because they are good_, not because they can make specific design requirements to the screw company.
My left femur is a good femur for my specific height and species. It would be a lot worse if I had to use the same femur as the pit bull next door. Why are desk lamps different? I conjecture that it's only because of the cognitive limitations of the designers.
The desk lamp can be designed around common parts to reduce the total number of unique parts in the world, so everything is reusable, replaceable, manufacturable in larger quantities so there's more resources to optimize the process, etc.
The problem is that you used vague sophist dialogue that could turn either way. You could say that T G A C are the designed parts, or any kind of bullshit honestly.
It's bad communication. You need to follow up the vague analogies with real examples to make a message stick. If you don't, people have no idea what you are saying.
I can assure you that both my leg and desk lamps are perfectly real examples. There is a common kind of desk lamp that is even fairly mechanically similar to a human leg, with a knee , tension springs, and a ball-and-socket joint to permit free repositioning in multiple degrees of freedom, and about the same size. But the different design processes involved have resulted in very different designs, and a major reason for that is precisely the use of standardized parts in the desk lamp, but not in my leg, which results precisely from the kind of specialization we have been talking about. I don't see how much less vague I could have been. Are you being sarcastic?
A human leg isn't designed to be repaired from the outside, it doesn't need replacement parts, it doesn't need external maintenance. It's designed around the maintenance and repair procedures of the human body which are able to fix it in situ and produce new parts on the fly. That allows it to have more freedom of design than a mechanical part that needs to be made from standardized parts in order to be serviced and manufactured.
The limitation is not cognitive, it's a matter of efficiency. We could, if we wanted to, make a lamp with all custom parts with the maximum efficiency possible in the design, but those efficiency gains would be at the cost of extremely difficult manufacturing. It's a tradeoff that the human body can make because it needs to produce only one (or two) legs, while us humans mass manufacture the stuff we make.
It sounds like you're more in favor of unique parts made to fit specific applications, wheras I prefer the more modern style of mostly generic parts with mostly only the case design and the code being unique
It's more nuanced than that. Unique parts made to fit specific applications can clearly perform better, but that doesn't mean I'm in favor of them in all contexts. Rather, I'm observing that the reason we don't use them for things like desk lamps, instead using mostly generic parts, is because of our cognitive limitations, which we cope with through specialization and generic parts with loosely-coupled, independent designs. This is a form of "dividing and specializing design", which is what alganet was saying people shouldn't do.
I am not in favor of ignoring those cognitive limitations. That wouldn't make the limitations go away; it would only keep us from taking measures to cope with them, such as dividing and specializing design into modular generic parts.
On the contrary, my comment was all about the difference! I see my body as far better designed than any desk lamp I have ever heard of. So I am puzzled as to why you count the characteristics that give rise to desk lamps' deficiencies as advantages on the side of the desk lamp.
The division of design doesn't stop because some of the pieces can be bought at a store.
The lamp design clearly was divided -- the final designer did not design the screws, lightbulb, wiring, and perhaps many other components. Someone had to design those components that were then combined creatively into a lamp.
Dividing design into components that can be effectively reused is tricky, but it remains essential.
Last week I was learning about Itanium. It was a processor designed specifically for HP. Its goal was to replace both x86 and PowerPC.
HP would design the new systems to run on Itanium, and Intel would design the chip.
There was an attempt at specializing design here, with both companies running on design constraints from another. They formed a design comittee.
This was like the screw company making screws _specifically_ for one kind of desk lamp. It's division and specialization of design.
A natural specialization (one company gets very good at designing some stuff) is not divided, or orchestrated by a central authority.
In manufacture, it's the other way around. If you already have a good design, the more divisions alongside a main central figure, the better. You can get tighter tolerances, timing benefits, etc.
My argument is that these aspects are not transferrable from one concept to another. Design is different from manufacturing, and it gets worse if we try to apply the optimizations we often do with manufacturing to it.
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.
> 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.
Toronto Metropolitan University (formerly Ryerson University). I only had a 90% in HS and didn't get into good CS/ECE programs (thanks grade inflation, my marks went up in uni). If you're not in Waterloo/UBC/UofT the quality drops drastically.
We don't even have an automatic grading system for code. You have to go in-person to a lab and demonstrate your code "working" while the TA asks questions.
It's actually a requirement that you put all of your code into a PDF and submit it. I have LaTeX macros that do it for me but most people literally attach 50 screenshots.
I don't see this getting better. CompArch is a required course (COE608) but the assignments are too hard so the school just gives out prewritten code to everyone. The hardest part is copying and pasting from the PDF and removing the smart quotes.
Also, the provided code is wrong. I found this out because I wrote everything from scratch and had to explain to the TA why my implementation of a shift instruction didn't match the correct one.
I think everyone involved views software as a cash grab.
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
I think you can teach this sort of class, in Python. Just using the basic syntax of Python, which is essentially pseudocode. The main danger, I think, is that it would involve doing lots of things in a non-pythonic way, which could confuse the students if they went on to write Python for real.
We do basic C, basic-medium Java, Python for signals analysis, and somewhat advanced design patterns. Tons of UML.
The misses remind me of technical debt vs shiny features. I wrote embedded assembly and did a bunch of labs on them. But due to time constraints and difficulty, I didn't go into much detail on interrupt-based programming. And our OS course focused more on rote memorization of concepts such as locks/mutexes/semaphores/deadlock avoidance algorithms/memory management.
But there's little detail on why I might use Linux syscalls over libc.
> 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.
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
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.
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.
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.
>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.
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.
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.
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.
No, unsustainable societies like the Lykov family or the Tasmanians were also often unspecialized. I suspect that specialization improves sustainability in general, at least up to a point. But it depends on how it's structured. The Khwarezmian empire had a high degree of specialization for the time, but one bad decision by the emperor made it unsustainable.
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.
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.
That's a tough row to hoe --- classic example of that is a pencil (see Thoreau and his family's history/business), though interestingly, there is a specialized tool now for making one (from components):
John Economaki's "Pencil Precision" from Bridge City Tool Works:
I have the preceding "Chopstick Master v2" and it is a delight to use (and probably if there was a suitable set of instructions for collecting the materials for making a pencil lead and baking them, I'd probably have the successor).
There are extraordinary people doing extraordinary things all around you. Aiming for these things is important, and we need those kinds of people with ambitious learning goals.
Because specialization is vastly more efficient, productive, and I don't have an interest in cutting and laminating my own circuit boards. I can pay a tiny (relative to the alternative investment of DIY) to get multilayer boards in a day.
Before, you said people _can't_ (in general, anyone that knows how to code cannot possibly learn how circuits work).
Now, you're saying that _you don't want to learn_. That's on you, buddy. Don't project your insecurities on the whole IT field. People can, and will, learn across many layers of abstraction.
That is because you are replying to two different people.
People can learn across layers of abstraction, but specialisation is generally a good thing and creates wealth, a Scottish guy wrote a good book on it.
I don't know what raincole's meaning was but can't there doesn't have to be a permanent inability just a current one, IMO backed up by the next sentence about the people making circuit boards not knowing how to refine the raw materials into those that they use. That's what I took it as.
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.