# We Are Not Special Part two of Hillel Wayne's crossover project, published January 2021. The method behind all three essays is interviews with people who worked as traditional engineers — mechanical, electrical, civil, chemical, chip design — and then moved into software, which makes them the only people with a first-hand comparison rather than a stereotype. Part one asked whether software people are really engineers. This one asks the opposite question: whether software is meaningfully different from the rest of engineering. The answer is that it is different in three specific ways and identical in most of the ways people claim. [[artisanal-programmer-label]] borrows the project's finding that many people who write software aren't doing software engineering, and maps it onto the AI split, a mapping the interviews themselves predate. He opens with an epigraph pair that does the whole argument in two lines. "No one thinks about moving the starting or ending point of the bridge midway through construction," from Justin Cave. Then, from an anonymous interviewee: "I had to move a bridge." ## Hazelnut shells The first anecdote is Carl, a mechanical verification engineer who tested how much oil rigs vibrate. People live on rigs for long stretches, and past a certain threshold they cannot sleep; rigs are designed to stay under it, but design and final version diverge. While explaining how oil gets found, Carl mentioned additives pumped down the hole — "like acid or hazelnut shells" — and Wayne stopped him. An oil reservoir is not a balloon full of oil, it's a porous structure in rock. Drilling in, you can hit a sudden loss of pressure in the pipe, and you cannot immediately tell whether you have broken into the open ocean or hit a local void. Guessing wrong and drilling into a high-pressure area destroys the pipe. Pumping in hazelnut shells gradually fills small voids, which both tests whether you're still inside the structure and equalizes the pressure if you are. Oil companies, Carl said, are the biggest purchasers of hazelnut shells in Norway. The anecdote earns its place because it is exactly the kind of thing an outsider's model of an industry does not contain, which is Wayne's charge against software's model of everything else. ## Why the differences get claimed Wayne separates two families of cliché. The "what makes an engineer" clichés, no licenses and not rigorous enough, work to marginalize software as less prestigious, and part one dealt with them. The "fundamental differences" clichés run the other way: they aren't trying to delegitimize software, they're trying to make it *special*, something the narrow lens of engineering cannot capture. He reads that as a defense mechanism. If software is genuinely different from trad, then it's fine that we aren't engineers. We don't plan upfront, but that's because requirements change faster here. We aren't applying engineering because we shouldn't be. His example is the NoEstimates movement: estimates are difficult in software, supposedly unlike everywhere else, so do away with them. Before testing the claims he flags the fallacy underneath all of them. "Trad" is an umbrella over disciplines that differ enormously from each other, and most arguments either stop at "software vs engineering" or quietly substitute civil engineering for the whole category — usually the bridges-and-buildings part of civil engineering, which is where the stereotypes come from. Jen, a civil engineer, told him she finds herself explaining that the field covers anything you need to build the city. The five claimed universal differences he settled on after a few interviews: trad is best done Waterfall while software is best done Agile; trad is predictable and software isn't; engineering is about manufacture while code is design; trad is more rigorous; software moves faster. ## Waterfall and Agile The origin story is that Winston Royce invented Waterfall in 1970 to mimic how real engineers build buildings, that it demands strict phase ordering, that this fails for software where requirements change and customers don't know what they want, and that the 2001 Agile Manifesto rejected it. Wayne calls this more fiction than fact. Waterfall was never as strict as remembered, and it was not ubiquitous — most developers in the 70s and 80s worked ad hoc or under one of the many incremental models in fashion, like the Spiral Model and the V-Model. Agile was a natural consequence of existing trends rather than a break. The core claim fails on its own terms too. Traditional engineers do more upfront design and spend more time in dedicated testing, but that follows from economics rather than dogma: when iterations are long and expensive, planning them out pays. Mike, an electrical engineer, on circuit boards: "it's pretty common for things not to work the first time. You have to do it again, and you have to send it out to the factory and do it again. You know it costs you another however many £1000 and another two weeks on the schedule." That is iteration with a price tag attached, not a phase gate. Agile-shaped practice turns up everywhere once you look. New Austrian Tunneling builds tunnels through iterative development with room for improvisation. The *Handbook of Industrial Engineering* emphasises cross-collaboration and rapid client feedback. Even civil engineering, the most Waterfall-looking of the lot, drifts toward adaptation once construction starts, because on-the-ground problems require open communication. Wayne also notes that the design/implementation boundary isn't where software people assume. When a civil engineer builds a scale model, is that design or implementation? When an automotive engineer makes a full clay replica of a car to test aesthetics and aerodynamics? ## Predictability The section's first quote is not a sentence. It is "*Laughter*", attributed to Dawn, Matt, Steve, Mike, Mat, and Another Matt. Wayne's diagnosis is that we see the results of the engineering process rather than the process itself. Not the friction, the overruns, or the delay because someone built a wall an inch to the left or a critical supplier went out of business. Assuming software is uniquely unpredictable is, in his words, a special kind of arrogance. The tooling-churn version of the argument gets a direct counterexample from Steve, a chip designer: "In the environment of software world, people are thinking 'what's the new JavaScript bundler of the month.' In the hardware world, it's 'what can the silicon fab people do for us this month.' If the foundry has new machinery to create chips, your plans change. Not as fast as libraries do, but still pretty fast." Less churn is not no churn, and churn is only one source of unpredictability among many. Territory claims changing mid-construction. Hardened procedures failing suddenly and permanently. New discoveries well into development. Someone starting a bridge foundation and finding that *this particular soil* freezes in a way that makes it liquefy too much in an earthquake, and going back to the drawing board. ## "The code is the design" Nick Coghlan gave Wayne the strongest version of this one, and his background is why it carries weight: core CPython developer, and before that a systems integration engineer at Boeing, coordinating separate teams building an airplane, an air traffic control system, and an antenna array so their interfaces would fit together. He called it "the diplomatic style of system architecture," and he saw software-is-design as the real difference between that job and his current one. He also placed the slogan historically — it was a reaction against the people who believed that building a beautiful UML model and autogenerating the code from it would make everything fine. Others disagreed flatly. One chip designer said it was all design, from the first CPU schematics to the chips coming out of the foundry; construction was the easy part, since you hand the design to a foundry and get chips back. Except the chips come back flawed, which means the design changes. Mechanical engineers felt this strongly, and Mike had a word for it — "fettling", tweaking the design to accommodate the slight imperfections of the construction process. Every construction changes the design, which changes the construction. Wayne adds a second problem: "design" is not well specified. Architectural overview, formal specification, detailed blueprints? Bridge plans have many layers of fractal detail. And if the code is the design, what is the formal specification of the code? The vault's nearest modern answer is [[specsmaxxing]] and [[acceptance-criteria-ids]], where numbered acceptance criteria act as the layer above the code that the code refers back to. The deeper answer is [[programming-as-theory-building]]: Naur's claim that the real product is the team's shared mental model and that code, docs, and tests are artifacts serving it, which reframes the whole design-versus-construction question as a wrong split. ## Rigor Mat, on the claim that trad engineering is more careful: "There's like a 1,000,000 million times more checks and balances in software than in traditional engineering. \[…] Whenever someone's tweeting about, like Excel horror stories \*laughter* I have amazing Excel horror stories \[…] there's days that I am shocked skyscrapers don't fall over daily and planes don't crash." Wayne makes two moves here. First, some of software's lower rigor is a rational tradeoff rather than a cultural failing, and Nick explained it as a difference in validating assumptions: "you reach a point with the easiest way to check if your assumption is right is to just go in and do it." Cheap empiricism is itself a source of rigor, available to software in a way it isn't to a field where the experiment costs two weeks and £1000. Second, the claim is usually smuggled in as a statement about outputs, namely that trad products are more coherent and less slapdash. Wayne found the opposite in interviews: critical information stored in Excel sheets and old filing cabinets, going obsolete and corrupting, and engineers who would kill for the automated testing software treats as table stakes. Software keeps better records and uses more comprehensive verification. Carl's summary of what rigor looks like in practice: "You can **always** add more brackets." ## The three real differences ### Consistency Nathan: "Software is entirely synthesized. It's bounded entirely by logic. It doesn't wear out like a spring, right? It just does what it's supposed to do. The only thing that can actually go wrong is the specifications." Give someone a sorting function and they expect it to sort — not to sort a non-pathological list 95% of the time, which would be absurd. Physical materials do not work this way. A resistor's color bands encode a nominal resistance plus a tolerance band; gold means ±5%, so a batch of nominally 5600-ohm resistors contains parts at 5320 and parts at 5880, and the only way to know which is which is to test each one. That is before wear, before temperature. Wayne's other favorite example is Fastenal, which makes screws and maintains engineering pages warning you not to put stainless steel screws in an aluminum plate. "Software engineering has nothing on that." ### Velocity Matt, a chemical engineer: "The code is the spec for how the hardware should be running. In traditional engineering, we would have to do all that same work to share the spec, but then we have to wait and, like, let the fab or the machine shop finish building the damn thing. And then we'd have to sit there and install it either ourselves or hire somebody. And then we'd have to run testing on it for several weeks to see if it worked or not." Several engineers described changes carrying a quantifiable price — every adjustment was $5000 out of the budget. Wayne can change code and run the tests in seconds. The closest analogue he found anywhere was chemical engineering, where Raja would come in each morning and look at what had gone wrong overnight; a one-minute turnaround is unheard of even in the fastest non-software field. This is the difference with a dark side, and Wayne is explicit about it. Because software iterates faster, other disciplines lean on it to compensate for physical problems. Mike: "The software engineer is being squeezed by the rest of the team. They're usually asked to save everyone's bacon. If something is not quite working in the electronics or mechanics, often you can work around it with a software kludge." The 737 MAX is the case where that killed people. Two crashes in 2019 killed over 300, and investigation pinned them on a bug in MCAS, an automated flight control system — but MCAS existed only because Boeing discovered aerodynamic profile problems late and chose to answer a trad problem with a software patch. The same asymmetry is what [[slow-software-high-latency]] argues for reversing: now that build time no longer tracks importance, critical infrastructure needs friction added back deliberately. ### Constraints Steve, on negotiating a chip's timing budget: "They have a \[chip] time budget, you have a time budget, you say 'I can't quite make it. Do you have a little slop there? Can I get a fraction of a nanosecond?'" Every interview carried an undercurrent of hard physical limits — light enough, strong enough, cool enough, some known quantity to maximize or minimize. Software has constraints too: fitting in an embedded device's memory, responding in exactly 10 cycles, staying under an API rate limit. But software constraints are usually soft. Exceeding them is bad and gets worse the further you go, and you can fudge the line in exchange for development speed or a simpler algorithm. A box that's too wide does not fit through the door, and no amount of tradeoff reasoning changes that. Carl's team once had to install a screw conveyor in an oil rig and found it a couple of inches too tall for the room. They couldn't shrink the equipment and couldn't raise the ceiling with four floors above it, so they cut a hole in the ceiling, put the equipment through, and built a box around the hole on the floor above so nobody would trip. That hole is now permanently part of the rig's structure and has to be accommodated by every future change forever. Which produces the fourth difference, the one Wayne draws out rather than lists: software engineers can undo their kludges and trad engineers cannot. [[disposable-code]] is the current version of that advantage, where code cheap enough to throw away changes which projects are worth starting at all. ## Different is not special Every field has unique challenges. Mechanical and electrical engineers don't face software's security problems; none of the three deal with weather the way civil engineers must, or with what chemical engineering involves. Software is no different in having its own set, which is precisely the point — having a unique set is the normal condition. Underneath, Wayne argues, the similarities dominate. Every field values upfront abstract thinking, tidy work, and a good kludge in the right place. Every field faces shifting requirements and unknown unknowns. And every field is siloed from every other: software people know as little about mechanical engineering as chemical engineers do, and during the interviews his subjects kept asking *him* what the other fields were like, because nobody gets a chance to leave their bubble. He treats the conclusion as good news. If software isn't special, there's a lot to learn from other fields and a lot they can learn from software, which is what part three, *What Engineering Can Teach (and Learn from) Us*, takes up. The essay lands as a direct challenge to the [[fred-brooks|No Silver Bullet]] tradition of arguing from software's essential properties. Brooks grounded software's difficulty in complexity, conformity, changeability, and invisibility as intrinsic to the medium; Wayne's interviews suggest that at least changeability and conformity are ordinary engineering conditions rather than software's inheritance, and that the parts that really are intrinsic are the three he isolates. Consistency, velocity, and constraint hardness are properties of the material, not of the profession's maturity or self-image.