The Lost Humility of Software Engineering

How the separation between abstraction and implementation changed the culture of engineering.

Written by Reichi Kirihoshi (min.k) · mncc.info

Listen to how software gets discussed now. Cloud-native. Serverless. Zero-trust. Agentic. Self-healing. They are good words; each points at something real. But increasingly the talk floats free of the things underneath it — which machine actually runs this, which path the packets take, what fails at three in the morning, who gets paged, what it costs to operate once the demo is over. The vocabulary has become a place you can live in without ever going downstairs.

I want to call that failure mode the abstraction-layer stroll: moving fluently across abstractions without ever descending to the implementation that would confirm or refute them. Abstraction itself is not the problem — it is one of engineering's great achievements. The problem is the stroll, where the round trip between abstraction and implementation never happens and a whole day's work can be completed in the upper layer alone.

Here is the question this essay circles. Earlier generations of engineers seem to have kept descending — to have distrusted their own abstractions enough to go and check. Why? My answer, offered as a hypothesis and not a proven fact, is that an older engineering culture imposed a kind of humility. It made engineers doubt their own work in a way that kept them honest, and that humility is quietly being lost.

One note before I start. This piece mixes three kinds of claim, and they carry very different weight: things the record can confirm, support lines borrowed from existing research, and my own interpretation. The idea at the center — that engineering humility once worked as a safeguard, and that its erosion is what the abstraction-layer stroll really signals — is the last kind. I flag which is which as I go. Japan, where I work, appears as a case study, not as the whole story.

1. Where the discipline came from

Software engineering has an unusually candid origin story. The term was popularized at a 1968 NATO conference convened around what its participants openly called a "software crisis": large systems were late, over budget, and unreliable, and the field reached for the word engineering almost aspirationally, as something it did not yet possess.^[1] Read that backwards and it tells you something. Software did not begin, as mechanical design did, with a mature body of method. It had to borrow its seriousness.

Where did the early people come from, then? Japan is a clean case to look at, because its records are explicit. Information science was not an independent discipline there until surprisingly late. Departments of "information engineering" were first grafted onto existing engineering faculties — Shizuoka University added one in 1971, alongside mechanical, electrical, and chemical engineering.^[2] Independent graduate schools of information science came later still: Tohoku's in 1993, the University of Tokyo's in 2001.^[3] Before those doors existed, people arrived from elsewhere — electrical engineering, communications, physics. One of Japan's computing pioneers, Hideo Aiso, came to early computer work by way of a degree in electrical engineering.^[4]

I want to be careful here, because a case study is easy to over-read. What Japan's record supports is modest: that information technology was, for a while, a field people entered after passing through some older, more physical branch of engineering or science. It does not show that any single origin — mechanical, say — dominated. The honest claim is about the entry point, not about a majority.

2. What the physical world does to you

Why should the entry point matter? Because some kinds of engineering argue back.

Mechanical design is the clearest example, and it carried real institutional weight. Japan's mechanical engineering society was founded in 1897 and remains one of the country's largest technical bodies; by its own account, the man who proposed founding it had been struck, during a stay in England, that belonging to a society of mechanical engineers commanded a respect rivaling a university degree.^[5] That prestige was not arbitrary. Mechanical design is disciplined by a world that pushes back. You choose dimensions, materials, safety factors; you anticipate failure modes; you guarantee that the thing can actually be manufactured and maintained. Get it wrong and it breaks, or it never gets built, or someone is hurt. You cannot talk gravity out of its position.

Here is where I will state the hypothesis plainly, and own it as mine. Passing through a physical discipline like that, I think, imposes intellectual humility on an engineer — a trained reluctance to trust your own model until reality has confirmed it. The engineers who came to software this way were, I suspect, quietly unsure whether what they were doing even counted as "design" in the sense they had been taught. That unsureness was not weakness. It was a habit of checking.

Notice the reframing, because it matters. This is not an inferiority complex in any clinical sense; it is closer to reverence — the posture of someone humbled by physical constraint, carrying that posture into a new domain. The useful word is humility, not inferiority.

3. Humility as a safeguard

So here is the claim at the center of this essay, stated as a hypothesis rather than a finding: the humility those engineers carried functioned as a safeguard. Because they did not fully trust their own abstractions, certain questions stayed live. Is this actually buildable? What happens when it breaks? Who maintains it? Does it still hold once you include operation, and not only design? That standing doubt kept the work grounded. It resisted the mystification of new technology, and it pulled abstractions back down to something you could touch.

I cannot prove this, and I will not pretend the literature does. But there are support lines worth naming, precisely as support and not as proof. Research on high-reliability organizations describes cultures that stay obsessively attentive to small signs of failure, resist premature simplification, and treat their own knowledge as incomplete — and argues that such cultures are safer for it.^[6] Work in psychology finds that intellectual humility, the willingness to hold that you might be wrong, is associated with more accurate judgment and less overconfidence.^[7] Neither study is about engineers and mechanical design; neither validates my historical story. What they do is make it plausible that a culture of not-quite-trusting-yourself can be a genuine asset rather than a defect.

Put the contrast in one line, knowing it is rhetoric and not evidence: the old humility could act as a brake; today's confidence can act as an accelerator with no brake attached.

4. Abstraction was the destination, not the door

For engineers who arrived this way, abstraction was something earned, not something given. They knew wiring, power, storage, failure, and maintenance first, and reached for abstraction afterward, as a way of managing all that mess. The order ran from the physical to the abstract — and abstraction, learned in that order, is a tool for handling reality, not for forgetting it. Someone who learned it that way tends to look at a clean, abstracted service and still ask, almost reflexively: what is running underneath, what does it depend on, where does it break, who fixes it.

This is not a claim that anyone entering from the top is less capable — that would be both unfair and wrong. It is a claim about starting points. And the instinct to descend all the way down is not mere nostalgia: modern systems-engineering standards define the lifecycle of a system to include operation, support, and retirement, not only the moment of design.^[8] Going downstairs is written into the discipline's own definition of the job.

5. The doors changed — and the floor went invisible

Two things then changed the shape of the work.

First, the entry point moved. As information science became its own discipline, it became possible — normal, even — to enter computing directly from software, the web, and the cloud, without ever passing through a physical layer. That is a natural and mostly good development. But it changed what people meet first: API and service and framework, rather than machine and wire and failure.

Second, the floor went invisible. Cloud computing is often described, loosely, as making servers "disappear." It does not. By its standard definition, the cloud is a pooling and abstraction of physical resources reached over a network — the physics is still there, merely out of view.^[9] And it still bites: some cloud outages trace back to ordinary physical failures of power, backup batteries, and cooling.^[10] What changed is visibility, not existence — and to someone who entered from the abstract layer, an invisible floor is very close to a floor that was never there.

Generative AI raises the building another storey. It genuinely speeds work up; the productivity gains are real and measured.^[11] But the same tools can lead people to write less secure code while feeling more confident that it is fine,^[12] and a meaningful share of AI-generated code has been found to contain vulnerabilities.^[13] None of this is new in kind: human-factors research has long documented automation bias, our tendency to over-trust automated output and relax our own vigilance.^[14] Stack all of it together and you can raise a very tall structure while looking at neither the physics nor the implementation — a dream built on top of a dream, a sandcastle you keep extending with holograms.

6. Why the stroll cannot review

There is a practical cost to all this, and it shows up most clearly in review. A real review is the round trip: you carry an abstract requirement down into implementation, carry the implementation's constraints back up, and find the contradictions in between. It needs concrete questions. What failure does that redundancy actually survive? Can this be built with those permissions? Who is paged, and for how long, when it breaks? Keeping architecture and implementation consistent is a recognized, hard problem in software engineering, not a formality.^[15]

Someone confined to the upper layer can only return abstractions for abstractions: the approach is sound, the diagram looks reasonable, it follows best practice. That is not bad faith. Without the round trip, it is the only kind of review available. And it means the hardest and most valuable check — does this actually hold together? — quietly stops happening.

7. What was actually lost

It would be easy, and wrong, to end at "the old engineers knew hardware." That shrinks the point. What is being lost — and I would say being lost, not lost, because it is a tendency and not an accomplished fact — is not knowledge. It is a posture: the habit of doubting your own abstraction, of checking it against reality, of measuring a design by whether it can actually stand up, operation and maintenance included.

The engineers I have in mind did not fully trust the medium they worked in, and that mistrust made them careful. The asymmetry now is that computing and AI have become the prestige disciplines — the fields the physical world once humbled sit at the top of the status order — and the pressure to doubt oneself has weakened. That connects, loosely, to the humility research: overconfidence is where accuracy goes to die.^[6:1][7:1] Connects — not proves.

Conclusion

The remedy is not to go back. Nobody should have to route a career through elevators and wiring harnesses to become a good engineer, and the physical apprenticeship of the past was never evenly distributed anyway. The point is subtler. The humility that physical constraint used to impose now has to be cultivated, on purpose, because nothing in a cloud console or an AI assistant will impose it for you.

Concretely, that means rebuilding the round trip as a first-class skill: climbing from the physical to the abstract, then descending from the abstract back into the implementation, and treating that movement itself as the real work of design and review. It means re-institutionalizing a little structured self-doubt — leaving room, in how we build and how we review, to ask whether the thing actually holds. Call it engineering humility, or professional humility, or epistemic humility. Whatever the name, it used to come for free, handed over by a world that pushed back. Now it is ours to keep alive deliberately — or to lose on a pleasant, frictionless stroll through the upper layers.

☕️ If this was worth your time, you can buy me a coffee.
https://buymeacoffee.com/mink_obs

Written by Reichi Kirihoshi (min.k) · mncc.info / Research & structural support: Claude Opus 4.8, ChatGPT, Perplexity / AI-assisted · Structure observation

Notes

日本語読者向け

この記事は、過去に執筆した日本のIT技術者論に関する記事を出発点にしながら、視点を「技術者文化論」へ引き上げた英語版である。中心にあるのは、機械設計のような物理的な工学が初期のソフトウェア技術者に課した「知的謙虚さ（intellectual / epistemic humility）」が、自分の抽象を鵜呑みにしないための安全装置として働いていたのではないか、という筆者の仮説だ。ここでは「劣等感」ではなく、工学への畏敬に近いものとして humility を扱っている。情報系教育の独立、クラウド、AIによって実装や物理の層が見えなくなるにつれ、その謙虚さは「抽象層さんぽ」——抽象と実装を往復しないまま上の層だけを歩く態度——へと痩せていく。高信頼性組織論や知的謙虚さの研究は、証明ではなく理論的な補助線として用いた。日本はあくまでケーススタディであり、結論は懐古ではなく、かつて物理的制約が「課して」くれた謙虚さを、これからは意図的に「育て直す」べきだ、という提案である。