Project</th>	Lines of Code</th>	Tokens</th></tr></thead>
SQLite</td>	~150K</td>	~2M</td></tr>
Linux kernel</td>	~40M</td>	~500M</td></tr> </tbody></table> In this sense, what's good for humans is good for LLMs. If you're human and want to work on a large codebase, you have to be choosy about what to bring into your working memory. If you want to use an LLM to work on a large codebase, you have to be choosy what to bring into its context.</p> So that's why modules matter. But what is a module, exactly?</p> What is a module?</h2> In programming, modules take many physical forms: a function, class, shared library, program, or a group of programs, an HTTP endpoint, or yet other forms.</p> What makes any of these a module is:</p> It exposes an interface</em> that conceals the secrets of its implementation</em></li> It operates without using the secrets of other modules.</li> </ul> What makes a good module?</h2> A good module is deep</em>. Its interface is smaller than its implementation^{4</a></sup>. Reading its interface is a much lower cognitive burden than reading its implementation.</li>} The preconditions</em> of a good module are well-defined. It is clear what the module assumes to be true about the world in order to run.</li> The postconditions</em> of a good module are well-defined. It is clear what the module guarantees about its output and effects on the world.</li> A good module relies only the guarantees of other modules. Code that relies on facts that other code does not guarantee may work today but can break in the future.</li> The above facts make a module composable</em>. Module A depends on Module B, and Module B depends on Module C. Programs can be understood as fractal structures: even simple programs have a deep dependency tree</a>. My single page web app depends on my chosen web framework, which depends on the browser's JavaScript runtime and rendering engine, which depend on the operating system's system call APIs, which depend on device drivers, which depend on device firmware. Thankfully, my app doesn't have to know about TCP packet retry. All it knows is to call `fetch()</code> so I can watch` cat videos</a> in peace.</li> </ul> For modules with enough users, it's inevitable5</a></sup> that someone will eventually break modularity by depending on what happens to work right now (observable behavior) instead of what is guaranteed to work (contractual behavior). Don't do that.</p> See these references4</a></sup> 6</a></sup> for more detail and examples on what a module is.</p> What do modules have to do with LLMs?</h1> Program Correctness</h2> Modules let you and and LLMs reason about program correctness without thinking about the entire program. You or your LLM can change a part of the program, and as long as you don't break that module's public contract, the rest of the program will remain correct if it only depends on that contract</em>.</p> You can be confident that your changes don't break some other part of the program. This is a powerful capability. The payoff for strictness about contracts, preconditions, and postconditions is confidence to make changes</em>.</p> LLM Performance</h2> The chart below shows the well-known fact that LLMs as a rule perform worse as they ingest more data. If future LLMs perform better, the problem doesn't go away. The horizontal axis just gets longer.</p> </picture> LLM Performance vs Context Length </p> </div> Conversely, an LLM will perform better if you constrain how much information it ingests. The type signature of a function is usually smaller than the function's implementation. If your LLM has to look at the implementation of a function to determine how to use it, that will use more context.</p> Subagents</h2> Right now, subagents and agent orchestration are hot topics. Your main LLM agent, the orchestrator, hands off work to "subagents", each with an independent context. This conserves the context of the main agent, which improves task adhesion and alignment to your intentions.</p> You need something to hand off to the subagents. If your code is not modular, each subagent has to read more code to do its task. LLMs can do a pretty good job of making tool calls to e.g. grep</code> a codebase and pick out the relevant bits, but your design choices can make it easier or harder for them. Without modular code, tasks will take longer, incur greater token usage, and fill up contexts more quickly.</p> Moreover, you want each subagent to work independently. Without modularity, parallel agents can make conflicting changes to the same files.</p> Chats</h2> If you're copy-pasting code into an LLM chat window, a modular codebase will still help. In this case, you're playing the role of main agent. You have to curate what information the chat bot receives, so you're managing both your working memory and the LLM context.</p> Summary</h1> It's easy to make software that works right today. It's very hard to make software that keeps working in a changing environment</a>. You can do that by depending only on what your code's environment guarantees. That's modular thinking.</p> Look for words like interface, specification, contract, assumption, guarantee, precondition, postcondition, and invariant. Those are signals you're dealing with a module.</p> Modules are humanity's best hope to manage complex software.</p> References</h1> CC0 Pixnio</a></li> Code that Fits in Your Head</a></li> The Programmer's Brain</a></li> A Philosophy of Software Design (book)</a></li> Hyrum's Law</a></li> Modules Matter Most for the Masses</a></li> </ol> Don't believe "software never fails" 2026-01-02T00:00:00+00:00 The claim "software never fails" is cavalier and dangerous. It creates a mindset that itself leads to software failures.</em></p> On March 26, 2024, a container ship collided with one of the piers of the Francis Scott Key Bridge in Maryland. Within 30 seconds, the entire bridge had collapsed into the Patapsco River, killing six people1</a></sup>.</p> </picture> The collapsed Francis Scott Key Bridge </p> </div> I'm going to make a bold claim: the bridge didn't fail</em>.</p> That's right. Six people dead. $15M economic loss per day. The bridge didn't fail</em>.</p> After all, it did exactly what it was designed to do. The bridge was doomed the moment its blueprints were approved, before a single truss was machined, before a single pier was erected. From the moment of impact, its collapse was mechanically inevitable. A computer simulation could have easily predicted it.</p> How does my claim make you feel? How do you think the families of the dead would feel? They'd be ready to throw me off that bridge! Of course the bridge failed</em>. Look at it!</p> Savor your righteous indignation, because that is exactly what I felt when I read the post Software Never Fails</em>2</a></sup>.</p> It claims that:</p> The brief reason we can say software never fails is that software always does precisely what we told it to do. The outcome may be undesirable, and it may be unexpected, but the software itself never deviates from the instructions it was compiled into</em>.</p> </blockquote> The post offers a definition of failure:</p> A failure</em> is the event that occurs when a component first does what we designed it to, then something happens, and then the component no longer does what it was designed to do.</p> </blockquote> If we are to consistently apply this claim and definition, then the Francis Scott Key Bridge didn't fail. It did precisely what it was designed to do.</p> Software developers: Now imagine this kind of thinking applied to your codebase or to the medical device that keeps your grandmother alive. What could go wrong?</p> The failure of "software never fails"</h1> The syllogism presented in Software Never Fails</em> goes:</p> Premise 1</strong>: Failure means some component changed from working to non-working.</li> Premise 2</strong>: A program's compiled instructions never changes.</li> Conclusion</strong>: "Software is design-stuff. It doesn't fail ever."</li> </ol> Both premises are false, and so is the conclusion.</p> A faulty definition</h2> Premise 1 is false by its definition of failure.</p> The article cherry-picks a definition from hardware reliability engineering which says that failure is a state transition from working to non-working.</em> A capacitor dries out, and a bearing wears down. While this definition is suitable for hardware, it doesn't apply to programs. If a program "never deviates from the instructions it was compiled into", how can it transition? Software is definitionally excluded.</p> In When the Machine Metaphor Breaks Down</a>, I compared and contrasted software failures to hardware failures. I provided precise definitions of failure that apply to both:</p> Sins of commission</em>: The thing did something it was required not to.</li> Sins of omission</em>: The thing didn't do something it was required to.</li> Latent faults</em>: Bugs that are present but not causing observable failures.</li> Unmet expectations</em>: The user was surprised the thing did or didn't do something.</li> Compromised safety</em>: A hazard or loss occurred and the thing was involved, even if</em> it performed as required and expected.</li> </ul> I also showed that hardware and software fail for different causes</em>:</p> Hardware</em> fails as its internal physical condition deteriorates.</li> A program</em> fails as it environment changes, invalidating its assumptions and preconditions.</li> A codebase</em> fails as its design integrity dissolves and defect count rises.</li> </ul> Software is surprising</h2> Premise 2 is also false.</p> The claim "software never changes" wants us to to believe that programs are deterministic</em>, and if deterministic, then predictable, and therefore incapable of surprising us with failure.</p> note </div> note</strong></span> </div> Deterministic</em> means the same inputs produce the same outputs.</p> </div> </div> But programs are effectively nondeterministic. Yes, it's narrowly correct that compiled bytecode doesn't spontaneously mutate, but the argument conflates instructions</em> with execution</em>. A program's behavior depends not only on its bytecode but on its entire input space</em>. Proving a program correct requires proving it correct for all possible inputs and states</em>. As Dijkstra wrote, tests can show the presence of bugs, but never show their absence.</p> The dangers of believing "software never fails"</h1> Danger: Design and implementation conflated</h2> In building architecture, the distinction between design and construction is clear. Design is clay models and blueprints. Construction is pouring concrete and milling steel. Many structural failures happened because the construction did not follow the design^{3</a></sup>.</p>} Software also has distinct design and implementation activities. Sometime this is easy to see: it's common industry practice for a software architect to hand over a completed design specification to another implementation team, perhaps even an offshore one. The distinction is harder to observe if the same person does the designing and the implementing.</p> When the Therac-25 radiation therapy machine killed patients in the 1980s, investigators found that the software implementation</em> failed to properly sequence safety interlocks that the design</em> had specified. The design was sound, but the implementation was not. If we say "software is pure design," we have no vocabulary to disambiguate these failure modes, and we have no framework for preventing them.</p> Fix: Remember Verification and Validation</h3> Implementation errors are mitigated with verification</em>, i.e. asking the question, "did we build the thing correctly?" Design errors are mitigated with validation</em>, i.e. asking "are we building the correct thing?"</p> In A Design is a Mold for Code</a>, I show with examples the distinction between design and code.</p> Danger: Presbyopic causal chains</h2> The benevolent intent of the phrase "software never fails" is to encourage us to look beyond proximal causes of failure and seek distal causes, but it goes too far. A high-quality report on a commercial airliner crash will include both: the plane had a problem, and</em> a long causal chain of lax training, spotty maintenance, regulatory capture, and eroded safety culture from the very top allowed the problem to cascade into a catastrophe.4</a></sup>.</p> Presbyopia</em> is the inability of the eye to focus clearly on close objects5</a></sup>, and I'm concerned that people who believe "software never fails" will look for distant causes of failure while allowing the immediate ones to blur into invisibility.</p> What is a causal chain? Many of us have had or heard a conversation with a young child that went something like this:</p> Child: "Why can't I play on the grass?"</li> You: "Because it's wet, sweetie"</li> "Why?"</li> "Because I turned the valve on."</li> "Why?"</li> "Because the grass is turning brown"</li> "Why?"</li> "Because we live in New Mexico"</li> "Why?"</li> "Because your great-grandfather moved here in the '40s"</li> "Why?"</li> "Because the Wright Brothers invented the airplane. This made the Japanese attack on Pearl Harbor possible, which brought the USA into World War 2, which resulted in the founding of Los Alamos in 1943."</li> </ul> As you can see, the more removed a cause is from its effect, the less plausible its association and the less actionable any mitigation or prevention</strong>. A proximal cause to my grass being wet is I turned the valve on</em>. A distal cause is the Wright Brothers invented the airplane</em>. Removing the middle links from the chain of causality reveals the absurdity: "You can't play outside because airplanes exist."</p> If we believe a claim like "software never fails", we sever the proximal links in the causal chain. We'll cast a wide net looking for monsters in other castles but not the ones under our beds.</p> Fix: The 4-part filter for relevant causes</h3> Use this framework to discover relevant distal causes of failure without ignoring proximal causes. When engineers analyze why a failure happened or could happen, they privilege causes that:</p> are proximal</strong>, physically or temporally. My hand turned the valve, and a few seconds later the grass got wet. The Pearl Harbor attack and invention of the airplane happened long ago and far away.</li> exhibit agency</strong>. I chose</em> to turn the valve. I didn't choose where to found Los Alamos.</li> are controllable</strong>. Turning a valve is an event I can control (separately from choosing to). There's no action I can take about historical wars.</li> are normal and expected</strong>. Turning a valve is a common event. Wars aren't.</li> </ol> Danger: Latent defects ignored</h2> Bad metaphors breed bad decisions. What might actually happens if a software team internalizes the idea that "software never fails"?</p> If a team thinks software never fails, they might not allow themselves to believe their software could contain latent defects. They might think, "It works today, so it will always work." In their false confidence, they might skip testing, breeze through code review, dismiss bug reports, or skip error handling. This may let them ship quickly at first only to get bogged down fixing bugs later. In the meantime, hopefully those bugs don't cause harm to anyone.</p> Fix: Use better metaphors</h3> In It's Not Tech Debt. It's Tech Risk</a>, I show that the metaphors we use shape how seriously we take software problems.</p> Danger: Eroded alignment with nonexperts</h2> The phrase "software never fails" communicates the wrong thing to non-practitioners. When a politician or mid-level manager hears "X never fails", they hear, "We never have to think about that." They don't share your nuanced understanding. This mindset could lead to poor business decisions, for example when leadership says "ship it" or downsizes the QA team. It could also lead to public harm when an elected or appointed official makes an misguided public policy decision.</p> Fix: Use different words</h3> A professional structural engineer would never say "bridges never fail". Instead of propagating incorrect absolute statements like "software never fails", let your word choices build, not erode, alignment between you and decision makers. For guidance on translating technical risks into terms leadership will prioritize, see my post Tech Risk is Business Risk</a>.</p> What to do instead</h1> Change your Mindset</h2> When analyzing software failures:</p> Use precise definitions of failure and definitions appropriate for software.</li> Distinguish between design and implementation. Remember validation and verification.</li> Use my 4-part filter for relevant causes.</li> Use metaphors that discourage hubris and language that communicates the right things to leaders.</li> </ul> Concrete actions</h2> Pretend your next commit message or PR description will be printed on the front page of the New York Times</em></strong>. How will your word choices come across to your manager, CEO, elected government officials, or to the public?</li> In your next code review this week, identify one assumption</strong> about the environment that could become invalid. Are there places where the code assumes "this will always work"?</li> Bookmark this page.</strong> The next time a postmortem gets off track, share it.</li> Start a discussion</strong>. In e.g. Slack, Teams, or another collaboration tool, ask "how do we distinguish design errors from implementation errors?"</li> </ul> Summary</h1> Saying a program can't fail because its deployed bytecode doesn't change is like saying the Francis Scott Key Bridge didn't fail because its steel molecules obeyed the laws of physics. One might object, "Yo dawg, the bridge was destroyed by an external force, not internal failure", and this is exactly my point about software. Programs eventually experience external forces that their designers didn't anticipate. If we excuse the bridge because it wasn't designed to withstand a collision with a modern container ship, then we must equally excuse software that fails when its environment changes. The question is how designs can anticipate and accommodate these stresses</em>.</p> References</h1> Francis Scott Key Bridge Collapse</a></li> Software Never Fails</a></li> Hyatt Regency walkway collapse</a></li> Trial by Fire: The crash of Aeroflot flight 1492</a></li> Presbyopia</a></li> </ol> Related reading</h1> When the Machine Metaphor Breaks Down</a>. How software failures differ from hardware failures</li> A Design is a Mold for Code</a>. Why design precedes and shapes code, not the reverse</li> It's Not Tech Debt. It's Tech Risk.</a>. How the metaphors we use shape how seriously we take software problems</li> Tech Risk is Business Risk</a>. Translating technical risks into terms leadership will prioritize</li> It's Time to License Software Engineering</a>. Why society should train and recognize professional software engineers</li> </ul> When the Machine Metaphor Breaks Down 2025-12-11T00:00:00+00:00 While it's rare to see a sixty-year old car still running, COBOL is 65 years old and processes 95% of today's ATM transactions1</a></sup>. The world is full of critical infrastructure running on ancient software, so it's important to understand how software can fail.</em></p> Computer people have an old tradition of calling computers machines:</p> The ACM is the Association for Computing Machinery</em></li> Alan Turing's paper "Computing Machinery and Intelligence" introduced the Turing test</li> We all recognize phrases like "machine code", "machine learning", and "virtual machine".</li> </ul> Edsger Dijkstra was an influential computer scientist and highly active in the ACM, but he took issue with this organization's name. In 1988 he wrote2</a></sup> that computers represent a "radical novelty" and "sharp discontinuity" compared to anything before. Computers are not better typewriters.</p> It's human to try and understand new things in terms of things we already understand</a>, but programs are very different than machines. When we try to apply models of hardware failure to software, we risk not addressing software's unique failure modes.</p> How software and hardware fail differently</h1> Entropy spares nothing. A ball bearing wears out over time, and though a program never deteriorates, it can become obsolete in a changing world: just think of Adobe Flash or Java applets. Software developers are often asked keep old programs working, but even skillful and careful maintenance can make code messy and hard to understand.</p> Failure rates over time for hardware and software. Software looks very different than hardware. </p> </div> A model of hardware failure</h2> The blue line in the chart above looks like a bathtub, which is why it's called a bathtub curve3</a></sup>. It shows the lifespan of a typical machine. In the early days, a lot of devices experience "infant mortality". Perhaps a batch has a manufacturing defect or is damaged in transit. For those that survive, there is a long steady period of useful life. Then, the devices fail more frequently as their physical condition deteriorates.</p> For example, consider hard disks. Not solid state drives, but the old kind with spinning platters:</p> A hard disk drive. The top platter and actuator arm are visible. </p> </div> A hard disk drive has software running on it called "firmware", a term of art for software that interacts with hardware and will rarely be updated in the field. Hard disks also have lots of physical parts that can break: motors, bearings, actuator heads, and platters. If any of these fail, the disk has has failed and you can't read or write data. Most disk manufacturers publish a number called MTBF4</a></sup> which predicts about how long you can expect the disk to work. It's reasonable to expect a hard disk to survive continuous service for about three years. If you keep using it after that, you're on borrowed time: you're on the right side of the bathtub curve.</p> A model of software failure</h2> Looking back at the chart, the red line tells a story of software failure rates over time.</p> note </div> note</strong></span> </div> The term "software" is ambiguous. It can refer to a program or its source code. A program doesn't wear out or deteriorate, but its code can. Here, we're looking at an evolution of a program deployed over time from a changing codebase.</p> </div> </div> Stabilizing Phase</h3> Like hardware, there is an "infant mortality" phase. New programs tend to be buggy. The customers complain and the team scrambles to fix the bugs. Once the bugs are fixed, the program enters a stable phase with relatively few failures.</p> Maintenance Phase</h3> It continues that way until the boss walks in and says, "We need to add Feature X by Monday". The software team rushes to ship feature X by Monday. They succeed, but in their rush they add some new bugs. (This is why I avoid revision-zero software, e.g. I skipped macOS 15.7.0 and waited 14 days for 15.7.1). Customers complain, the team scrambles and fixes the bugs, and the waters calm down.</p> A while later, NIST announces a critical security vulnerability in one of the code's dependencies. The team scrambles to update or replace the dependency. In doing so, they create new bugs. Customers complain, the team scrambles to fix them, and the waters settle down again.</p> This happens many more times, and all the while something ominous is happening: the "floor" of defects is rising. The team can never get them down to how it was in the beginning before all of the new features and security patches. The code also doesn't feel as clean. It's messy and hard to understand. Its internal quality is deteriorating. A pile of quick fixes has obfuscated the elegance of the original design. Engineers leave, and new ones arrive who haven't internalized the design. Some people call all of this "tech debt", but tech risk</a> is a better metaphor.</p> End-of-life Phase</h3> Eventually maintenance becomes too expensive, and the program doesn't receive any more updates. It is announced deprecated or out-of-support and eventually removed from service.</p> Entropy affects software differently than hardware</h2> Notice that while hardware fails due to changes in its internal state, a program succumbs to entropy even if it doesn't change. Its shifting environment does the job. Maintaining software to accommodate its shifting environment postpones its demise but does not prevent it. As one of the greats in computing wrote:</p> Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.</p> </blockquote> -- Fred Brooks, The Mythical Man-Month, 1975</p> How software and hardware fail alike</h1> Software and hardware share some common notions of failure.</p> We've all seen this cartoon before. It takes outstanding communication to keep the spec, implementation, and user expectations in sync. This is exacerbated in situations where the user is not the customer or the designer is not the implementer. </p> </div> Failure to meet requirements</h2> A requirements-centric of failure view says that a system fails when it deviates from specified requirements</em>.</p> The IEEE defines failure as "the inability of a system or component to perform its required functions within specified performance requirements."5</a></sup> It distinguishes between a fault</em> (what most of us would call a bug</em> or defect</em>) and a failure</em>, which is the externally observable consequence.</li> If your mind has trouble distinguishing between fault and failure, consider latent faults</em>, which are bugs that are present in the software but not causing any observable failures. Latent faults often exist from the beginning but inspection (code review for software) and testing don't reveal them.</li> Examples for hardware: The O-rings of the Challenger solid rocket boosters had a latent fault</em> that caused them to deviate from their required</em> elasticity at low temperatures, resulting in the failure</em> of the seal to contain hot combustion gases.</li> The rivets on the Titanic had a latent fault</em>: they exceeded the required</em> maximum level of slag impurity. This made them brittle in the freezing North Atlantic waters. When ice contacted the hull plates, the rivets sheared rather than deformed, a failure</em> which caused ingress of seawater.</li> </ul> </li> </ul> </li> </ul> Failure to meet expectations</h2> A user-centric view of failure says that a system fails if it does does not meet user expectations</em>.</p> This broader view pits the end-user's expectations against the design and implementation.</li> This kind of failure is mitigated with early and iterative validation, by asking users to try it and give feedback.</li> For software: The design may have said "make the button green", and the button background may factually be #00FF00</code>, but if the user was expecting blue, the software has failed.</li> </ul> </li> For hardware: The original Segway was a well-functioning self-balancing vehicle. People expected</em> it to improve their urban transit. Instead, they got expensive scooters that attract ridicule. The device failed</em> to meet customer expectations. The Segway brand now emphasizes traditional scooters and e-bikes.</li> The Concorde jet met its spec: it achieved supersonic commercial flight. Passengers expected</em> fast, worldwide travel. Instead they got limited routes and extremely expensive fares. The jet failed</em> to find product-market fit. The last one was made in 1979.</li> </ul> </li> </ul> The processes for identifying these two kinds of failures are often called verification</strong> ("Did we built the thing right?") and validation</strong> ("Did we build the right thing?").</p> Failure to avoid hazard or loss</h2> There is a third, safety-centric view which says that a system fails if it contributes to a hazard or loss</em>.</p> This perspective is more common in safety-critical systems and public infrastructure.</li> For software: The Boeing 737 MAX MCAS software functioned as designed when the single angle of attack sensor failed: it thought the plane was in a nose-up attitude, so it commanded the nose to go down. While a requirement-centric view would say the software functioned as designed in this situation, nobody expects a plane to take an uncommanded nose dive. The failures are the two ground collisions which killed 346 people.</li> </ul> </li> For hardware: We say a bridge failed if it collapses, even if it's because a container ship collided into it, a load it was never required or expected to withstand.</li> The towers of the World Trade Center collapsed after airliners flew into them and the inferno weakened its metal structure. The doomed occupants may have hoped the buildings would stay up, but nobody expected</em> it, and no building code required</em> it. Still, nobody challenges a statement like, "the structure failed."</li> For space shuttle Challenger, the failure from this perspective is not the seal but the loss of crew and vehicle.</li> For Titanic, the failure from this perspective is not the rivets or hull plating but the hazard of the ship flooding with seawater and the resulting tragic loss of life.</li> </ul> </li> </ul> Summary</h1> Over time, software and hardware fail for different reasons:</p> Hardware</em> fails as its internal physical condition deteriorates.</li> A program</em> fails as it environment changes, invalidating its assumptions and preconditions.</li> A codebase</em> fails as its design integrity dissolves and defect count rises.</li> </ul> In an instant of time, software and hardware fail for the same reasons:</p> Sins of commission</em>: The system did something it was required not to.</li> Sins of omission</em>: The system didn't do something it was required to.</li> Unmet expectations</em>: The user was surprised the system did or didn't do something.</li> Compromised safety</em>: A hazard or loss occurred and the system was involved, even if</em> it performed as required and expected.</li> </ul> I plan to write more about software failures. See you soon.</p> References</h1> IBM: What is COBOL?</a></li> Dijkstra: On the cruelty of really teaching computing science</a></li> Wikipedia: Bathtub curve</a></li> Wikipedia: Mean Time Between Failures</a></li> IEEE 610.12 Standard Glossary of Software Engineering Terminology</a></li> </ol> Who wins in an Arms Race? 2025-10-28T00:00:00+00:00 In 2016, Nike shook up the sport of road running with its elite Vaporfly 4%</em> shoe. This shoe factually speeds up elite running times by 3-4% 1</a></sup>, which translates to 4-5 minutes over a 2 hour 30 minute marathon, an impassable advantage.</p> The Nike Vaporfly 4% </p> </div> Supershoes make you lose</h1> You might think that racing in these shoes would convey a career-defining advantage, but they actually do the opposite. The shoe only helps one to lose, not to win.</p> Initially, Nike restricted the supply to its sponsored athletes. Runners sponsored by any other brand were at a disadvantage. After a while, Nike made the shoes generally available, and competitors created similar shoes. Since then, the entire marathon elite field shows up wearing supershoes. They have to: those who don't are competing with a handicap.</p> In the men’s marathon at the 2016 Rio Olympics, most of the competitors wore the same green Nike shoe. Photo Credit: Norman Katende </p> </div> LLMs are supershoes</h1> LLMs are like the Vaporfly shoe in the bad ways and not in the good ways.</p> Whether used for writing software or marketing copy, LLMs promise to make businesses ship faster, both yours and your competitor's. If they live up to this promise (an uncertain claim 2</a></sup>), no winners are made; only losers who don't wear the new shoes.</p> At least supershoes don't take away fitness. You still have to run. In contrast, LLMs can make you dumber 3</a></sup>. They're mopeds, not bicycles 4</a></sup>.</p> The winners are the shoe makers, LLM providers, and GPU manufacturers.</p> Take aways</h1> In a competitive landscape, LLMs, like supershoes, do not result in your benefit.</li> LLM providers are SaaS 5</a></sup>. All SaaS wants to minimize customer turnover and to expand revenue. The SaaS dream is to capture customers and make them dependent on the SaaS offering.</li> LLM dependency is both competitive and cognitive. Competitive: All of your competitors are using LLMs. You have to keep up with the pack.</li> Cognitive: LLM use atrophies one's ability to think and reason, making one likely to prompt again. The dependency is self-reinforcing.</li> </ul> </li> </ul> References</h1> Nike's Controversially Fast New Shoes</a></li> Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</a></li> Your Brain on ChatGPT</a></li> LLMs are not Bicycles for the Mind</a></li> Software as a service</a></li> </ol> How to say no without authority 2025-10-22T00:00:00+00:00 At work, saying no to someone higher on the org chart is safe if you first earn their trust and if it's for the good of the business.</em></p> There's more than one type of authority. Being the boss is just one. The red circle is smallest because it's the weakest. </p> </div> Key ideas</h1> There's more than one kind of authority</li> Saying "no" without positional authority is a negotiation</li> Relational authority is a valid negotiating position</li> You earn relational authority when you make people feel understood</li> To understand someone, you first have to cool down, even if you disagree</li> When your "no" is aligned with business objectives (increased revenue or reduced costs), you can negotiate with a clear conscience.</li> To negotiate, you need to establish common ground.</li> You are the only factor you can control, so dig through your beliefs and worldviews for that common ground.</li> </ul> Why read this?</h1> Hackers lack soft skills. That includes me.</p> (For the general audience: the term "hacker" doesn't mean what you think. If you're comfortable with a command line interface, you're probably a hacker. Being mysterious and unethical is not part of the definition).</p> I showed a draft of this post to my wife, who is an elementary school teacher. She remarked, "In my line of work, this is very basic stuff. Like, not interesting at all. Do you think tech people need this post?" I don't know you, dear reader, but I've been in this game long enough to know that hacker culture does not esteem soft skills. We'd much rather learn Haskell or complain about the Apple tax. Seven employers have not subjected me to such training: what soft skills I possess, I've learned on my own. My hope is this post gives you a head start.</p> Intro</h1> About a week ago, a software developer, nickname him Thrug (a cousin of Grug</a>), submitted a post to the /r/ExperiencedDevs</code> subreddit with the title, Why do people think software development is easy?</em> In short, the Thrug's management asked for an unrealistic deliverable and did not appreciate his manner of protest:</p> [Management says], "it should be simple to build" ... I am always sort of at a loss as to how to even respond ... When I tell them no that’s not possible, they get upset and treat it as me being difficult ... One guy or a few are asked to build the impossible. 1</a></sup></p> </blockquote> Diagnosis</h1> To be brief, Thrug's employer exhibits the traits of a pathological organization. As for Thrug, his escalated emotional state blocks any capacity for empathy and persuasion.</p> A pathological organization</h2> Anyone who has read the book Accelerate</em> 2</a></sup> can quickly discern from the following red flags that Thrug is working amongst dysfunction. I wouldn't apply for a job at Thrug's company:</p> There's a hero culture</strong>. The company expects an individual to deliver what should take a team.</li> There's an absence of psychological safety</strong>. Messengers get shot. Blame is the norm. For being realistic, Thrug is labeled "difficult", though I think some of the fault rests with the manner of his pushback, which I'll get to in a moment.</li> Long project timelines imply infrequent deployments</strong>, which means each deployment carries greater risk, which contributes to...</li> High change failure rate</strong>. Bugs are the probable outcome of rushed projects. Remember "Good, fast, cheap. Choose two." 3</a></sup></li> No learning culture</strong>. According to Thrug, this isn't the first time the company has ignored developers and overpromised deliverables.</li> </ul> Thrug is in a tough environment; he isn't crazy.</p> Blinded by feelings</h2> At the same time, some the criticism from Thrug's management is valid.</p> His post includes charged, accusatory language and absolute statements:</p> "managers dictating what softwares to make"</li> "These people have no concept of technology"</li> "everyone thinks things can just be tossed into the magical black box"</li> "zillion other things"</li> "just flat out impossible"</li> </ul> From its length, I'm guessing the post took Thrug at least one coffee break to write. If this is the language Thrug deploys after cooling off a bit, I can infer he was at least as escalated when communicating with his management in realtime. This lends some validity to the label "difficult".</p> It's clear that Thrug feels strong negative emotions: he feels frustrated and exasperated at being misunderstood, isolated with no leadership in his corner, and defensive when accused of being the problem.</p> Like I said, Thrug has good reason to be upset: his worldviews are in conflict with his workplace.</p> He believes that craftsmanship is more important than speed.</li> He believes that expertise should be respected.</li> He believes management is theatrics.</li> </ul> Thrug is upset, but the problem is that he stays there and doesn't move forward toward constructive resolution. He's not exactly endearing himself to his leadership. Nobody in management can say, "Well, Thrug didn't perform as I expected, but he's a great guy and I enjoy having him around." As a result, the business misses out on his valuable perspective. It's up to Thrug to make a change, for his benefit and the benefit of the business.</p> Remedy</h1> Now that we know Thrug's failure mode (overheated emotions), we can prescribe a path to resolution:</p> Deescalate</li> Humanize</li> Negotiate</li> </ul> If Thrug can deescalate his emotions, he will be able to empathize with his management's perspective and to show he cares. He will be willing to listen, to back off from his hardline "no", and to negotiate options. All this will flip their perception. Once they believe he understands them and is on their side, they will be much more likely to listen to him.</p> Deescalate</h2> We can't think straight when we are escalated emotionally; the structure of the brain all but guarantees it. When activated, the amygdala mostly preempts the prefrontal cortex's ability to think ^{4</a></sup>. You have to calm down first.</p>} To calm down, take two minutes to close your eyes and breathe deeply. This can shift the brain out of crisis mode and let you start to think. Then, identify your feelings. Naming them is enough.</p> If you're face-to-face with someone, you may not have two minutes to calm down. While it is possible with practice to deescalate in a matter of seconds, it's best to ask for a few moments to think or to take a trip to the restroom.</p> Humanize</h2> Once you are calm enough to think somewhat objectively, your goal is to humanize the other party. Naming their probable feelings is a great start, because it bootstraps your empathy. Asking questions lets them clarify their feelings and perspective. Listening is like attaching a debugger to a person and inspecting their local variables and emotional call stack. Are they angry, fearful, insecure? Does their mom have cancer? Are they behind on their mortgage?</p> Example: Imagine you're Thrug. Think about the manager you're most upset with. You just left a meeting with them ten minutes ago. You've calmed down, or as much as one can in ten minutes. Now ask yourself, what is that manager going through? How do they feel? Here's one possible thought train:</p> Well, my manager said the Director of Product said we missed quarterly revenue goals and have customer retention issues. That sounds like bad news. The director probably had a tough meeting with the middle managers, from which our meeting resulted. I bet a lot of similar meetings are happening right now, so I'm not alone. This is probably from even higher up: I've often heard the private investor group backing us is pushy. This isn't my manager's fault. He's stuck between a rock and a hard place: the Powers That Be demand more of him, but I know it's not even possible. Moreover, I was really nasty to him about it. I know he's been a manager for only a year. He started out in customer service years ago. I remember him saying offhand a few weeks ago how the call center was way more fun. That's really saying something since our customers are sweat shops and drug cartels. Perhaps training could help my manager, but I know finance is never going to approve it. He's stuck where he's at. With just an associate's degree, he isn't qualified for such a well-compensated role anywhere else. He can't risk it anyway, since he has a wife and toddler and newborn at home. Man, he's in a tough spot.</p> </blockquote> Next, with a rational mind, Thrug can challenge his own worldviews. For example, he could come to accept that in business, the fundamental purpose of software development is to bring business value, not to practice craftsmanship. This happens to be a worldview that his manager very likely also holds. That's valuable common ground. Thrug can repeat to himself:</p> Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals. 5</a></sup></p> </blockquote> Negotiate</h2> Yes, negotiation. When you are saying "no" to someone and don't want to burn a bridge, you are in a negotiation, not just for the decision but also for the relationship.</p> Now that the other person is a human again in your mind, it's time to communicate with them. You're going to let them know that you are on their side. This addresses the ethos</em> of your negotiating position.</p> What is ethos?</h3> Ever heard of logos</em>, pathos</em> and ethos</em>? In rhetoric, logos</em> is the logic of your argument. Pathos</em> concerns how people feel about your argument. Ethos</em> is your credibility and authority. You can have a totally valid argument (good logos) and be unpersuasive because you are not trusted (poor ethos).</p> The ethos you project needs to be genuine. Don't apologize if you aren't. Don't insinuate you are working in someone's interest when you aren't. Don't ask how someone is doing if you don't care. If they get a whiff of your duplicity, you're in doo-doo.</p> Ethos is authority</h3> Most people when they hear the word authority</em> picture positional authority: an airline captain, your boss, a police officer. You listen to these people because of the consequences they can inflict, which in these cases includes removing you from a flight, firing you, or firing at you.</p> There are other kinds of authority, and the kind I'm advocating here is relational</em> authority. You listen to someone because you trust them. Relational authority is a kind of earned</em> authority. You're not handed relational authority when you become someone's boss: you have to earn it. Another kind of earned authority is expert</em> authority: You listen to someone because they've proven their competence. It's why you listen to your doctor even if she has poor bedside manners. Thrug's boss may have positional authority over Thrug, but we can infer from Thrug's post that he does not possess relational or expert authority with Thrug. In turn, Thrug doesn't possess any of these three forms of authority with his manager. It's not a good negotiating position.</p> The restorative conversation</h3> Here's how Thrug can instantly improve his negotiating position with his manager. The next time they talk, he can say, "I apologize for my response last time. I bet it feels like you're between a rock and a hard place, between senior leadership's demands and my rants." Thrug should be prepared for a potentially emotional response. That's good and means he is getting through and it's time to listen. If the response is bland, his inference might be incorrect, or his manager might be guarded. Obviously hasn't forgotten about recent interactions. In these cases, Thrug can simply ask, "How do you feel about all that?" When talked to this way, most people will mirror your gentleness and open up.</p> Relationship takes time</h3> In particularly broken relationships, it may take time and consistency to restore relational authority.</p> The strongest relationships have been cultivated over long periods of time. You should always seek to build rapport and trust with people because people are valuable in and of themselves 6</a></sup>. However, humans are eager help you if they like you. Ask your DevOps lead about his sickly mother and show genuine concern by following up once or twice. Months later, watch how your request to update the CI pipeline skips the weeks-long backlog and is done two hours after you asked. True story.</p> Make the offer</h3> With a relationship in place, the conversation can proceed on constructive terms. Thrug can make an initial offer: "I want to help deliver business value. I still think it'll be a long shot, but I'd like to talk about some options to cut scope so we can realistically ship Feature X on time." A back-and-forth follows from there.</p> In a negotiation, there is always a BATNA: the Best Alternative to a Negotiated Agreement. It's what happens if you and the other party fail to reach an agreement. In this case, there are at least two alternatives:</p> Thrug leaves the company.</li> The company commits to more than it can deliver. The company misses the revenue, loses to competitors, and Thrug is out of a job anyway.</li> </ul> I think for at least the short term, these two alternatives are worse for the business than negotiating an achievable deliverable.</p> Summary</h1> When you as a software developer have the insight that a software deliverable is unachievable, it's in the business's interest to negotiate another plan. The negotiated deliverable is more likely to be delivered on time and its business value realized. If you're in a blameful work culture, building relational authority first serves as job security.</p> This is how you say "no" in a way that earns respect:</p> Deescalate</strong> if necessary. Pause. Breathe. Collect yourself.</li> Humanize</strong>. See the other side's feelings. Let them feel understood and cared about. Listen. Ask questions.</li> Negotiate</strong>. Offer choices. Rarely do you actually utter the syllable "no".</li> They make a choice</li> They walk away feeling good because you're working for their benefit.</li> You're protected because they made the choice and they respect you.</li> </ul> </li> </ul> It's like the old Aesop fable of the North Wind and the Sun ^{7</a></sup>. The harder the wind blew, the tighter the man held on to his coat. The sun however warmed the man until he willingly removed it. Go forth and do likewise.</p>} References</h1> Why do people think software development is easy?</a></li> Accelerate (book)</a></li> Project management triangle</a></li> Emotional Intelligence (book)</a></li> Don't Call Yourself A Programmer</a></li> Psalm 139:14</a></li> The North Wind & the Sun</a></li> </ol> Recommended Reading</h1> Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations</em>. Portland: IT Revolution Press.</li> Goulston, M. (2010) Just listen: Discover the secret to getting through to absolutely anyone</em>. New York: AMACOM.</li> Goleman, D. (1995) Emotional intelligence: Why it can matter more than IQ</em>. New York: Bantam Books.</li> </ul> Addendum: A personal experience</h1> Thrug's post hits close to home, because I recently lived this experience. About eight months ago I was writing software at a company with a similar management culture. Communication was one-way, and the company was piling on tech debt faster than anyone could track. I was a vocal messenger but was viewed as the problem. Thrug's management is comparably patient: I was fired after eight weeks.</p> My dismissal was tragic. I knew my tech skills could have helped that company, but I never got to deploy them because of my manner of communication. It's tempting to blame the company, but I am the only factor which I know can change. In the months after, I came to regard soft skills as my new growth area: I bought no less than seven books on emotional intelligence, negotiation, conflict, and leadership. I also went through a counseling program at my church.</p> As my software engineering career stretches toward two decades, more often I've found it necessary to turn things down. The audience and context varies: sometimes I'm speaking with mentees, sometimes with peers, and often enough with superiors. Sometimes it's declining a change in a pull request. Sometimes it's in a meeting, talking the team down from a design decision. A couple of times, it was on the phone with a customer, tactfully helping them see the problem was on their end or that the software works as intended.</p> It's Time to License Software Engineering 2025-09-15T00:00:00+00:00 Society restricts who can design bridges or prescribe medicine, but it lets anyone market their software. AI accelerates the problem. It's in everyone's interest that states require licensure of software engineers.</em></p> AI has dramatically broadened who can create software. </p> </div> Why I care</h1> I almost became an engineer. From 2008, I spent three years pursuing a degree in computer engineering. I sat in engineering fundamentals and ethics courses with people who became engineers: mechanical, electrical, aerospace, nuclear, and others. We all planned to graduate, pass the FE exam, work a while, pass the PE exam, and become licensed professional engineers.</p> Then I switched to computer science. At the time, the thought of government adding red tape to my career path angered me. You don't even need a degree to become a software engineer. You just have to convince someone to hire you into that role.</p> Fast forward to 2025, and the barrier to entry is even lower. AI lets anyone ship software, and it's causing an avalanche of quality issues1</a></sup>. The classic engineering disciplines have spent centuries learning hard lessons about cost and quality. My profession could learn a thing or two from them.</p> Why do we have engineering licensure?</h1> How the US got started</h2> On March 12, 1928, the St. Francis dam near Los Angeles had stood for just under two years when it collapsed with almost no warning. Flood water surged down the San Francisquito Canyon, drowning over 400 people and causing extensive damage to man-made structures and the environment2</a></sup>.</p> The St. Francis Dam before its collapse </p> </div> The St. Francis Dam after its collapse. Just a small section of the wall remained, nicknamed "the tombstone". </p> </div> The immediate cause was the material on which the dam rested essentially dissolved and eroded away when it became wet. The proximal cause was the dam's designer was not qualified to design dams, and being self-taught, made critical errors in judgement. The root cause was a public policy which permitted the design and construction of dams by unqualified people and without independent review.</p> Just over a year after the collapse, California enacted its Civil Engineers Act, making it the second US state to regulate licensure of engineers. By 1947, all states had created similar licensure laws for Civil, Mechanical, and Electrical engineers.</p> Licensure lifts quality</h2> Market forces exert a downward pressure on cost and therefore on the quality of products and services. Licensure of professionals, combined with the standards they must follow, protects public welfare by exerting a counteracting upward force on quality.</p> Licensure sets a minimum bar for quality and upfront cost. Read more about cost in Objections</a>. </p> </div> For example, the International Building Code specifies a minimum load a roof must be able to hold up. Without this requirement, structural engineers might cave when pressured to find ways to make a building cheaper.</p> Another way to look at it is, competing firms find themselves in a prisoner's dilemma where they all could</em> cooperate and offer high quality goods. If any one of them defects by offering a lower price, then to maintain market share, all firms must follow suit. A Nash equilibrium emerges where nobody offers quality goods. Markets do segment; it's how Jones soda can exist in the same world as Coca Cola and Pepsi, but they all follow FDA standards for water quality.</p> Licensure lifts the Nash equilibrium to a higher level of quality, since no participant has the choice to cut certain costs.</p> Why license software engineers?</h1> Software can Harm People</h2> The collapse of a dam, bridge, or building is tragic when it costs lives. Bad medicine is also insidious: it promises a cure but delivers none or actively harms the patient.</p> Software is less tangible, but it can also cause widespread harm. For example:</p> In 2024, the global Crowdstrike outage brought down 18,000 customers and businesses, including retail stores, banks, universities, airports, hospitals, and governments3</a></sup>.</li> Tesla's self-driving cars marketed with "Autopilot" have a well-established record of killing occupants, pedestrians, and other drivers4</a></sup>.</li> </ul> Most of your line-of-business software isn't going to kill people, but software supply chains are complex: a library maintained by some guy in Nebraska5</a></sup> can show up in surprisingly mission-critical situations.</p> Society wants it</h2> Professional licensure ensures both adequate competence and a commitment to public good.</p> Physicians take countless exams and traditionally recite some derivative of the Hippocratic oath, promising to do no harm with their practice of medicine. Engineers take the FE exam and the PE exam. Both professions follow their respective code of ethics.</p> If software engineering had had any serious commitment to the ACM's 1999 code of ethics6</a></sup>, I think the world would look different today. The profession has exerted herculean efforts enabling these societal harms:</p> surveilling and amassing personal information</li> showing targeted ads for the highest bidder</li> rent-seeking and encrapifying marketplaces</li> </ul> Nonpractitioners want it</h2> By practitioners, I mean people who were already writing software for a living before LLMs or who could continue to do so if all LLMs were turned off.</p> AI lets anyone write software, even if they don't want to or are not qualified to.</p> Mr. Big Boss can now ask Suzy Secretary to write a bossware app that tracks remote employees' app use and keystrokes. As of 2025, Suzy can no longer say "I don't know how to do that" because with Claude Code and a 30 minute YouTube tutorial, she can. She has no code of ethics by which to say, "I won't do that". She also doesn't know that the AI-generated spyware transmits company data over the web in plaintext. Suzy shouldn't do this job, but she has no power to decline.</p> Mr. Big Boss could never ask Suzy to write him a pharmacy prescription. Why can he do that for software?</p> Practitioners want it</h2> In the US, the titles "Professional/Licensed/Registered Engineer" are legally protected7</a></sup>. Without a license, it's unlawful to market oneself using them.</p> In the U.S., most employment is at-will, meaning you can leave or be fired at any time and for any reason, but many states and federal laws create exceptions that can make a termination unlawful* when an engineer is fired for refusing to break the law or for protecting public health and safety. Many statutes are derived from the NSPE Code of Ethics.</p> I personally witnessed a professional engineer successfully sue our former employer which fired whim when he wouldn't sign off on a medical device he didn't think was ready to treat patients.</p> * I am not a lawyer.</p> Customers want it</h2> Licensure protects consumers, too. The threat of license revocation encourages responsible conduct.</p> If you want to build a house, your architect has to convince a licensed structural engineer to sign off on the mechanical soundness of the structure. If the house later collapses, you have legal recourse against the engineer.</p> Objections</h1> Licensure doesn't make software better</h2> It does improve outcomes for the existing professions, and in three ways:</p> It ensures a minimum level of competence.</li> It holds professionals accountable to a code of ethics.</li> It provides leverage for professionals to push back on forces that compromise quality.</li> </ol> In a world where I hold a license to practice software engineering, I hold the keys to shipping legally. I have leverage when my project manager pushes back against unit tests and tech debt. They don't hold a license, so they can't ship without me.</p> Licensure will get abused by political actors</h2> On the contrary, licensure would give our profession a backbone and a voice. There's no real unifying body for software engineers. For the vast majority of them, IEEE and ACM are irrelevant.</p> The AMA and NSPE respectively serve that role for physicians and engineers. Their age is measured in centuries, and they serve as nonpartisan beacons of ethics and professionalism.</p> Software will get more expensive.</h2> The upfront cost will increase, but a long tail of costs stemming from quality issues will decrease.</p> What's cheaper: to build a dam right or let it collapse and kill 400 people?</p> What's cheaper: Adding adequate driver awareness detection to Teslas or a fatal accident rate that's twice the industry average?8</a></sup></p> What costs more: Adding automated tests now or years of tech debt?</p> How can engineers without a license find work?</h2> The same as unlicensed civil engineers: behind the name of a licensed PE (professional engineer) who signs off on their work.</p> Can Suzy still write software?</h2> I think Suzy should be allowed to write her own apps and even share them with friends. To sell them or use them commercially, she needs a PE to sign off.</p> Like agriculture, you can grow your own tomatoes in your backyard, and you can bring a bag of them to share at work, but if you start selling them, the FDA might come visit.</p> When it comes to private activity, there are edge cases and nuance. It often comes down to scale and risk.</p> You can DIY a shed but not a house.</li> You can self-prescribe ibuprofen but not oxycodone.</li> </ul> Is software free speech?</h2> In the US, yes9</a></sup>, but causing public harm or encroaching on others' rights is not protected. For example, DeCSS was ruled to be illegal10</a></sup> even though it was free, noncommercial software.</p> Will some committee tell me how to do my job? (What language to use, where the curly braces go, etc.)</h2> I think some recommendations are to be called for. These would provide some of that upward force on quality against the market's tendency to push it down.</p> There is already pressure e.g. from NIST to use safer, more secure languages, like Rust or C# instead of C or C++. To that I would add QA standards like automated testing. Just like a structure must undergo inspection, it simply should not be a business's choice to skip QA of software.</p> However, the software profession has a great deal of variety in the work it does and the tools it uses. It also changes very rapidly, since the field is extremely young compared to e.g. civil engineering. We shouldn't enforce things we aren't certain are beneficial.</p> What mechanisms will there be to obtain licensure?</h2> Like the existing PE, there would be training and exams. There would be statements to sign, like a code of ethics, as well as continuing education.</p> Grandfathering and exemptions were common in the early days of the PE. These would be awarded based factors like education, length of career, and reputation.</p> Isn't this overkill? What about open-source projects?</h2> What I'm proposing is only for commercial software, at the end of the supply chain. A professional software engineer signs off on all of the packages and dependencies used in a product. Nothing changes for the guy working for free in Nebraska.</p> One of the differences between e.g. structural and software engineering is with the former, there is a clear distinction between design and construction, i.e. between idea and tangible artifact. A structural engineer doesn't necessary even see the constructed building whose structural designs he approved. Software engineers handle both.</p> I considered conceding that we could require sign-off just for certain high-risk classes of software like automotive, medical, and aerospace or high-scale classes like social media, but that does not address the problem of everyday people selling or commercially deploying AI-generated software whose quality they aren't able to ensure.</p> What about versioning? Do I need a sign off for minor revisions and bugfixes?</h2> Each public release of commercial software needs a sign off.</p> So my WordPress blog needs a sign off for each post?</h2> That's publishing, not software, and requiring sign off on writing would encroach on free speech.</p> How would it be enforced?</h2> Probably via courts. We should look to the existing engineering disciplines for guidance and precedent.</p> Conclusion</h1> Consider supporting licensure of sofware engineering. My aim is to protect:</p> society from a deluge of low-quality software of uncertain provenance.</li> the craft and integrity of the profession from unethical demands.</li> nonpractitioners of software engineering from being consigned by their employers to write software they aren't qualified to.</li> </ul> Next...</h1> Subscribe to my email list below. I plan to write more.</p> References</h1> 5 Vibe Coding Failures That Prove AI Can't Replace Developers Yet</a></li> Total Failure of St. Francis Dam Renewed Calls for Oversight</a></li> 2024 CrowdStrike-related IT outages</a></li> List of Tesla Autopilot crashes</a></li> XKCD: Dependency</a></li> The Software Engineering Code of Ethics and Professional Practice</a></li> Regulation and licensure in engineering</a></li> The 23 Most Dangerous Cars On The Road</a></li> Bernstein v. United States</a></li> Universal City Studios, Inc. v. Corley</a></li> </ol> About that Gig Fixing Vibe Code Slop 2025-09-05T00:00:00+00:00 AI now lets anyone write software, but it has limits. People will call upon software practitioners to fix their AI-generated code. Learn how to decide when to take that gig.</em></p> </p> Venn diagrams showing that AI lets more people make software </p> </div> Everyone Can Make Apps Now, sort of</h1> All over the world, people who haven't written a line of code in their life are using chat bots and coding agents to code up their dream product or app.</p> Venture capitalists, MBAs, project managers, visual designers, auto mechanics, and even elementary schoolers are now able to obtain working implementations of their ideas, and for a fraction of the cost. In 2025, you can pay a developer $10,000 to make a web app in a few weeks, or you can pay an AI company $2 in tokens and ship in a few hours.</p> But LLMs have limits:</p> Context windows limit how much code and conversation they can digest.</li> Hallucinations interpolate false information.</li> A lack of long term memory means each morning is the first day on the job.</li> A lack of emotion and metacognition means they don't get that "sinking feeling" that causes humans to pause and assess their choices.</li> </ul> The ease of starting a software project leaves nontechnical people surprised when they hit a productivity wall. This is a risk for them 1</a></sup>2</a></sup>, but an opportunity for you.</p> Practitioners to the Rescue, maybe</h1> When AI leaves a nontechnical person up a creek without paddle, there's a nonzero chance they'll be ready to hand the work over to a professional.</p> Why? Maybe their reputation is on the line, or their company's revenue. Maybe their proof of concept demonstrated enough value to justify making it production-ready. Maybe the prototype is already in production and its bugs have caused downtime, data loss, or customer churn.</p> Whatever the circumstance, if you can read and write software without LLMs, you can charge money to make their problem your problem. When you receive that call, email, or LinkedIn message, what will your answer be? Before you sign, should know what you're getting into.</p> You're dealing with a special category of legacy code</em>.</p> A Venn diagram showing that AI-generated code is a kind of legacy code </p> </div> What Is Legacy Code?</h1> You know you're dealing with legacy code when either:</p> It's a huge codebase</em>: even ideal code in high quantities is expensive to change.</li> You have low confidence</em> that the code is or will remain correct.</li> </ol> The general topic of legacy code maintenance is already addressed in some great literature 3</a></sup> 4</a></sup>. Since it's not currently within the abilities of LLMs to generate very large codebases, this short post will focus on confidence</em> .</p> How do we know when software is correct?</h2> Software practitioners have three gates at their disposal to catch software defects:</p> Runtime</strong>. The app has errors when you run it. They can surface to users, like error messages, or remain hidden, like logs. Unit and integration tests attempt to reveal errors at runtime.</li> Compile time</strong>. The compiler yells at you on your dev machine or in your CI/CD pipeline, because for example you can't do Dog fido = new Cat()</code>. You can't run code that won't compile.</li> Design time</strong>. This one is trickier. A bad design will compile and run. There's no automated way to evaluate design. It has to do with fulfilling the software's requirements, and in a way that keeps the software simple and easy to change. It's about structure and language: boxes and arrows; lexicons and metaphors. I explored the relationship between design and code in a previous post 5</a></sup>.</li> </ul> You will notice that runtime occurs after compile time, which occurs after design time. In general, it is most cost-effective to shift errors from runtime to compile time and from compile time to design time. When using an iterative SDLC, the time between each step is shortened, but the sequence is still there.</p> It's more expensive to fix code at runtime than at compile time and at compile time than at design time. </p> </div> Unfortunately, AI rushes people to runtime as fast as possible.</p> When don't we have confidence?</h2> From the previous points, we can see that there are a few reasons one might feel reluctant to change legacy code:</p> Runtime There are no automated regression tests.</li> There are no manual regression tests.</li> </ul> </li> Compile time The language doesn't discover errors at compile time, i.e. it is interpreted, dynamically typed, or weakly typed. Examples include Python, Ruby, and JavaScript.</li> The code doesn't make use of the compiler's type system. For example, it uses strings like "Employee"</code> and "Admin"</code> instead of value types like record Employee; record Admin</code> or enums like enum User { Employee, Admin }</code>.</li> </ul> </li> Design time There is no specification</strong>, i.e. what the code should do is not written down.</li> There is no documentation</strong>, i.e. no knowledge about the code's internal structure or design is written down.</li> There are no domain experts</strong>, i.e. people who know about the problem the software solves.</li> There are no code experts</strong>, such as a developer who wrote the code. The bus factor ^{6</a></sup> is zero.</li>} The code is badly structured</strong>, i.e. hard to understand and hard to change.</li> </ul> </li> </ul> Unique Qualities of AI-Generated Code</h2> AI-generated code inherits the characteristics of legacy code but is especially likely to have these:</p> Low internal quality</strong>. You'll hear this feedback from developers: "this code makes no sense". They may be referring the code's poor structure: duplication, inconsistent patterns, or to poor naming and a lack of coherence between the code and the part of the world the software interacts with. The result is the code is hard to understand and hard to change.</li> Low external quality</strong>. You'll hear this kind of feedback from non-developers, with phrases like, "this thing kind of does what I want, but not quite" or "this thing is so buggy". The code fulfills its requirements partially or circumstantially.</li> High Quantity to Age Ratio</strong>. You don't need AI to write legacy code. Humans do it every day, but AI can do it faster.</li> </ul> The Confidence Rubric</h1> My Confidence Rubric</em> evaluates the previously discussed factors to score how painful a codebase will be to work in.</p> Spec</th> Docs</th> Code Expert</th> Domain Expert</th> Tests</th> Structure</th> Language</th></tr></thead> ?</td> ?</td> ?</td> ?</td> ?</td> ?</td> ?</td></tr> </tbody></table> Let's fill in the rubric while considering two made-up scenarios.</p> Scenario: Auto Repair Shop</h2> James runs a car repair shop by himself. A YouTube video taught him to use Lovable to write a web app to track his small business's tools and parts inventory. It wrote the frontend in ReactJS and the backend in Python+Flask+Postgres. There are no automated tests, docs, or specs.</p> The app works fine, but Lovable has trouble iterating from there. After James hires two employees, he needs to track who has which tools. He asks Lovable what to do. It recommends implementing identity, authentication, and authorization. That's total overkill: OAuth is hard, and simpler solutions would work. James doesn't know that, so he says go for it. Lovable goes down a rabbit hole and can't get it working. After burning four hours on a Sunday afternoon, James gets fed up and the next day calls a software consultancy.</p> Here's our confidence rubric for James:</p> Spec</th> Docs</th> Experts (Code \| Domain)</th> Tests</th> Structure</th> Language</th></tr></thead> ❌</td> ❌</td> ❌ \| ✅</td> ❌</td> ?</td> ❌</td></tr> </tbody></table> There's only one thing going for this codebase, which is that you can talk to James.</p> Notice we haven't evaluated the structure. We won't cover that deep topic in this post, but if you have the opportunity, sign an NDA and have a look at the actual code before committing to the job.</p> Scenario: Small VC Firm</h2> Susan studied at a major USA university. She took a year of computer science before switching to an MBA. After college, she worked at Big Enterprise, but for the last five years she's worked at a small venture capital firm. She's not a developer, but she remembers some things from her CS program and her time at the Big Enterprise. She follows a tutorial and has Claude Code write a web app to manage her company's investment portfolio. She asks Claude to write the app using the same technologies she knew worked at the Big Enterprise: ASP.NET Core Blazor + Azure App Service and Managed SQL Database. Following the tutorial, she writes her requirements in a Requirements.md</code> file and has Claude and track its progress across sessions in a Tasks.md</code> file as well as keep a README.md</code> file up to date. She has Claude commit incrementally using git. There are integration tests which run the app in a browser against an in-memory DB, click buttons, fill and submit forms, and verify expected changes in the DB.</p> The app is a hit, since everyone at the firm is tired of sharing spreadsheets. Not long after, Susan retires, and her younger colleague Mark inherits her work. The app hums along unmaintained for months. One day, the CEO is out on the putting green and opens the web app on his phone. He notices that it looks terrible; Susan only ever tested it on her 1080p work monitor. He calls up Mark and asks him to make it mobile-friendly. Mark has no idea and is busy; he immediately reaches out to a consultant.</p> Here's our confidence rubric for Mark:</p> Spec</th> Docs</th> Experts (Code \| Domain)</th> Tests</th> Structure</th> Language</th></tr></thead> ✅</td> ✅</td> ❌ \| ❌</td> ✅</td> ?</td> ✅</td></tr> </tbody></table> Without even looking at the code, it's already looking like Mark's project will be easier to work on than James, but there is still more to consider.</p> Human and Organizational Factors</h1> Outside of the code, there are nontechnical factors that can affect any software project: there can be difficult personalities, tall management structures, entrenched political actors, and misaligned expectations.</p> While James' code might be a bigger lift, I'll bet working with him would be more straightforward than proxying through Mark to his CEO, who is busy flying around doing VC things. On the other hand, I'll bet that a VC firm is less price sensitive than a car repair shop.</p> Managing Expectations</h2> Stable</em> and boring</em> often describe legacy code. It's often old and business-critical, and an established organization understands that it takes time to turn a big ship.</p> With AI-generated code, there's none of the stable cash-minting of an old lethargic codebase. While it may not be business-critical, there is likely schedule pressure to fix the mess. To the business, you'll feel slow compared to the quick start AI gave them. You'll need communicate expectations and sell the business on the ROI of finishing the job.</p> Summary</h1> When you're offered a job or gig fixing AI-generated Code, give pause.</p> AI-generated code is a lot like legacy code, with some unique characteristics.</li> Not all AI-generated codebases are the same. Use the Confidence Rubric discern between them.</li> Consider the human and organizational factors.</li> Consider the customer's willingness to pay.</li> Bigger headaches merit bigger checks, because you bring more value to the business.</li> </ul> References</h1> It's Not Tech Debt. It's Tech Risk.</a></li> Tech Risk is Business Risk</a></li> Brutal Refactoring</a></li> Working Effectively with Legacy Code</a></li> A Design is a Mold for Code</a></li> Bus factor</a></li> </ol> LLMs are not Bicycles for the Mind 2025-08-25T00:00:00+00:00 LLMs are more like E-bikes. More assist makes you go faster, but provides less exercise.</em></p> A greenway and a sign that says "No Motor Vehicles". Source 1</a></sup> </p> </div> In 1980, Steve Jobs spoke,</p> What a computer is to me is it's the most remarkable tool that we've ever come up with, and it's the equivalent of a bicycle for our minds.</p> </blockquote> I don't think that LLMs are like bicycles for the mind. They are more like E-bikes.</p> Greenways and E-bikes</h1> A few nights ago, I was walking with my wife on the greenway. It's illuminated, so we were easily visible. We were absorbed in our conversation when an e-bike startled us, appearing around a curve and speeding toward us at about 25 miles per hour (~40 km/h). With just a couple of seconds to react, I pushed my wife out of danger and into the damp grass. As the two-tired vehicle passed, I turned toward its rider and yelled, "SLOW DOWN!". He muttered an unintelligible, unconcerned reply and motored on. As he disappeared from sight, I was angry and my wife was distraught.</p> The town where I live has excellent greenways, and I spend a lot of time running and walking on them. Seriously, it's thousands of miles each year, and over the last five years, I've noticed an increase in use of electric vehicles on our greenways: I've seen e-things of all kinds and sizes: bikes, scooters, skateboards, longboards, and unicycles.</p> I suppose people believe that the absence of a gas engine makes a vehicle acceptable on the greenway. The greenway is an outdoor space reserved for humans to exercise and enjoy nature. E-bikes that go too fast deter pedestrians from using it as intended.</p> I am not against electric vehicles on the greenway when riders use the throttle responsibly. Electric assist is a fantastic gateway to a healthy aerobic exercise regimen for those who could otherwise not even start. For example, my older colleague's e-bike gives him the confidence he needs get out in the first place.</p> LLMs are like E-bikes</h1> In software engineering, LLM use is like riding an e-bike on the greenway. Appropriate use comes down to how much "throttle" you use: how much cognitive effort you offload to the bot. Engineering is an intellectual and collaborative space where human minds work hard to solve business and technical problems. When you drop a mostly LLM-generated contribution into a chat or pull request, you zoom by on your LLM-moped, disrespecting and alienating those who are engaging their neocortex without assistance.</p> One of the rudest encounters I've had in my career was when a former colleague contradicted me in a technical discussion with an LLM-generated reply. Their screenshot of ChatGPT was lazy and reinforced an incorrect belief. It amounted to nothing more than an appeal to authority: the AI said it, so it must be true 2</a></sup>. The asymmetry principle 3</a></sup> helps explain why it was so frustrating: my counterpart effortlessly generated the LLM rebuttal which took me time and effort to parse and refute.</p> At my work, the ratio of LLM-generated code in pull requests is rising. The interesting thing about these is the author often doesn't seem quite as, well, authoritative</em>. It seems that when a robot has written the code, a higher portion of my feedback is ignored or answered unsatisfactorily. Since the point of a pull request is knowledge sharing and responding to feedback, it's a bit of a waste of time and feels more like a rubber-stamp request.</p> I'm not pointing fingers: In mid-2023, I completely over-relied on ChatGPT and shipped code I didn't understand to production. It took me three weeks to fix a defect that came up. Pretty embarrassing.</p> Summary</h1> You can depend on LLMs too much. Use them in a way that doesn't atrophy your mental fitness and doesn't exasperate your colleagues.</p> References</h1> What's Wrong with this Picture?</a></li> Appeal to Aithority</a></li> Brandolini's Law</a></li> </ol> Oil Spills Can Create Jobs 2025-08-09T00:00:00+00:00 LLM-generated code is like an oil spill. Real engineers will be there to mop up the mess - and collect the checks.</em></p> Workers clean up LLM slop. Source: US Coast Guard1</a></sup> </p> </div> The job outlook is not so bad</h1> In 2010, after the BP's oil rig Deepwater Horizons</em> dumped 3 billion barrels of oil into the Gulf of Mexico 2</a></sup>, at least $20B of BP's purse was redistributed to a massive mobilization of cleanup efforts. By 2014, this had resulted in a net increase in employment and wages in Louisiana, contrary to predictions of economic loss 3</a></sup>.</p> Last week, a reddit user lit /r/ExperiencedDevs</code> on fire with this post 4</a></sup>:</p> I’m a freelance software engineer...I have noticed a large increase in projects where they paid a ton of money for an internal software and it does not work well at all...most of the time, the people hiring me aren’t technical and don’t understand what the problem is...the code was obviously AI generated. -- kcib</p> </blockquote> In short, a software engineer noticed across a variety of his freelance projects that nontechnical decision makers are using AI to deploy buggy, unmaintainable apps. Then, they call in the calvary to fix the mess.</p> It stands to reason that to keep these systems in production, and with their reputations on the line, many decision makers will hire freelance or full-time software engineers to clean up their AI-generated mess. If this is a widespread pattern, the job outlook for devs may be brighter than one would conclude merely from recent big tech layoffs and boardroom-promulgated narratives about AI replacing tech laborers.</p> The Internet is a shared ecosystem</h1> Even though this oil spill created jobs, we shouldn't encourage them. BP's damage to the Gulf ecosystem is deep and unfathomable.</p> Similarly, we all inhabit the waters and shores of a shared ecosystem called the internet. Low-quality information is the oil of the internet. When people pollute the information space with the unrefined output of LLMs, it spreads and lingers, degrading everyone's quality of life.</p> You don't have to be altruistic. BP lost reputation</em>, and on the internet, reputation is money. Reputation and quality information bring traffic, the lifeblood of companies. That's one reason many subreddits and other online communities disallow LLM-generated content. These communities know their value is connecting with real people.</p> The same goes for publications. I can't tell you how fast I hit the back button when I sense an article was written by an LLM. It feels impersonal, and my trust is broken. My thinking goes: if it wasn't worth the author's time to write, it isn't worth my time to read.</p> The issue with an oil spill isn't that the oil isn't valuable. The issue is where the oil is, which renders it both useless and damaging to the place it ends up.</p> References</h1> Deepwater Horizons Cleanup, 2010-08-19</a></li> as everyone called it then</li> Labor Market Impacts of the 2010 Deepwater Horizon Oil Spill and Offshore Drilling Momentum</a></li> The era of AI slop cleanup has begun</a></li> </ol> Dev Skills for the LLM Era 2025-06-10T00:00:00+00:00 There are certain skills software engineers can practice to further differentiate themselves from LLMs.</em></p> Books I am reading to uplevel my people skills </p> </div> In my last post, AI: Accelerated Incompetence</em>1</a></sup>, I claimed that LLMs can't replace human software developers, but I also wrote "there are certainly things you can do to further differentiate yourself from an LLM". In this post, I want to elaborate on the things I am doing to keep myself indispensable in the LLM age.</p> Chronologically, my focused journey to develop these skills began in 2023, before LLMs were quite as ubiquitous as today. In 2025, I have redoubled these efforts.</p> People Skills</h1> As a younger dev, I wanted it to be true that people skills didn't matter in software engineering: I viewed emotion as a distraction, preferring to get right to the important stuff like defining requirements and writing code. However, as I've gotten into the mid to late years of my career, I've come to understand that awareness and management of my emotions and those of others is at the center of professional work.</p> If you don't believe me, go scroll through /r/ExperiencedDevs</code> on Reddit. I see more posts about people problems than code or architecture.</p> If there's one thing a computer program can't do, it is offer genuine connection and empathy. When an LLM says nice things to me, it feels disingenuous. When a human uses kind words, it stands out. It makes me like them, and I feel like there's some good in this life, and I want to pass it forward.</p> At work, when you don't have any positional authority but need to collaborate, the best card in your hand is that people like and trust you. If you do have managerial authority over people, it's still in your best interest not to default to command-and-control schemes. As a leader, your example sets the tone for everyone else.</p> I've often half-joked that the best thing I've done for my career is get married. Why? My wife loves</em> to talk. Not to make noise, but as a means to connect with me on an emotional level. Younger Doug thought that words were merely for communicating information: e.g. for filing taxes, reading documentation, or writing requirements specifications. I now understand that I can talk to people to, you know, make them feel cared about</em> and to allow them to care about me</em>.</p> To that end, a couple of weeks ago I went on a binge and bought these books, pictured above:</p> How to Win Friends and Influence People by Dale Carnegie</li> Emotional Intelligence by Daniel Goleman</li> What Makes a Leader by Daniel Goleman</li> Getting Along by Amy Gallo</li> Dealing with Conflict by Amy Gallo</li> </ul> Whether its with these books or other resources, improving your people skills is not only likely to benefit your career, it might make you a happier person.</p> Managerial and Communication Skills</h1> Each of us is now a supervisor of machines. I never wanted to be a manager, but thankfully, there is a large body of knowledge for managing people. We just have to contextualize it to machines.</p> What is different about managing LLMs vs people?</p> With people, there is relationship, mutual trust (or lack of it), and shared context. Machines have none of that: there's only your prompt, the system prompt, the context window, and the model's training. Moreover, the model doesn't have feelings and doesn't require feedback and growth.</p> One of the most important aspects of management is communication.</p> LLMs are poor communicators, so you have to make up the difference. Unlike a talented direct report, LLMs don't yet seem generally able to ask the question-behind-the-question or to infer a larger context behind a prompt, or even ask for clarification.</p> For LLMs, the medium of communication is writing. Therefore, it's important to think clearly and write unambiguously. Be explicit, specific, and clear; and ask the LLM to respond the same way.</p> Before prompt engineering was a term, we had technical writing. I recommend you review Google's free courses2</a></sup>.</p> Advanced Software Engineering Skills</h1> Look for ways to advance your software engineering skills.</p> Now that each of us commands a team of fast, confident, often wrong virtual engineers, we can move up the value chain of engineering. LLMs buy us time to do more important things. We don't need to update the package dependencies by hand. We can ask an agent to, and with the time saved, we can talk with users or focus on refactoring the notification platform to an event-based architecture.</p> Where can we go to find advanced training in software engineering? Personally, I turn to books and courses. Paid courses are an excellent opportunity to differentiate from LLMs because being behind paywalls, their content is not scraped up with the rest of the publicly accessible internet. Books, legally or not, are more likely to be in the training dataset. Courses usually get you introduced to the instructor, whom you can reach e.g. by chat or email.</p> Books</h2> It's easy to rattle off a list of books. Here's a curated list that I have actually read, studied, applied in my work, and recommend to you:</p> A Philosophy of Software Design</em> by John Ousterhout</li> Grokking Simplicity</em> by Eric Normand</li> Working Effectively with Legacy Code</em> by Michael C Feathers</li> </ul> Courses</h2> In 2023, I bought access to Jimmy Koppel's Advanced Software Design</em> course3</a></sup>. It's been well worth it. The course touts these benefits, among others, which I can attest to:</p> Rise above subjective debates. Give concrete suggestions your team will understand and respect</li> Escape software influencer dogma. Get your own compass.</li> </ul> </blockquote> For a sample of Jimmy's teaching, have a look at his blog, for example this post4</a></sup>.</p> This year Udi Dahan made Distributed System Design Fundamentals</em> course5</a></sup> available free of charge. The full course is pretty expensive, so it's a fantastic opportunity. Some experienced colleagues of mine took it years ago and rave about it. I've just started it this week.</p> Business Skills</h1> My position in this post and the last has been that LLMs can't replace humans in skilled thought work. If your employer disagrees, there's one sure move you can make: you can employ yourself.</p> Yes, running your own business is allowed, and get this: customers don't care whether you use AI or not to make a product or service. They only care whether you solve a pain for them.</p> In 2023, I started a nascent software business. I quickly did what you're not supposed to do: I built a product based on a "cool idea". Instead of first finding customers and validating my idea, I jumped right in to coding. I spent hundreds of dollars and six months of nights and weekends. In the two years since, FitEdit6</a></sup> has earned a few hundred dollars. In December 2024, I repeated the mistake with Linklever7</a></sup>. In six months, it's made about $40.</p> I'm doing it a better way now. I'm breaking out of the "fail cycle" of building before validating. Last year, I bought access to Rob Walling's course The SaaS Launchpad</em>8</a></sup>. This year, I bought access to Amy Hoy and Alex Hillman's startup course 30x500 Academy</em>9</a></sup>. These courses are teaching me to focus on customers and marketing before writing a line of code.</p> In February 2025, I was fired from my job. No LLMs were involved. I was grateful to be welcomed back to my previous job, but I resolved then that I wanted more financial security. A salaried engineer is a business with one large customer. I'd rather have 500 small customers. My goal is to build a product business that earns me financial independence.</p> Conclusion</h1> Fellow dev, to stay economically valuable in the LLM age:</p> practice soft skills and emotional intelligence. Most of engineering is human interaction.</li> learn to write clearly. You're a manager of machines now.</li> focus on deep expertise and system-level thinking. That's your bread-and-butter. Machines can handle the boring parts.</li> consider starting a business. Then you can decide what mix of LLMs and humans to employ. Beware that coding is just one small part.</li> </ul> References</h1> AI: Accelerated Incompetence</a></li> Overview of technical writing courses</a></li> Advanced Software Design Course by Mirdin</a></li> Abstraction: Not What You Think It Is</a></li> Distributed Systems Design Fundamentals</a></li> FitEdit</a></li> Linklever</a></li> The SaaS Launchpad</a></li> 30x500 Academy</a></li> </ol> AI: Accelerated Incompetence 2025-05-19T00:00:00+00:00 In software engineering, over-reliance on LLMs accelerates incompetence. LLMs can't replace human critical thinking.</em></p> The text in this essay was written without any use of AI.</em></p> A speculative inverse correlation between LLM dependence and IQ </p> </div> By now much ink has dried on the wave of AI and LLMs which crashed upon the public consciousness in late 2022. As an experienced software engineer, I'd like to speak to two troubling engineering perspectives I've observed on LLMs.</p> "LLMs are my friend"</h1> I don't think anyone believes that a computer program is literally their companion, so let's address the euphemistic intent of the above phrase: namely that an LLM conveys magnificent benefits upon its user.</p> Engineers who view LLMs as an ally invariably prioritize or feel pressured to prioritize velocity; for them, production trumps perspicacity. While it's true that LLMs can deliver a lot of code quickly, their use carries a long tail of risks</em>.</p> Risks of using LLMs</h2> Output Risk</strong>. An LLM can give output that is blatantly incorrect, for example code that won't compile. More likely and dangerously, it can give output that is subtly and undetectably wrong, like logic bugs. The risk is elevated if the prompter is not qualified to evaluate the output, for example project managers prompting for source code.</li> Input Risk</strong>. An LLM does not challenge a prompt which is leading1</a></sup> or whose assumptions are flawed or context is incomplete. Example: An engineer prompts, "Provide a thread-safe list implementation in C#" and receives 200 lines of flawless, correct code. It's still the wrong answer, because the question should have been, "How can I make this code thread-safe?" and whose answer is "Use System.Collections.Concurrent</code>" and 1 line of code. The LLM is not able to recognize an instance of the XY problem2</a></sup> because it was not asked to.</li> Future Velocity</strong>. This is your typical "tech debt" argument, but more urgent. AI can degrade the quality of your codebase so fast</em>. Have you ever seen the fruits of hoarding disorder? From the outside, a house or apartment may look fine. But the inside is unsanitary, reprehensible, and nonfunctional. Developers are discovering that without strong guardrails, code produced by an LLM is like such a space.</li> User Infantilization</strong>. An extinction of talent will occur within individuals and organizations that outsource thinking and problem solving to LLMs: As senior engineers are deprived of the opportunity to learn through productive struggle, their existing problem solving and critical thinking skills atrophy: "Microsoft research on knowledge workers found that AI-driven confidence often comes at the expense of critical thinking"3</a></sup></li> "In a world pushing for “reflexive AI usage,” I’m advocating for something different: thoughtful, intentional collaboration with AI that preserves the essence of coding as a craft"4</a></sup></li> "LLMs give me finished thoughts, polished and convincing, but none of the intellectual growth that comes from developing them myself" 5</a></sup></li> </ul> </li> Junior engineers never develop such skills to begin with and so can never in turn mentor future junior engineers.</li> </ul> </li> Loss of Joy</strong>. Many developers are reporting that using AI robs them of flow state and the joy of creation.6</a></sup> AI-generated code is miserable to read and change.</li> </ul> In a future post, I plan to write about mitigations for each of these risks. Be sure to subscribe below if that sounds interesting.</p> "I'll become redundant"</h1> Source7</a></sup></p> No, you won't. That said, there are certainly things you can do to further differentiate yourself from an LLM. To stay on topic, I'll defer that to a future post. (Update: I wrote that post</a>)</em>.</p> There are two programming competences that LLMs cannot furnish: program theory</em> and program entropy</em>.</p> Program Theory</h2> ...programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand</p> </blockquote> -- Peter Naur, Programming as Theory Building</em>, 19858</a></sup></p> Naur was one of the greats in computing. He argued, against popular belief at the time, that a program is not its source code. Rather, the program is a shared mental construct: a theory</em> or design</em>. From that, the engineer derives code, but the work product of value is the design, not code.</p> To help you think about the difference between program theory and program text, consider this thought experiment: Imagine that two engineering teams of equivalent talent, A and B, are locked in separate rooms. Each team is told not to communicate with the other. Team A is tasked to write a program, for example a simple terminal-based Chess game. Team B just waits, plays real Chess, or whatever. When Team A is finished, their source code is handed to Team B. Now each team is asked in parallel to add a feature to the program, for example a virtual chess player so the game can be played solo. (We'll let Team A take a coffee break before they get started).</p> Question</em>: Which team will deliver a better solution?</p> Answer</em>: Team A, because those engineers have a fresh mental model of the program they just created, while Team B has none.</p> According to Naur, the theory matters because inevitably a program needs to be maintained</em>, i.e. modified after its initial creation. If all you have is the source code and not an internalized understanding of its design, the cost for those modifications will be higher. I think we can each remember a time we were introduced to a big existing codebase. At first our productivity was near zero. As we loaded the program theory into our mind, productivity rose.</p> LLMs and Program Theory</h3> LLMs as they currently exist cannot master a theory, design, or mental construct because they don't remember beyond their context window. Only humans can can gain and retain program theory.</p> Program Entropy</h2> Complexity is a fundamental opposing force of programming9</a></sup>, and it correlates with entropy.</p> ...program building is an entropy-decreasing process...program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence</p> </blockquote> -- Fred Brooks, The Mythical Man-Month</em>, 1975</p> Brooks, another prominent historical figure in computing, asserted that after initial construction, the changes made to a program can only make the source code more complex. However, changes made in harmony with the design will do so at a slower rate.</p> LLMs and Program Entropy</h3> An LLM is a token predictor. It works only at the level of text. It is not capable of working at a conceptual level: it doesn't reason about ideas, diagrams, or requirements specifications. Everyone who has prompted an LLM with a large chunk of code has beheld that the LLM tends to apply unnecessary and bizarre changes, and the longer the conversation drags on, the more it diverges. How often have you witnessed an LLM reduce</em> the complexity of a piece of code?</p> Only humans can decrease or resist complexity.</p> Conclusion</h1> We found wisdom for the LLM age by remembering what two forerunners of our discipline had to say about software design and complexity.</p> If you had hoped that AI would launch your engineering career to the next level, be warned that it could do the opposite. LLMs can accelerate incompetence.</em></p> If you're a skilled, experienced engineer and you fear that AI will make you unemployable, adopt a more nuanced view. LLMs can't replace human engineering.</em></p> The business allure of AI is reduced costs through commoditized engineering, but just like offshore engineering talent brings forth mixed fruit, LLMs fall short and open risks.</p> The AI hype cycle will eventually peak10</a></sup>. Companies which overuse AI now will inherit a long tail of costs, and they'll either pivot or go extinct. As such, the long-term value proposition for humans in engineering remains unchanged. The world still needs and will pay for technical skills and deep thinking in engineering.</p> AI will stick around, though. Use it as a tool, not a crutch, and continue to invest in the same fundamental engineering skills that were deemed valuable in 2019.</p> Next...</h1> Subscribe to my email list below. I plan to write more.</p> References</h1> Leading Question</a></li> The XY Problem</a></li> ThoughtWorks Technology Radar Volume 32</a></li> Coding as Craft: Going Back to the Old Gym</a></li> Thoughts on Thinking</a></li> The Hidden Cost of AI Coding</a></li> "I wonder if I'll become redundant"</a></li> Programming as Theory Building</a></li> Grug on Complexity</a></li> Gartner Hype Cycle</a></li> </ol> Tech Risk is Business Risk 2025-04-25T00:00:00+00:00 Tech risk is a business concern. Instead of vaguely bemoaning "tech debt" and hoping to "do things right", explain its potential costs with words the business understands.</em></p> </p> Tech Risks mapped onto Business Metrics </p> </div> Introduction</h2> 5 months ago, Reddit user Agent_Aftermath</em> posted in /r/AskProgramming</em>:</p> Why are so many companies so ambivalent or uncommitted to addressing tech-debt?</p> </blockquote> I think most engineers can empathize with this problem. We've all worked in codebases or infrastructures that smelled worse than a dirty diaper while our organization seemed unmoved or even resisted remediation.</p> The responses enumerated the many disincentives for addressing tech debt and presented only a few tenuous solutions. The top response succinctly captures the diagnosis:</p> It is more difficult to quantify the value of addressing tech debt as opposed to creating a new feature. --oofy-gang</p> </blockquote> The problem is not that tech debt is not real, nor that addressing it is frivolous. The pain lurks in quantifying it</em> and that there are apparently</em> more profitable uses of resources.</p> Note that for the rest of this article, I will use the term tech risk</em> instead of tech debt</em>. Why: In short, unlike mortgages, quality issues exact repayment suddenly and unpredictably. You can read my more detailed explanation here</a>.</p> What a Business Values</h2> Boardrooms always optimize for business metrics, and in capitalism, all business processes reduce to revenue and profit. If technical issues have no anticipated</em> effect on the bottom line, then leadership will readily prioritize other capitalizable work.</p> It would be ludicrous for a CTO to stand up in a board meeting and declare, "I'm happy to share that engineering has closed all open bugs in the backlog." This statement conveys no meaning to the board. It is unactionable techno-babble. Rather, the CTO knows to translate to business-speak: "I'm happy to share that this quarter we'll able to deploy 100% of our resources to new feature development, and because of this efficiency we will not renew our offshore QA contract, saving $3M over last quarter."</p> The key word above is anticipated</em>. There is high-quality research^[1</a>]</sup> and literature^[2</a>]</sup> demonstrating that internal tech quality is a business concern after all</em>. Indirectly, the board does</em> care about the engineering backlog, because engineering is a business unit, and business units cost or earn money.</p> Let's now focus on how you, a technical person, can present engineering concerns as business concerns. I have distilled your task into three steps:</p> Identify business metrics</li> Identify tech risks</li> Map tech risks onto business metrics</li> </ol> Funded startups, nonprofits, and businesses with philanthropic goals may have more nuanced motives than just net profit.</p> Identify Business Metrics</h2> If you're not sure what metrics your business is tracking, ask. They will usually be instantiations of "make more money" or "spend less money". However, revenues and profit may be linked to business processes with second-order metrics and performance indicators. For example, a food distributor must:</p> procure raw foods from producers</li> store raw foods cleanly</li> process and package foods efficiently and safely</li> find and retain customers</li> distribute food quickly to customers via truck, rail, or air before it spoils.</li> </ul> The overall business metric "net profit" will be a complex result of its many business processes.</p> Identify Tech Risks</h2> A tech risk is a technology that a business depends on that could have unexpected costs. Examples include a buggy internal codebase, outdated software^[3</a>]</sup>, servers past their vendor support window, and overcomplicated architectures. Quality is correlated with risk: high-quality software has less bugs and is easier to change.</p> These risks can cause events which negatively affect business metrics. For example:</p> An old software package contains a security flaw which results in data exfiltration.</li> A server fails and production is interrupted for a day.</li> A complicated architecture makes it expensive and slow to pivot the business to pursue a new revenue stream.</li> </ul> An FMEA^[4</a>]</sup> is helpful for prioritization, i.e. to decide which risks most merit mitigation. In this style of risk analysis, the risk is quantified in terms of its probability of occurrence and severity of the harm it could cause. You won't be able to fill in the severity column until you've completed the mapping to business metrics below.</p> Tech Risk</th> Probability of Occurrence</th> Severity of Harm</th></tr></thead> Security flaw in shipment DB</td> 1%</td> Low</strong>. Low-value shipment data exfiltrated</td></tr> Security flaw in patient DB</td> 1%</td> Severe</strong>. Protected Health Information exfiltrated</td></tr> Server disk fails</td> 10% after 5 years</td> Moderate</strong>. Production interrupted 1 day</td></tr> </tbody></table> Map Tech Risks onto Business Metrics</h2> Each risk presents one or more harms, each of which can realize cost to the business. Sometimes the path to a business metric will traverse one or more business processes. For example, it may not be immediately apparent how a damaged brand reputation can affect revenues, but a reduced sales funnel conversion rate will directly impact the bottom line.</p> Event</th> Business Metric Impacted</th></tr></thead> Low-value shipment data exfiltrated</td> None; who cares?</td></tr> Protected Health Information exfiltrated</td> Brand reputation damaged → Sales Funnel Conversion % (fewer new customers)</td></tr> Protected Health Information exfiltrated</td> Brand reputation damaged → Churn (customers leave)</td></tr> Production interrupted 1 day</td> Can’t fulfill committed sales → 1% loss of quarterly revenue</td></tr> </tbody></table> Step back for a second and compare the items on the left and right. The CEO's eyes may glaze over at the annual HIPAA training, but connecting a PHI breach convincingly to the company's sales conversion rate will make them listen.</p> Conversely, if you can't meaningfully associate a tech risk with a business cost, then you should accept that it is not a business priority. In the example above, we don't need to prioritize hardening the shipment DB.</p> Conclusion</h2> To convince your company to address "tech debt", map from tech risks to business metrics. Be prepared to discover that some tech risks don't matter.</p> Next...</h2> Subscribe to my email list below. I plan to write more.</p> References</h2> Code Red: The Business Impact of Code Quality</a></li> Accelerate: The Science of Lean Software and DevOps</a></li> End-of-life (EOL)</a></li> Failure Mode and Effects Analysis</a></li> </ol> It's Not Tech Debt. It's Tech Risk. 2025-04-09T00:00:00+00:00 Tech Debt becomes due swiftly and chaotically. Tech Risk is a better metaphor.</em></p> </p> Space Shuttle Challenger, 1986. </p> </div> What is Tech Debt?</h2> Tech debt</em> is a metaphor coined in 1992 by Ward Cunningham1</a></sup>.</p> In software engineering and adjacent disciplines like DevOps, it relates shortcuts on quality to financial debt.</p> We all know how financial debt works: you pay to use someone else's money. The amount you pay is proportional to the amount you borrow, how long you borrow it, and the interest rate. Borrowing can be a good idea since having money right now</em> enables valuable events like buying a house or starting a business.</p> Wardites hold that tech debt, like financial debt, incurs a penalty which over time compounds the amount of labor required to continue delivering. Etiologies vary: Some folks hold that tech debt originates when stakeholders intentionally</em> trade quality for delivery speed. Others say it happens inadvertently</em>. Some distinguish between reckless</em> and prudent</em> tech debt2</a></sup>.</p> Financial Debt is Predictable</h2> The tech debt metaphor appeals because it is easy to explain. Unfortunately, the metaphor is strained. Tech debt is not like financial debt</em>. Let's see why not.</p> Mortgages and other loan products are predictable</em>, for both the lender and the borrower. Borrowers repay on a steady schedule which has a specified maturity term, e.g. 15 or 30 years. The interest rate is fixed or mostly fixed. From day one, a spreadsheet predicts exactly how much principal and interest the borrower will still owe in month 137. For a bank, any loan is part of a diversified portfolio of many loans. While banks do fail3</a></sup>, stricter underwriting rules since 2008 have made it less common. Moreover, the societal harm of any individual bank failure is mitigated by distributing its cost across the entire banking system, facilitated by the full faith and assurance of the US Federal Reserve.</p> Tech Debt Detonates</h2> Here's how financial debt could be like tech debt. Imagine a hypothetical dystopian financial system in which banks could demand full mortgage repayment on a whim. We'll call these detonating mortgages</em>4</a></sup> — If you can't pay a few hundred thousand dollars right now</em>, you lose your home. No, you didn't do anything wrong, but the bank needs some liquidity today, so you and your children are now living in a hotel.</p> </p> A detonating mortgage </p> </div> Tech debt is like a detonating mortgage. Its payment becomes due unpredictably. Its timing is not fair or uniformly distributed.</p> The people who investigated the Challenger disaster5</a></sup> didn't have the term tech debt, but they listed quality shortcuts among the root causes. These quality shortcuts exposed the space program to risk. If NASA could have had at their disposal a spreadsheet predicting that the O-ring would fail on January 28, 1986, they would have decided not to fly.</p> Conclusion</h2> Quality shortcuts create risk. Some risk is necessary to reach our goals; how much we can tolerate depends on the expected reward6</a></sup>.</p> Let's not delude ourselves when we're taking risks. Deferred tech quality is not like a loan. The cost of quality shortcuts doesn't manifest on a schedule.</p> Use the term tech risk</strong>.</p> Next...</h2> Want to identify, prioritize, and mitigate tech risk? Subscribe to my email list below. I plan to write more about this topic.</p> References</h2> Ward Cunningham</a></li> Technical Debt Quadrant</a></li> Banking in Very Uncertain Times</a></li> Patrick McKenzie invented this thought experiment in Banking in Very Uncertain Times</em></li> Rogers Commission Report</a></li> The Most Important Thing</a></li> </ol> Why Programming is Hard 2024-02-16T00:00:00+00:00 Programming computers is hard because, as Hal put it</a>, it isn't about programming, and it isn't about computers.</p> A wizard conjuring a computer program. Generated by Dall-E</p> </div> Even the most mundane of programming issues are rooted in profound questions:</p> "Why are my dependencies broken?" => "What is causality?" ^[1</a>]</sup></li> "Should I check for null?" => "When can we know a program is correct? Design time, compile time, or run time?" ^[2,3</a>]</sup></li> "Why don't I understand this code?" => "What is memory, cognition, and language?" ^[4</a>]</sup></li> "Why is this program buggy?" => "What is a proof?" ^[5,6</a>]</sup></li> </ul> While you'll overhear the questions on the left rising from the desks of developers on a Tuesday afternoon, their answers are surprisingly elusive and timeless.</p> References</h2> Program Actions as Actual Causes</a></li> Null References: The Billion Dollar Mistake</a></li> The Three Levels of Software</a></li> Tacit knowledge</a></li> Curry-Howard correspondence</a></li> Would aliens understand lambda calculus?</a></li> </ol> Grounded Programming Pedagogy 2024-01-25T00:00:00+00:00 In the alum chat for Mirdin</a>, someone posted the following question, "Would it be better to start teaching beginners functional or imperative programming first?"</p> Pretending for a second that FP</a> and IP</a> are the only choices (they're not</a>), an answer depends on where your beginner comes from.</p> A meta-pedagogical (teaching about teaching) answer acknowledges that learning starts in a place the learner feels grounded</a> and connects them from there to new knowledge. For example, subitizing</a> is an innate ability. A developmentally normal child can instantly know how many objects are presented, for values up to about 5.</p> Image: How many dots are there? You just subitized.</p> </div> From there, you can teach a 5-year-old arithmetic, for example to add, by having them subitize groups of objects alongside numerals and the math symbol +</code>. This connects their innate notion of quantity to the abstract notion of numbers.</p> The MIT book and course SICP</a> is a masterpiece in programming pedagogy, and it falls heavily on the FP side. Watch Professor Sussman absolutely rip apart side effects in lecture 5A</a>. But not everybody "gets" this approach easily. Even Hal acknowledges in this Corecursive interview</a> that the FP approach didn't work for everyone:</p> In the very beginning days, we would teach a sort of short courses for MIT faculty and some of the electrical engineers would just get stuck. "You haven’t showed us how the transistors work". ...People think different ways. Some people have to be grounded on where they’re comfortable and for some people, well, it really is transistors.</p> </blockquote> Contrast that to somebody who knows what a function is, in the math sense. The machinery of a transistor</a>, of gates, sources, drains, and TTL</a> will be an irritating detail, like multiplying matrices by hand.</p> So in the dichotomy between introducing FP and IP first, the answer might depend on where the learner is coming from. I learned IP and OOP first because that's what material was available. I was first exposed to FP in college in the form of Scheme. It was disorienting. I couldn't count all the parentheses, let alone grok tail recursion. I wish it could have been presented to me grounded in terms of what I was already comfortable with, for example high school algebra.</p> I say, introduce multiple programming paradigms early, and ground it in what the learner knows. A fundamental programming skill is to think at multiple levels of abstraction</a>. The Haskell programmer needs to be aware that even monads at some point are just bits in a memory hierarchy, just as it's important for an assembly programmer to know that while register allocation is critical to performance, registers are not really what the program is about.</p> To close, let's ground this discussion in something we all know. To design a cathedral, the architect needs to know what bricks will be used. To build a cathedral, the bricklayer needs to envision the noble end to which each brick is set down.</p> A Design is a Mold for Code 2024-01-15T00:00:00+00:00 I'm always in search of good metaphors for software design. Good or not, here's one:</p> A Design is a Mold for Code</p> </blockquote> In manufacturing, a mold is a hollow shape that fills with fluid material which expands into the space and sets to form a casting.</p> Image: A useful mold. Generated by Dall-E</p> </div> Like in manufacturing, code fills the negative space</a> of a software design. Over time, code sets and becomes harder to change.</p> Imagine two engineering teams who independently "fill" (implement) a design, and the design is the set of standards for a web browser. The two implementations are Chrome and Firefox. The two browsers have independent codebases^[1</a>]</sup> which take vastly different shapes, but as far as web standards are concerned, the two are equal. You could switch from Chrome to Firefox (which I recommend</a>) and still browse compliant web pages with no discernible change.</p> Programmers who also like math sometimes call two pieces of code which can be swapped isomorphic</a> with respect to the spec.</p> It's important not to reverse the causality: a design causes the work product, not the converse. A mold causes a casting, and a software design causes code. Nevertheless, to some extent, one can go in reverse, i.e. reconstruct a mold from a casting or infer a design from code.</p> The reconstructed mold might lose some fidelity, like sharp edges or precise dimensions, but it's far worse for code. Looking at code without supplemental information, a new dev can only infer a dim, vague notion of its design. She might even sense the mind(s) behind the design. However, it would be costly if even possible to losslessly reconstruct the design, i.e. to such a fidelity that it could be the basis for an isomorphic implementation.</p> In pseudocode:</p> [Test] </span>fn Reverse_ProducesIsomorphicDesign() </span> let design1 : ... </span> let code1 = implement(design1) </span> let design2 = reverse(code1) </span> let code2 = implement(design2) </span> assert(isomorphic(code1, code2)) // Fails </span></code></pre> Above: The roundtrip from a design to code back to design is lossy.</p> There are a few reasons for this:</p> A codebase maybe too large to fit into a dev's head. The codebases for Chrome and Firefox are huge. Like the limited context window of ChatGPT, a human has limited working memory and forgets. Though with time and repetition, knowledge transitions to long-term memory.</li> It's hard to infer high-level concepts from low-level details. For example, decompiling assembly back to C.</li> Design and code have a many-to-many relationship. There can be many implementations that satisfy a design.</li> There can be many designs that result in the same code.</li> </ul> </li> </ul> This is a problem for software that outlives its creator(s). The software will languish unless knowledge is retained</a> and replicated</a>.</p> There are some things developers can do to keep their software alive:</p> Write down the design. Use natural language</a></li> Make the design apparent in the code</a></li> Use precise abstractions</a></li> Use effective</a> metaphors</a></li> Make the code fit in your head</a></li> </ul> Notes</h2> Firefox and Chrome are not truly independent by this definition. Plenty of people who have worked on one browser have also worked on the other. Moreover, as open source projects, both teams can see the other's code. Chromium source</a> and Firefox source</a></li> </ol>

Relieve your context anxiety with modular thinking

2026-02-23T00:00:00+00:00

Like electric vehicle range anxiety, context anxiety is that dread you feel when your LLM is almost out of context memory. Modules are your best tool for conserving LLM context.</em></p> </picture>

A photo of a puzzle piece fitting into its place. Source^{1</a></sup>
</p>
</div>}
In my post AI: Accelerated Incompetence</a>, my last sentence was:</p>

continue to invest in the same fundamental engineering skills that were deemed valuable in 2019</p> </blockquote>
Modular thinking is one of those timeless engineering skills.</p>
Why do modules matter?</h2> </picture>

I feel anxious when I see this message from Claude Code. </p> </div>
At the heart of OOP, FP, SOLID, DDD, SOA, CQRS, N-tier, bounded contexts, ports-and-adapters, onion, clean, event-driven, and all the other browbeaten software architecture jargon you're tired of hearing about, is the hope to decompose software into pieces which the human mind can comprehend.</p>
Smart humans can remember about 7 things at a time 2</a></sup> 3</a></sup>. (For me, it's closer to 3.) Meanwhile, computer programs can be staggeringly complex. The only way for humans to work on big programs is to think about small pieces of them at a time. If the human mind had infinite working memory and attention span, we would not need any structure in our programs. Our children would write 1,000,000 line monolithic god-functions, and we would smile at their cute simplistic work.</p>
Machines, like humans, have finite capacity.</p>
Today, 1M tokens is considered a cavernous context window, and most people settle for 200k, which is the default for Claude Code. Yet 1M tokens will only fit a small codebase, up to about 75k lines of code. For perspective, that accomodates about half of SQLite and 0.2% of the Linux kernel.</p>
Project</th> Lines of Code</th> Tokens</th></tr></thead>

SQLite</td> ~150K</td> ~2M</td></tr>
Linux kernel</td> ~40M</td> ~500M</td></tr> </tbody></table>
In this sense, what's good for humans is good for LLMs. If you're human and want to work on a large codebase, you have to be choosy about what to bring into your working memory. If you want to use an LLM to work on a large codebase, you have to be choosy what to bring into its context.</p>
So that's why modules matter. But what is a module, exactly?</p>
What is a module?</h2>
In programming, modules take many physical forms: a function, class, shared library, program, or a group of programs, an HTTP endpoint, or yet other forms.</p>
What makes any of these a module is:</p>

It exposes an interface</em> that conceals the secrets of its implementation</em></li>
It operates without using the secrets of other modules.</li> </ul>
What makes a good module?</h2>

A good module is deep</em>. Its interface is smaller than its implementation^{4</a></sup>. Reading its interface is a much lower cognitive burden than reading its implementation.</li>}
The preconditions</em> of a good module are well-defined. It is clear what the module assumes to be true about the world in order to run.</li>
The postconditions</em> of a good module are well-defined. It is clear what the module guarantees about its output and effects on the world.</li>
A good module relies only the guarantees of other modules. Code that relies on facts that other code does not guarantee may work today but can break in the future.</li>
The above facts make a module composable</em>. Module A depends on Module B, and Module B depends on Module C. Programs can be understood as fractal structures: even simple programs have a deep dependency tree</a>. My single page web app depends on my chosen web framework, which depends on the browser's JavaScript runtime and rendering engine, which depend on the operating system's system call APIs, which depend on device drivers, which depend on device firmware. Thankfully, my app doesn't have to know about TCP packet retry. All it knows is to call fetch()</code> so I can watch cat videos</a> in peace.</li> </ul> For modules with enough users, it's inevitable5</a></sup> that someone will eventually break modularity by depending on what happens to work right now (observable behavior) instead of what is guaranteed to work (contractual behavior). Don't do that.</p> See these references4</a></sup> 6</a></sup> for more detail and examples on what a module is.</p> What do modules have to do with LLMs?</h1> Program Correctness</h2> Modules let you and and LLMs reason about program correctness without thinking about the entire program. You or your LLM can change a part of the program, and as long as you don't break that module's public contract, the rest of the program will remain correct if it only depends on that contract</em>.</p> You can be confident that your changes don't break some other part of the program. This is a powerful capability. The payoff for strictness about contracts, preconditions, and postconditions is confidence to make changes</em>.</p> LLM Performance</h2> The chart below shows the well-known fact that LLMs as a rule perform worse as they ingest more data. If future LLMs perform better, the problem doesn't go away. The horizontal axis just gets longer.</p> </picture> LLM Performance vs Context Length </p> </div> Conversely, an LLM will perform better if you constrain how much information it ingests. The type signature of a function is usually smaller than the function's implementation. If your LLM has to look at the implementation of a function to determine how to use it, that will use more context.</p> Subagents</h2> Right now, subagents and agent orchestration are hot topics. Your main LLM agent, the orchestrator, hands off work to "subagents", each with an independent context. This conserves the context of the main agent, which improves task adhesion and alignment to your intentions.</p> You need something to hand off to the subagents. If your code is not modular, each subagent has to read more code to do its task. LLMs can do a pretty good job of making tool calls to e.g. grep</code> a codebase and pick out the relevant bits, but your design choices can make it easier or harder for them. Without modular code, tasks will take longer, incur greater token usage, and fill up contexts more quickly.</p> Moreover, you want each subagent to work independently. Without modularity, parallel agents can make conflicting changes to the same files.</p> Chats</h2> If you're copy-pasting code into an LLM chat window, a modular codebase will still help. In this case, you're playing the role of main agent. You have to curate what information the chat bot receives, so you're managing both your working memory and the LLM context.</p> Summary</h1> It's easy to make software that works right today. It's very hard to make software that keeps working in a changing environment</a>. You can do that by depending only on what your code's environment guarantees. That's modular thinking.</p> Look for words like interface, specification, contract, assumption, guarantee, precondition, postcondition, and invariant. Those are signals you're dealing with a module.</p> Modules are humanity's best hope to manage complex software.</p> References</h1> CC0 Pixnio</a></li> Code that Fits in Your Head</a></li> The Programmer's Brain</a></li> A Philosophy of Software Design (book)</a></li> Hyrum's Law</a></li> Modules Matter Most for the Masses</a></li> </ol> Don't believe "software never fails" 2026-01-02T00:00:00+00:00 The claim "software never fails" is cavalier and dangerous. It creates a mindset that itself leads to software failures.</em></p> On March 26, 2024, a container ship collided with one of the piers of the Francis Scott Key Bridge in Maryland. Within 30 seconds, the entire bridge had collapsed into the Patapsco River, killing six people1</a></sup>.</p> </picture> The collapsed Francis Scott Key Bridge </p> </div> I'm going to make a bold claim: the bridge didn't fail</em>.</p> That's right. Six people dead. $15M economic loss per day. The bridge didn't fail</em>.</p> After all, it did exactly what it was designed to do. The bridge was doomed the moment its blueprints were approved, before a single truss was machined, before a single pier was erected. From the moment of impact, its collapse was mechanically inevitable. A computer simulation could have easily predicted it.</p> How does my claim make you feel? How do you think the families of the dead would feel? They'd be ready to throw me off that bridge! Of course the bridge failed</em>. Look at it!</p> Savor your righteous indignation, because that is exactly what I felt when I read the post Software Never Fails</em>2</a></sup>.</p> It claims that:</p> The brief reason we can say software never fails is that software always does precisely what we told it to do. The outcome may be undesirable, and it may be unexpected, but the software itself never deviates from the instructions it was compiled into</em>.</p> </blockquote> The post offers a definition of failure:</p> A failure</em> is the event that occurs when a component first does what we designed it to, then something happens, and then the component no longer does what it was designed to do.</p> </blockquote> If we are to consistently apply this claim and definition, then the Francis Scott Key Bridge didn't fail. It did precisely what it was designed to do.</p> Software developers: Now imagine this kind of thinking applied to your codebase or to the medical device that keeps your grandmother alive. What could go wrong?</p> The failure of "software never fails"</h1> The syllogism presented in Software Never Fails</em> goes:</p> Premise 1</strong>: Failure means some component changed from working to non-working.</li> Premise 2</strong>: A program's compiled instructions never changes.</li> Conclusion</strong>: "Software is design-stuff. It doesn't fail ever."</li> </ol> Both premises are false, and so is the conclusion.</p> A faulty definition</h2> Premise 1 is false by its definition of failure.</p> The article cherry-picks a definition from hardware reliability engineering which says that failure is a state transition from working to non-working.</em> A capacitor dries out, and a bearing wears down. While this definition is suitable for hardware, it doesn't apply to programs. If a program "never deviates from the instructions it was compiled into", how can it transition? Software is definitionally excluded.</p> In When the Machine Metaphor Breaks Down</a>, I compared and contrasted software failures to hardware failures. I provided precise definitions of failure that apply to both:</p> Sins of commission</em>: The thing did something it was required not to.</li> Sins of omission</em>: The thing didn't do something it was required to.</li> Latent faults</em>: Bugs that are present but not causing observable failures.</li> Unmet expectations</em>: The user was surprised the thing did or didn't do something.</li> Compromised safety</em>: A hazard or loss occurred and the thing was involved, even if</em> it performed as required and expected.</li> </ul> I also showed that hardware and software fail for different causes</em>:</p> Hardware</em> fails as its internal physical condition deteriorates.</li> A program</em> fails as it environment changes, invalidating its assumptions and preconditions.</li> A codebase</em> fails as its design integrity dissolves and defect count rises.</li> </ul> Software is surprising</h2> Premise 2 is also false.</p> The claim "software never changes" wants us to to believe that programs are deterministic</em>, and if deterministic, then predictable, and therefore incapable of surprising us with failure.</p> note </div> note</strong></span> </div> Deterministic</em> means the same inputs produce the same outputs.</p> </div> </div> But programs are effectively nondeterministic. Yes, it's narrowly correct that compiled bytecode doesn't spontaneously mutate, but the argument conflates instructions</em> with execution</em>. A program's behavior depends not only on its bytecode but on its entire input space</em>. Proving a program correct requires proving it correct for all possible inputs and states</em>. As Dijkstra wrote, tests can show the presence of bugs, but never show their absence.</p> The dangers of believing "software never fails"</h1> Danger: Design and implementation conflated</h2> In building architecture, the distinction between design and construction is clear. Design is clay models and blueprints. Construction is pouring concrete and milling steel. Many structural failures happened because the construction did not follow the design^{3</a></sup>.</p>} Software also has distinct design and implementation activities. Sometime this is easy to see: it's common industry practice for a software architect to hand over a completed design specification to another implementation team, perhaps even an offshore one. The distinction is harder to observe if the same person does the designing and the implementing.</p> When the Therac-25 radiation therapy machine killed patients in the 1980s, investigators found that the software implementation</em> failed to properly sequence safety interlocks that the design</em> had specified. The design was sound, but the implementation was not. If we say "software is pure design," we have no vocabulary to disambiguate these failure modes, and we have no framework for preventing them.</p> Fix: Remember Verification and Validation</h3> Implementation errors are mitigated with verification</em>, i.e. asking the question, "did we build the thing correctly?" Design errors are mitigated with validation</em>, i.e. asking "are we building the correct thing?"</p> In A Design is a Mold for Code</a>, I show with examples the distinction between design and code.</p> Danger: Presbyopic causal chains</h2> The benevolent intent of the phrase "software never fails" is to encourage us to look beyond proximal causes of failure and seek distal causes, but it goes too far. A high-quality report on a commercial airliner crash will include both: the plane had a problem, and</em> a long causal chain of lax training, spotty maintenance, regulatory capture, and eroded safety culture from the very top allowed the problem to cascade into a catastrophe.4</a></sup>.</p> Presbyopia</em> is the inability of the eye to focus clearly on close objects5</a></sup>, and I'm concerned that people who believe "software never fails" will look for distant causes of failure while allowing the immediate ones to blur into invisibility.</p> What is a causal chain? Many of us have had or heard a conversation with a young child that went something like this:</p> Child: "Why can't I play on the grass?"</li> You: "Because it's wet, sweetie"</li> "Why?"</li> "Because I turned the valve on."</li> "Why?"</li> "Because the grass is turning brown"</li> "Why?"</li> "Because we live in New Mexico"</li> "Why?"</li> "Because your great-grandfather moved here in the '40s"</li> "Why?"</li> "Because the Wright Brothers invented the airplane. This made the Japanese attack on Pearl Harbor possible, which brought the USA into World War 2, which resulted in the founding of Los Alamos in 1943."</li> </ul> As you can see, the more removed a cause is from its effect, the less plausible its association and the less actionable any mitigation or prevention</strong>. A proximal cause to my grass being wet is I turned the valve on</em>. A distal cause is the Wright Brothers invented the airplane</em>. Removing the middle links from the chain of causality reveals the absurdity: "You can't play outside because airplanes exist."</p> If we believe a claim like "software never fails", we sever the proximal links in the causal chain. We'll cast a wide net looking for monsters in other castles but not the ones under our beds.</p> Fix: The 4-part filter for relevant causes</h3> Use this framework to discover relevant distal causes of failure without ignoring proximal causes. When engineers analyze why a failure happened or could happen, they privilege causes that:</p> are proximal</strong>, physically or temporally. My hand turned the valve, and a few seconds later the grass got wet. The Pearl Harbor attack and invention of the airplane happened long ago and far away.</li> exhibit agency</strong>. I chose</em> to turn the valve. I didn't choose where to found Los Alamos.</li> are controllable</strong>. Turning a valve is an event I can control (separately from choosing to). There's no action I can take about historical wars.</li> are normal and expected</strong>. Turning a valve is a common event. Wars aren't.</li> </ol> Danger: Latent defects ignored</h2> Bad metaphors breed bad decisions. What might actually happens if a software team internalizes the idea that "software never fails"?</p> If a team thinks software never fails, they might not allow themselves to believe their software could contain latent defects. They might think, "It works today, so it will always work." In their false confidence, they might skip testing, breeze through code review, dismiss bug reports, or skip error handling. This may let them ship quickly at first only to get bogged down fixing bugs later. In the meantime, hopefully those bugs don't cause harm to anyone.</p> Fix: Use better metaphors</h3> In It's Not Tech Debt. It's Tech Risk</a>, I show that the metaphors we use shape how seriously we take software problems.</p> Danger: Eroded alignment with nonexperts</h2> The phrase "software never fails" communicates the wrong thing to non-practitioners. When a politician or mid-level manager hears "X never fails", they hear, "We never have to think about that." They don't share your nuanced understanding. This mindset could lead to poor business decisions, for example when leadership says "ship it" or downsizes the QA team. It could also lead to public harm when an elected or appointed official makes an misguided public policy decision.</p> Fix: Use different words</h3> A professional structural engineer would never say "bridges never fail". Instead of propagating incorrect absolute statements like "software never fails", let your word choices build, not erode, alignment between you and decision makers. For guidance on translating technical risks into terms leadership will prioritize, see my post Tech Risk is Business Risk</a>.</p> What to do instead</h1> Change your Mindset</h2> When analyzing software failures:</p> Use precise definitions of failure and definitions appropriate for software.</li> Distinguish between design and implementation. Remember validation and verification.</li> Use my 4-part filter for relevant causes.</li> Use metaphors that discourage hubris and language that communicates the right things to leaders.</li> </ul> Concrete actions</h2> Pretend your next commit message or PR description will be printed on the front page of the New York Times</em></strong>. How will your word choices come across to your manager, CEO, elected government officials, or to the public?</li> In your next code review this week, identify one assumption</strong> about the environment that could become invalid. Are there places where the code assumes "this will always work"?</li> Bookmark this page.</strong> The next time a postmortem gets off track, share it.</li> Start a discussion</strong>. In e.g. Slack, Teams, or another collaboration tool, ask "how do we distinguish design errors from implementation errors?"</li> </ul> Summary</h1> Saying a program can't fail because its deployed bytecode doesn't change is like saying the Francis Scott Key Bridge didn't fail because its steel molecules obeyed the laws of physics. One might object, "Yo dawg, the bridge was destroyed by an external force, not internal failure", and this is exactly my point about software. Programs eventually experience external forces that their designers didn't anticipate. If we excuse the bridge because it wasn't designed to withstand a collision with a modern container ship, then we must equally excuse software that fails when its environment changes. The question is how designs can anticipate and accommodate these stresses</em>.</p> References</h1> Francis Scott Key Bridge Collapse</a></li> Software Never Fails</a></li> Hyatt Regency walkway collapse</a></li> Trial by Fire: The crash of Aeroflot flight 1492</a></li> Presbyopia</a></li> </ol> Related reading</h1> When the Machine Metaphor Breaks Down</a>. How software failures differ from hardware failures</li> A Design is a Mold for Code</a>. Why design precedes and shapes code, not the reverse</li> It's Not Tech Debt. It's Tech Risk.</a>. How the metaphors we use shape how seriously we take software problems</li> Tech Risk is Business Risk</a>. Translating technical risks into terms leadership will prioritize</li> It's Time to License Software Engineering</a>. Why society should train and recognize professional software engineers</li> </ul> When the Machine Metaphor Breaks Down 2025-12-11T00:00:00+00:00 While it's rare to see a sixty-year old car still running, COBOL is 65 years old and processes 95% of today's ATM transactions1</a></sup>. The world is full of critical infrastructure running on ancient software, so it's important to understand how software can fail.</em></p> Computer people have an old tradition of calling computers machines:</p> The ACM is the Association for Computing Machinery</em></li> Alan Turing's paper "Computing Machinery and Intelligence" introduced the Turing test</li> We all recognize phrases like "machine code", "machine learning", and "virtual machine".</li> </ul> Edsger Dijkstra was an influential computer scientist and highly active in the ACM, but he took issue with this organization's name. In 1988 he wrote2</a></sup> that computers represent a "radical novelty" and "sharp discontinuity" compared to anything before. Computers are not better typewriters.</p> It's human to try and understand new things in terms of things we already understand</a>, but programs are very different than machines. When we try to apply models of hardware failure to software, we risk not addressing software's unique failure modes.</p> How software and hardware fail differently</h1> Entropy spares nothing. A ball bearing wears out over time, and though a program never deteriorates, it can become obsolete in a changing world: just think of Adobe Flash or Java applets. Software developers are often asked keep old programs working, but even skillful and careful maintenance can make code messy and hard to understand.</p> Failure rates over time for hardware and software. Software looks very different than hardware. </p> </div> A model of hardware failure</h2> The blue line in the chart above looks like a bathtub, which is why it's called a bathtub curve3</a></sup>. It shows the lifespan of a typical machine. In the early days, a lot of devices experience "infant mortality". Perhaps a batch has a manufacturing defect or is damaged in transit. For those that survive, there is a long steady period of useful life. Then, the devices fail more frequently as their physical condition deteriorates.</p> For example, consider hard disks. Not solid state drives, but the old kind with spinning platters:</p> A hard disk drive. The top platter and actuator arm are visible. </p> </div> A hard disk drive has software running on it called "firmware", a term of art for software that interacts with hardware and will rarely be updated in the field. Hard disks also have lots of physical parts that can break: motors, bearings, actuator heads, and platters. If any of these fail, the disk has has failed and you can't read or write data. Most disk manufacturers publish a number called MTBF4</a></sup> which predicts about how long you can expect the disk to work. It's reasonable to expect a hard disk to survive continuous service for about three years. If you keep using it after that, you're on borrowed time: you're on the right side of the bathtub curve.</p> A model of software failure</h2> Looking back at the chart, the red line tells a story of software failure rates over time.</p> note </div> note</strong></span> </div> The term "software" is ambiguous. It can refer to a program or its source code. A program doesn't wear out or deteriorate, but its code can. Here, we're looking at an evolution of a program deployed over time from a changing codebase.</p> </div> </div> Stabilizing Phase</h3> Like hardware, there is an "infant mortality" phase. New programs tend to be buggy. The customers complain and the team scrambles to fix the bugs. Once the bugs are fixed, the program enters a stable phase with relatively few failures.</p> Maintenance Phase</h3> It continues that way until the boss walks in and says, "We need to add Feature X by Monday". The software team rushes to ship feature X by Monday. They succeed, but in their rush they add some new bugs. (This is why I avoid revision-zero software, e.g. I skipped macOS 15.7.0 and waited 14 days for 15.7.1). Customers complain, the team scrambles and fixes the bugs, and the waters calm down.</p> A while later, NIST announces a critical security vulnerability in one of the code's dependencies. The team scrambles to update or replace the dependency. In doing so, they create new bugs. Customers complain, the team scrambles to fix them, and the waters settle down again.</p> This happens many more times, and all the while something ominous is happening: the "floor" of defects is rising. The team can never get them down to how it was in the beginning before all of the new features and security patches. The code also doesn't feel as clean. It's messy and hard to understand. Its internal quality is deteriorating. A pile of quick fixes has obfuscated the elegance of the original design. Engineers leave, and new ones arrive who haven't internalized the design. Some people call all of this "tech debt", but tech risk</a> is a better metaphor.</p> End-of-life Phase</h3> Eventually maintenance becomes too expensive, and the program doesn't receive any more updates. It is announced deprecated or out-of-support and eventually removed from service.</p> Entropy affects software differently than hardware</h2> Notice that while hardware fails due to changes in its internal state, a program succumbs to entropy even if it doesn't change. Its shifting environment does the job. Maintaining software to accommodate its shifting environment postpones its demise but does not prevent it. As one of the greats in computing wrote:</p> Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.</p> </blockquote> -- Fred Brooks, The Mythical Man-Month, 1975</p> How software and hardware fail alike</h1> Software and hardware share some common notions of failure.</p> We've all seen this cartoon before. It takes outstanding communication to keep the spec, implementation, and user expectations in sync. This is exacerbated in situations where the user is not the customer or the designer is not the implementer. </p> </div> Failure to meet requirements</h2> A requirements-centric of failure view says that a system fails when it deviates from specified requirements</em>.</p> The IEEE defines failure as "the inability of a system or component to perform its required functions within specified performance requirements."5</a></sup> It distinguishes between a fault</em> (what most of us would call a bug</em> or defect</em>) and a failure</em>, which is the externally observable consequence.</li> If your mind has trouble distinguishing between fault and failure, consider latent faults</em>, which are bugs that are present in the software but not causing any observable failures. Latent faults often exist from the beginning but inspection (code review for software) and testing don't reveal them.</li> Examples for hardware: The O-rings of the Challenger solid rocket boosters had a latent fault</em> that caused them to deviate from their required</em> elasticity at low temperatures, resulting in the failure</em> of the seal to contain hot combustion gases.</li> The rivets on the Titanic had a latent fault</em>: they exceeded the required</em> maximum level of slag impurity. This made them brittle in the freezing North Atlantic waters. When ice contacted the hull plates, the rivets sheared rather than deformed, a failure</em> which caused ingress of seawater.</li> </ul> </li> </ul> </li> </ul> Failure to meet expectations</h2> A user-centric view of failure says that a system fails if it does does not meet user expectations</em>.</p> This broader view pits the end-user's expectations against the design and implementation.</li> This kind of failure is mitigated with early and iterative validation, by asking users to try it and give feedback.</li> For software: The design may have said "make the button green", and the button background may factually be #00FF00</code>, but if the user was expecting blue, the software has failed.</li> </ul> </li> For hardware: The original Segway was a well-functioning self-balancing vehicle. People expected</em> it to improve their urban transit. Instead, they got expensive scooters that attract ridicule. The device failed</em> to meet customer expectations. The Segway brand now emphasizes traditional scooters and e-bikes.</li> The Concorde jet met its spec: it achieved supersonic commercial flight. Passengers expected</em> fast, worldwide travel. Instead they got limited routes and extremely expensive fares. The jet failed</em> to find product-market fit. The last one was made in 1979.</li> </ul> </li> </ul> The processes for identifying these two kinds of failures are often called verification</strong> ("Did we built the thing right?") and validation</strong> ("Did we build the right thing?").</p> Failure to avoid hazard or loss</h2> There is a third, safety-centric view which says that a system fails if it contributes to a hazard or loss</em>.</p> This perspective is more common in safety-critical systems and public infrastructure.</li> For software: The Boeing 737 MAX MCAS software functioned as designed when the single angle of attack sensor failed: it thought the plane was in a nose-up attitude, so it commanded the nose to go down. While a requirement-centric view would say the software functioned as designed in this situation, nobody expects a plane to take an uncommanded nose dive. The failures are the two ground collisions which killed 346 people.</li> </ul> </li> For hardware: We say a bridge failed if it collapses, even if it's because a container ship collided into it, a load it was never required or expected to withstand.</li> The towers of the World Trade Center collapsed after airliners flew into them and the inferno weakened its metal structure. The doomed occupants may have hoped the buildings would stay up, but nobody expected</em> it, and no building code required</em> it. Still, nobody challenges a statement like, "the structure failed."</li> For space shuttle Challenger, the failure from this perspective is not the seal but the loss of crew and vehicle.</li> For Titanic, the failure from this perspective is not the rivets or hull plating but the hazard of the ship flooding with seawater and the resulting tragic loss of life.</li> </ul> </li> </ul> Summary</h1> Over time, software and hardware fail for different reasons:</p> Hardware</em> fails as its internal physical condition deteriorates.</li> A program</em> fails as it environment changes, invalidating its assumptions and preconditions.</li> A codebase</em> fails as its design integrity dissolves and defect count rises.</li> </ul> In an instant of time, software and hardware fail for the same reasons:</p> Sins of commission</em>: The system did something it was required not to.</li> Sins of omission</em>: The system didn't do something it was required to.</li> Unmet expectations</em>: The user was surprised the system did or didn't do something.</li> Compromised safety</em>: A hazard or loss occurred and the system was involved, even if</em> it performed as required and expected.</li> </ul> I plan to write more about software failures. See you soon.</p> References</h1> IBM: What is COBOL?</a></li> Dijkstra: On the cruelty of really teaching computing science</a></li> Wikipedia: Bathtub curve</a></li> Wikipedia: Mean Time Between Failures</a></li> IEEE 610.12 Standard Glossary of Software Engineering Terminology</a></li> </ol> Who wins in an Arms Race? 2025-10-28T00:00:00+00:00 In 2016, Nike shook up the sport of road running with its elite Vaporfly 4%</em> shoe. This shoe factually speeds up elite running times by 3-4% 1</a></sup>, which translates to 4-5 minutes over a 2 hour 30 minute marathon, an impassable advantage.</p> The Nike Vaporfly 4% </p> </div> Supershoes make you lose</h1> You might think that racing in these shoes would convey a career-defining advantage, but they actually do the opposite. The shoe only helps one to lose, not to win.</p> Initially, Nike restricted the supply to its sponsored athletes. Runners sponsored by any other brand were at a disadvantage. After a while, Nike made the shoes generally available, and competitors created similar shoes. Since then, the entire marathon elite field shows up wearing supershoes. They have to: those who don't are competing with a handicap.</p> In the men’s marathon at the 2016 Rio Olympics, most of the competitors wore the same green Nike shoe. Photo Credit: Norman Katende </p> </div> LLMs are supershoes</h1> LLMs are like the Vaporfly shoe in the bad ways and not in the good ways.</p> Whether used for writing software or marketing copy, LLMs promise to make businesses ship faster, both yours and your competitor's. If they live up to this promise (an uncertain claim 2</a></sup>), no winners are made; only losers who don't wear the new shoes.</p> At least supershoes don't take away fitness. You still have to run. In contrast, LLMs can make you dumber 3</a></sup>. They're mopeds, not bicycles 4</a></sup>.</p> The winners are the shoe makers, LLM providers, and GPU manufacturers.</p> Take aways</h1> In a competitive landscape, LLMs, like supershoes, do not result in your benefit.</li> LLM providers are SaaS 5</a></sup>. All SaaS wants to minimize customer turnover and to expand revenue. The SaaS dream is to capture customers and make them dependent on the SaaS offering.</li> LLM dependency is both competitive and cognitive. Competitive: All of your competitors are using LLMs. You have to keep up with the pack.</li> Cognitive: LLM use atrophies one's ability to think and reason, making one likely to prompt again. The dependency is self-reinforcing.</li> </ul> </li> </ul> References</h1> Nike's Controversially Fast New Shoes</a></li> Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</a></li> Your Brain on ChatGPT</a></li> LLMs are not Bicycles for the Mind</a></li> Software as a service</a></li> </ol> How to say no without authority 2025-10-22T00:00:00+00:00 At work, saying no to someone higher on the org chart is safe if you first earn their trust and if it's for the good of the business.</em></p> There's more than one type of authority. Being the boss is just one. The red circle is smallest because it's the weakest. </p> </div> Key ideas</h1> There's more than one kind of authority</li> Saying "no" without positional authority is a negotiation</li> Relational authority is a valid negotiating position</li> You earn relational authority when you make people feel understood</li> To understand someone, you first have to cool down, even if you disagree</li> When your "no" is aligned with business objectives (increased revenue or reduced costs), you can negotiate with a clear conscience.</li> To negotiate, you need to establish common ground.</li> You are the only factor you can control, so dig through your beliefs and worldviews for that common ground.</li> </ul> Why read this?</h1> Hackers lack soft skills. That includes me.</p> (For the general audience: the term "hacker" doesn't mean what you think. If you're comfortable with a command line interface, you're probably a hacker. Being mysterious and unethical is not part of the definition).</p> I showed a draft of this post to my wife, who is an elementary school teacher. She remarked, "In my line of work, this is very basic stuff. Like, not interesting at all. Do you think tech people need this post?" I don't know you, dear reader, but I've been in this game long enough to know that hacker culture does not esteem soft skills. We'd much rather learn Haskell or complain about the Apple tax. Seven employers have not subjected me to such training: what soft skills I possess, I've learned on my own. My hope is this post gives you a head start.</p> Intro</h1> About a week ago, a software developer, nickname him Thrug (a cousin of Grug</a>), submitted a post to the /r/ExperiencedDevs</code> subreddit with the title, Why do people think software development is easy?</em> In short, the Thrug's management asked for an unrealistic deliverable and did not appreciate his manner of protest:</p> [Management says], "it should be simple to build" ... I am always sort of at a loss as to how to even respond ... When I tell them no that’s not possible, they get upset and treat it as me being difficult ... One guy or a few are asked to build the impossible. 1</a></sup></p> </blockquote> Diagnosis</h1> To be brief, Thrug's employer exhibits the traits of a pathological organization. As for Thrug, his escalated emotional state blocks any capacity for empathy and persuasion.</p> A pathological organization</h2> Anyone who has read the book Accelerate</em> 2</a></sup> can quickly discern from the following red flags that Thrug is working amongst dysfunction. I wouldn't apply for a job at Thrug's company:</p> There's a hero culture</strong>. The company expects an individual to deliver what should take a team.</li> There's an absence of psychological safety</strong>. Messengers get shot. Blame is the norm. For being realistic, Thrug is labeled "difficult", though I think some of the fault rests with the manner of his pushback, which I'll get to in a moment.</li> Long project timelines imply infrequent deployments</strong>, which means each deployment carries greater risk, which contributes to...</li> High change failure rate</strong>. Bugs are the probable outcome of rushed projects. Remember "Good, fast, cheap. Choose two." 3</a></sup></li> No learning culture</strong>. According to Thrug, this isn't the first time the company has ignored developers and overpromised deliverables.</li> </ul> Thrug is in a tough environment; he isn't crazy.</p> Blinded by feelings</h2> At the same time, some the criticism from Thrug's management is valid.</p> His post includes charged, accusatory language and absolute statements:</p> "managers dictating what softwares to make"</li> "These people have no concept of technology"</li> "everyone thinks things can just be tossed into the magical black box"</li> "zillion other things"</li> "just flat out impossible"</li> </ul> From its length, I'm guessing the post took Thrug at least one coffee break to write. If this is the language Thrug deploys after cooling off a bit, I can infer he was at least as escalated when communicating with his management in realtime. This lends some validity to the label "difficult".</p> It's clear that Thrug feels strong negative emotions: he feels frustrated and exasperated at being misunderstood, isolated with no leadership in his corner, and defensive when accused of being the problem.</p> Like I said, Thrug has good reason to be upset: his worldviews are in conflict with his workplace.</p> He believes that craftsmanship is more important than speed.</li> He believes that expertise should be respected.</li> He believes management is theatrics.</li> </ul> Thrug is upset, but the problem is that he stays there and doesn't move forward toward constructive resolution. He's not exactly endearing himself to his leadership. Nobody in management can say, "Well, Thrug didn't perform as I expected, but he's a great guy and I enjoy having him around." As a result, the business misses out on his valuable perspective. It's up to Thrug to make a change, for his benefit and the benefit of the business.</p> Remedy</h1> Now that we know Thrug's failure mode (overheated emotions), we can prescribe a path to resolution:</p> Deescalate</li> Humanize</li> Negotiate</li> </ul> If Thrug can deescalate his emotions, he will be able to empathize with his management's perspective and to show he cares. He will be willing to listen, to back off from his hardline "no", and to negotiate options. All this will flip their perception. Once they believe he understands them and is on their side, they will be much more likely to listen to him.</p> Deescalate</h2> We can't think straight when we are escalated emotionally; the structure of the brain all but guarantees it. When activated, the amygdala mostly preempts the prefrontal cortex's ability to think ^{4</a></sup>. You have to calm down first.</p>} To calm down, take two minutes to close your eyes and breathe deeply. This can shift the brain out of crisis mode and let you start to think. Then, identify your feelings. Naming them is enough.</p> If you're face-to-face with someone, you may not have two minutes to calm down. While it is possible with practice to deescalate in a matter of seconds, it's best to ask for a few moments to think or to take a trip to the restroom.</p> Humanize</h2> Once you are calm enough to think somewhat objectively, your goal is to humanize the other party. Naming their probable feelings is a great start, because it bootstraps your empathy. Asking questions lets them clarify their feelings and perspective. Listening is like attaching a debugger to a person and inspecting their local variables and emotional call stack. Are they angry, fearful, insecure? Does their mom have cancer? Are they behind on their mortgage?</p> Example: Imagine you're Thrug. Think about the manager you're most upset with. You just left a meeting with them ten minutes ago. You've calmed down, or as much as one can in ten minutes. Now ask yourself, what is that manager going through? How do they feel? Here's one possible thought train:</p> Well, my manager said the Director of Product said we missed quarterly revenue goals and have customer retention issues. That sounds like bad news. The director probably had a tough meeting with the middle managers, from which our meeting resulted. I bet a lot of similar meetings are happening right now, so I'm not alone. This is probably from even higher up: I've often heard the private investor group backing us is pushy. This isn't my manager's fault. He's stuck between a rock and a hard place: the Powers That Be demand more of him, but I know it's not even possible. Moreover, I was really nasty to him about it. I know he's been a manager for only a year. He started out in customer service years ago. I remember him saying offhand a few weeks ago how the call center was way more fun. That's really saying something since our customers are sweat shops and drug cartels. Perhaps training could help my manager, but I know finance is never going to approve it. He's stuck where he's at. With just an associate's degree, he isn't qualified for such a well-compensated role anywhere else. He can't risk it anyway, since he has a wife and toddler and newborn at home. Man, he's in a tough spot.</p> </blockquote> Next, with a rational mind, Thrug can challenge his own worldviews. For example, he could come to accept that in business, the fundamental purpose of software development is to bring business value, not to practice craftsmanship. This happens to be a worldview that his manager very likely also holds. That's valuable common ground. Thrug can repeat to himself:</p> Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals. 5</a></sup></p> </blockquote> Negotiate</h2> Yes, negotiation. When you are saying "no" to someone and don't want to burn a bridge, you are in a negotiation, not just for the decision but also for the relationship.</p> Now that the other person is a human again in your mind, it's time to communicate with them. You're going to let them know that you are on their side. This addresses the ethos</em> of your negotiating position.</p> What is ethos?</h3> Ever heard of logos</em>, pathos</em> and ethos</em>? In rhetoric, logos</em> is the logic of your argument. Pathos</em> concerns how people feel about your argument. Ethos</em> is your credibility and authority. You can have a totally valid argument (good logos) and be unpersuasive because you are not trusted (poor ethos).</p> The ethos you project needs to be genuine. Don't apologize if you aren't. Don't insinuate you are working in someone's interest when you aren't. Don't ask how someone is doing if you don't care. If they get a whiff of your duplicity, you're in doo-doo.</p> Ethos is authority</h3> Most people when they hear the word authority</em> picture positional authority: an airline captain, your boss, a police officer. You listen to these people because of the consequences they can inflict, which in these cases includes removing you from a flight, firing you, or firing at you.</p> There are other kinds of authority, and the kind I'm advocating here is relational</em> authority. You listen to someone because you trust them. Relational authority is a kind of earned</em> authority. You're not handed relational authority when you become someone's boss: you have to earn it. Another kind of earned authority is expert</em> authority: You listen to someone because they've proven their competence. It's why you listen to your doctor even if she has poor bedside manners. Thrug's boss may have positional authority over Thrug, but we can infer from Thrug's post that he does not possess relational or expert authority with Thrug. In turn, Thrug doesn't possess any of these three forms of authority with his manager. It's not a good negotiating position.</p> The restorative conversation</h3> Here's how Thrug can instantly improve his negotiating position with his manager. The next time they talk, he can say, "I apologize for my response last time. I bet it feels like you're between a rock and a hard place, between senior leadership's demands and my rants." Thrug should be prepared for a potentially emotional response. That's good and means he is getting through and it's time to listen. If the response is bland, his inference might be incorrect, or his manager might be guarded. Obviously hasn't forgotten about recent interactions. In these cases, Thrug can simply ask, "How do you feel about all that?" When talked to this way, most people will mirror your gentleness and open up.</p> Relationship takes time</h3> In particularly broken relationships, it may take time and consistency to restore relational authority.</p> The strongest relationships have been cultivated over long periods of time. You should always seek to build rapport and trust with people because people are valuable in and of themselves 6</a></sup>. However, humans are eager help you if they like you. Ask your DevOps lead about his sickly mother and show genuine concern by following up once or twice. Months later, watch how your request to update the CI pipeline skips the weeks-long backlog and is done two hours after you asked. True story.</p> Make the offer</h3> With a relationship in place, the conversation can proceed on constructive terms. Thrug can make an initial offer: "I want to help deliver business value. I still think it'll be a long shot, but I'd like to talk about some options to cut scope so we can realistically ship Feature X on time." A back-and-forth follows from there.</p> In a negotiation, there is always a BATNA: the Best Alternative to a Negotiated Agreement. It's what happens if you and the other party fail to reach an agreement. In this case, there are at least two alternatives:</p> Thrug leaves the company.</li> The company commits to more than it can deliver. The company misses the revenue, loses to competitors, and Thrug is out of a job anyway.</li> </ul> I think for at least the short term, these two alternatives are worse for the business than negotiating an achievable deliverable.</p> Summary</h1> When you as a software developer have the insight that a software deliverable is unachievable, it's in the business's interest to negotiate another plan. The negotiated deliverable is more likely to be delivered on time and its business value realized. If you're in a blameful work culture, building relational authority first serves as job security.</p> This is how you say "no" in a way that earns respect:</p> Deescalate</strong> if necessary. Pause. Breathe. Collect yourself.</li> Humanize</strong>. See the other side's feelings. Let them feel understood and cared about. Listen. Ask questions.</li> Negotiate</strong>. Offer choices. Rarely do you actually utter the syllable "no".</li> They make a choice</li> They walk away feeling good because you're working for their benefit.</li> You're protected because they made the choice and they respect you.</li> </ul> </li> </ul> It's like the old Aesop fable of the North Wind and the Sun ^{7</a></sup>. The harder the wind blew, the tighter the man held on to his coat. The sun however warmed the man until he willingly removed it. Go forth and do likewise.</p>} References</h1> Why do people think software development is easy?</a></li> Accelerate (book)</a></li> Project management triangle</a></li> Emotional Intelligence (book)</a></li> Don't Call Yourself A Programmer</a></li> Psalm 139:14</a></li> The North Wind & the Sun</a></li> </ol> Recommended Reading</h1> Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations</em>. Portland: IT Revolution Press.</li> Goulston, M. (2010) Just listen: Discover the secret to getting through to absolutely anyone</em>. New York: AMACOM.</li> Goleman, D. (1995) Emotional intelligence: Why it can matter more than IQ</em>. New York: Bantam Books.</li> </ul> Addendum: A personal experience</h1> Thrug's post hits close to home, because I recently lived this experience. About eight months ago I was writing software at a company with a similar management culture. Communication was one-way, and the company was piling on tech debt faster than anyone could track. I was a vocal messenger but was viewed as the problem. Thrug's management is comparably patient: I was fired after eight weeks.</p> My dismissal was tragic. I knew my tech skills could have helped that company, but I never got to deploy them because of my manner of communication. It's tempting to blame the company, but I am the only factor which I know can change. In the months after, I came to regard soft skills as my new growth area: I bought no less than seven books on emotional intelligence, negotiation, conflict, and leadership. I also went through a counseling program at my church.</p> As my software engineering career stretches toward two decades, more often I've found it necessary to turn things down. The audience and context varies: sometimes I'm speaking with mentees, sometimes with peers, and often enough with superiors. Sometimes it's declining a change in a pull request. Sometimes it's in a meeting, talking the team down from a design decision. A couple of times, it was on the phone with a customer, tactfully helping them see the problem was on their end or that the software works as intended.</p> It's Time to License Software Engineering 2025-09-15T00:00:00+00:00 Society restricts who can design bridges or prescribe medicine, but it lets anyone market their software. AI accelerates the problem. It's in everyone's interest that states require licensure of software engineers.</em></p> AI has dramatically broadened who can create software. </p> </div> Why I care</h1> I almost became an engineer. From 2008, I spent three years pursuing a degree in computer engineering. I sat in engineering fundamentals and ethics courses with people who became engineers: mechanical, electrical, aerospace, nuclear, and others. We all planned to graduate, pass the FE exam, work a while, pass the PE exam, and become licensed professional engineers.</p> Then I switched to computer science. At the time, the thought of government adding red tape to my career path angered me. You don't even need a degree to become a software engineer. You just have to convince someone to hire you into that role.</p> Fast forward to 2025, and the barrier to entry is even lower. AI lets anyone ship software, and it's causing an avalanche of quality issues1</a></sup>. The classic engineering disciplines have spent centuries learning hard lessons about cost and quality. My profession could learn a thing or two from them.</p> Why do we have engineering licensure?</h1> How the US got started</h2> On March 12, 1928, the St. Francis dam near Los Angeles had stood for just under two years when it collapsed with almost no warning. Flood water surged down the San Francisquito Canyon, drowning over 400 people and causing extensive damage to man-made structures and the environment2</a></sup>.</p> The St. Francis Dam before its collapse </p> </div> The St. Francis Dam after its collapse. Just a small section of the wall remained, nicknamed "the tombstone". </p> </div> The immediate cause was the material on which the dam rested essentially dissolved and eroded away when it became wet. The proximal cause was the dam's designer was not qualified to design dams, and being self-taught, made critical errors in judgement. The root cause was a public policy which permitted the design and construction of dams by unqualified people and without independent review.</p> Just over a year after the collapse, California enacted its Civil Engineers Act, making it the second US state to regulate licensure of engineers. By 1947, all states had created similar licensure laws for Civil, Mechanical, and Electrical engineers.</p> Licensure lifts quality</h2> Market forces exert a downward pressure on cost and therefore on the quality of products and services. Licensure of professionals, combined with the standards they must follow, protects public welfare by exerting a counteracting upward force on quality.</p> Licensure sets a minimum bar for quality and upfront cost. Read more about cost in Objections</a>. </p> </div> For example, the International Building Code specifies a minimum load a roof must be able to hold up. Without this requirement, structural engineers might cave when pressured to find ways to make a building cheaper.</p> Another way to look at it is, competing firms find themselves in a prisoner's dilemma where they all could</em> cooperate and offer high quality goods. If any one of them defects by offering a lower price, then to maintain market share, all firms must follow suit. A Nash equilibrium emerges where nobody offers quality goods. Markets do segment; it's how Jones soda can exist in the same world as Coca Cola and Pepsi, but they all follow FDA standards for water quality.</p> Licensure lifts the Nash equilibrium to a higher level of quality, since no participant has the choice to cut certain costs.</p> Why license software engineers?</h1> Software can Harm People</h2> The collapse of a dam, bridge, or building is tragic when it costs lives. Bad medicine is also insidious: it promises a cure but delivers none or actively harms the patient.</p> Software is less tangible, but it can also cause widespread harm. For example:</p> In 2024, the global Crowdstrike outage brought down 18,000 customers and businesses, including retail stores, banks, universities, airports, hospitals, and governments3</a></sup>.</li> Tesla's self-driving cars marketed with "Autopilot" have a well-established record of killing occupants, pedestrians, and other drivers4</a></sup>.</li> </ul> Most of your line-of-business software isn't going to kill people, but software supply chains are complex: a library maintained by some guy in Nebraska5</a></sup> can show up in surprisingly mission-critical situations.</p> Society wants it</h2> Professional licensure ensures both adequate competence and a commitment to public good.</p> Physicians take countless exams and traditionally recite some derivative of the Hippocratic oath, promising to do no harm with their practice of medicine. Engineers take the FE exam and the PE exam. Both professions follow their respective code of ethics.</p> If software engineering had had any serious commitment to the ACM's 1999 code of ethics6</a></sup>, I think the world would look different today. The profession has exerted herculean efforts enabling these societal harms:</p> surveilling and amassing personal information</li> showing targeted ads for the highest bidder</li> rent-seeking and encrapifying marketplaces</li> </ul> Nonpractitioners want it</h2> By practitioners, I mean people who were already writing software for a living before LLMs or who could continue to do so if all LLMs were turned off.</p> AI lets anyone write software, even if they don't want to or are not qualified to.</p> Mr. Big Boss can now ask Suzy Secretary to write a bossware app that tracks remote employees' app use and keystrokes. As of 2025, Suzy can no longer say "I don't know how to do that" because with Claude Code and a 30 minute YouTube tutorial, she can. She has no code of ethics by which to say, "I won't do that". She also doesn't know that the AI-generated spyware transmits company data over the web in plaintext. Suzy shouldn't do this job, but she has no power to decline.</p> Mr. Big Boss could never ask Suzy to write him a pharmacy prescription. Why can he do that for software?</p> Practitioners want it</h2> In the US, the titles "Professional/Licensed/Registered Engineer" are legally protected7</a></sup>. Without a license, it's unlawful to market oneself using them.</p> In the U.S., most employment is at-will, meaning you can leave or be fired at any time and for any reason, but many states and federal laws create exceptions that can make a termination unlawful* when an engineer is fired for refusing to break the law or for protecting public health and safety. Many statutes are derived from the NSPE Code of Ethics.</p> I personally witnessed a professional engineer successfully sue our former employer which fired whim when he wouldn't sign off on a medical device he didn't think was ready to treat patients.</p> * I am not a lawyer.</p> Customers want it</h2> Licensure protects consumers, too. The threat of license revocation encourages responsible conduct.</p> If you want to build a house, your architect has to convince a licensed structural engineer to sign off on the mechanical soundness of the structure. If the house later collapses, you have legal recourse against the engineer.</p> Objections</h1> Licensure doesn't make software better</h2> It does improve outcomes for the existing professions, and in three ways:</p> It ensures a minimum level of competence.</li> It holds professionals accountable to a code of ethics.</li> It provides leverage for professionals to push back on forces that compromise quality.</li> </ol> In a world where I hold a license to practice software engineering, I hold the keys to shipping legally. I have leverage when my project manager pushes back against unit tests and tech debt. They don't hold a license, so they can't ship without me.</p> Licensure will get abused by political actors</h2> On the contrary, licensure would give our profession a backbone and a voice. There's no real unifying body for software engineers. For the vast majority of them, IEEE and ACM are irrelevant.</p> The AMA and NSPE respectively serve that role for physicians and engineers. Their age is measured in centuries, and they serve as nonpartisan beacons of ethics and professionalism.</p> Software will get more expensive.</h2> The upfront cost will increase, but a long tail of costs stemming from quality issues will decrease.</p> What's cheaper: to build a dam right or let it collapse and kill 400 people?</p> What's cheaper: Adding adequate driver awareness detection to Teslas or a fatal accident rate that's twice the industry average?8</a></sup></p> What costs more: Adding automated tests now or years of tech debt?</p> How can engineers without a license find work?</h2> The same as unlicensed civil engineers: behind the name of a licensed PE (professional engineer) who signs off on their work.</p> Can Suzy still write software?</h2> I think Suzy should be allowed to write her own apps and even share them with friends. To sell them or use them commercially, she needs a PE to sign off.</p> Like agriculture, you can grow your own tomatoes in your backyard, and you can bring a bag of them to share at work, but if you start selling them, the FDA might come visit.</p> When it comes to private activity, there are edge cases and nuance. It often comes down to scale and risk.</p> You can DIY a shed but not a house.</li> You can self-prescribe ibuprofen but not oxycodone.</li> </ul> Is software free speech?</h2> In the US, yes9</a></sup>, but causing public harm or encroaching on others' rights is not protected. For example, DeCSS was ruled to be illegal10</a></sup> even though it was free, noncommercial software.</p> Will some committee tell me how to do my job? (What language to use, where the curly braces go, etc.)</h2> I think some recommendations are to be called for. These would provide some of that upward force on quality against the market's tendency to push it down.</p> There is already pressure e.g. from NIST to use safer, more secure languages, like Rust or C# instead of C or C++. To that I would add QA standards like automated testing. Just like a structure must undergo inspection, it simply should not be a business's choice to skip QA of software.</p> However, the software profession has a great deal of variety in the work it does and the tools it uses. It also changes very rapidly, since the field is extremely young compared to e.g. civil engineering. We shouldn't enforce things we aren't certain are beneficial.</p> What mechanisms will there be to obtain licensure?</h2> Like the existing PE, there would be training and exams. There would be statements to sign, like a code of ethics, as well as continuing education.</p> Grandfathering and exemptions were common in the early days of the PE. These would be awarded based factors like education, length of career, and reputation.</p> Isn't this overkill? What about open-source projects?</h2> What I'm proposing is only for commercial software, at the end of the supply chain. A professional software engineer signs off on all of the packages and dependencies used in a product. Nothing changes for the guy working for free in Nebraska.</p> One of the differences between e.g. structural and software engineering is with the former, there is a clear distinction between design and construction, i.e. between idea and tangible artifact. A structural engineer doesn't necessary even see the constructed building whose structural designs he approved. Software engineers handle both.</p> I considered conceding that we could require sign-off just for certain high-risk classes of software like automotive, medical, and aerospace or high-scale classes like social media, but that does not address the problem of everyday people selling or commercially deploying AI-generated software whose quality they aren't able to ensure.</p> What about versioning? Do I need a sign off for minor revisions and bugfixes?</h2> Each public release of commercial software needs a sign off.</p> So my WordPress blog needs a sign off for each post?</h2> That's publishing, not software, and requiring sign off on writing would encroach on free speech.</p> How would it be enforced?</h2> Probably via courts. We should look to the existing engineering disciplines for guidance and precedent.</p> Conclusion</h1> Consider supporting licensure of sofware engineering. My aim is to protect:</p> society from a deluge of low-quality software of uncertain provenance.</li> the craft and integrity of the profession from unethical demands.</li> nonpractitioners of software engineering from being consigned by their employers to write software they aren't qualified to.</li> </ul> Next...</h1> Subscribe to my email list below. I plan to write more.</p> References</h1> 5 Vibe Coding Failures That Prove AI Can't Replace Developers Yet</a></li> Total Failure of St. Francis Dam Renewed Calls for Oversight</a></li> 2024 CrowdStrike-related IT outages</a></li> List of Tesla Autopilot crashes</a></li> XKCD: Dependency</a></li> The Software Engineering Code of Ethics and Professional Practice</a></li> Regulation and licensure in engineering</a></li> The 23 Most Dangerous Cars On The Road</a></li> Bernstein v. United States</a></li> Universal City Studios, Inc. v. Corley</a></li> </ol> About that Gig Fixing Vibe Code Slop 2025-09-05T00:00:00+00:00 AI now lets anyone write software, but it has limits. People will call upon software practitioners to fix their AI-generated code. Learn how to decide when to take that gig.</em></p> </p> Venn diagrams showing that AI lets more people make software </p> </div> Everyone Can Make Apps Now, sort of</h1> All over the world, people who haven't written a line of code in their life are using chat bots and coding agents to code up their dream product or app.</p> Venture capitalists, MBAs, project managers, visual designers, auto mechanics, and even elementary schoolers are now able to obtain working implementations of their ideas, and for a fraction of the cost. In 2025, you can pay a developer $10,000 to make a web app in a few weeks, or you can pay an AI company $2 in tokens and ship in a few hours.</p> But LLMs have limits:</p> Context windows limit how much code and conversation they can digest.</li> Hallucinations interpolate false information.</li> A lack of long term memory means each morning is the first day on the job.</li> A lack of emotion and metacognition means they don't get that "sinking feeling" that causes humans to pause and assess their choices.</li> </ul> The ease of starting a software project leaves nontechnical people surprised when they hit a productivity wall. This is a risk for them 1</a></sup>2</a></sup>, but an opportunity for you.</p> Practitioners to the Rescue, maybe</h1> When AI leaves a nontechnical person up a creek without paddle, there's a nonzero chance they'll be ready to hand the work over to a professional.</p> Why? Maybe their reputation is on the line, or their company's revenue. Maybe their proof of concept demonstrated enough value to justify making it production-ready. Maybe the prototype is already in production and its bugs have caused downtime, data loss, or customer churn.</p> Whatever the circumstance, if you can read and write software without LLMs, you can charge money to make their problem your problem. When you receive that call, email, or LinkedIn message, what will your answer be? Before you sign, should know what you're getting into.</p> You're dealing with a special category of legacy code</em>.</p> A Venn diagram showing that AI-generated code is a kind of legacy code </p> </div> What Is Legacy Code?</h1> You know you're dealing with legacy code when either:</p> It's a huge codebase</em>: even ideal code in high quantities is expensive to change.</li> You have low confidence</em> that the code is or will remain correct.</li> </ol> The general topic of legacy code maintenance is already addressed in some great literature 3</a></sup> 4</a></sup>. Since it's not currently within the abilities of LLMs to generate very large codebases, this short post will focus on confidence</em> .</p> How do we know when software is correct?</h2> Software practitioners have three gates at their disposal to catch software defects:</p> Runtime</strong>. The app has errors when you run it. They can surface to users, like error messages, or remain hidden, like logs. Unit and integration tests attempt to reveal errors at runtime.</li> Compile time</strong>. The compiler yells at you on your dev machine or in your CI/CD pipeline, because for example you can't do Dog fido = new Cat()</code>. You can't run code that won't compile.</li> Design time</strong>. This one is trickier. A bad design will compile and run. There's no automated way to evaluate design. It has to do with fulfilling the software's requirements, and in a way that keeps the software simple and easy to change. It's about structure and language: boxes and arrows; lexicons and metaphors. I explored the relationship between design and code in a previous post 5</a></sup>.</li> </ul> You will notice that runtime occurs after compile time, which occurs after design time. In general, it is most cost-effective to shift errors from runtime to compile time and from compile time to design time. When using an iterative SDLC, the time between each step is shortened, but the sequence is still there.</p> It's more expensive to fix code at runtime than at compile time and at compile time than at design time. </p> </div> Unfortunately, AI rushes people to runtime as fast as possible.</p> When don't we have confidence?</h2> From the previous points, we can see that there are a few reasons one might feel reluctant to change legacy code:</p> Runtime There are no automated regression tests.</li> There are no manual regression tests.</li> </ul> </li> Compile time The language doesn't discover errors at compile time, i.e. it is interpreted, dynamically typed, or weakly typed. Examples include Python, Ruby, and JavaScript.</li> The code doesn't make use of the compiler's type system. For example, it uses strings like "Employee"</code> and "Admin"</code> instead of value types like record Employee; record Admin</code> or enums like enum User { Employee, Admin }</code>.</li> </ul> </li> Design time There is no specification</strong>, i.e. what the code should do is not written down.</li> There is no documentation</strong>, i.e. no knowledge about the code's internal structure or design is written down.</li> There are no domain experts</strong>, i.e. people who know about the problem the software solves.</li> There are no code experts</strong>, such as a developer who wrote the code. The bus factor ^{6</a></sup> is zero.</li>} The code is badly structured</strong>, i.e. hard to understand and hard to change.</li> </ul> </li> </ul> Unique Qualities of AI-Generated Code</h2> AI-generated code inherits the characteristics of legacy code but is especially likely to have these:</p> Low internal quality</strong>. You'll hear this feedback from developers: "this code makes no sense". They may be referring the code's poor structure: duplication, inconsistent patterns, or to poor naming and a lack of coherence between the code and the part of the world the software interacts with. The result is the code is hard to understand and hard to change.</li> Low external quality</strong>. You'll hear this kind of feedback from non-developers, with phrases like, "this thing kind of does what I want, but not quite" or "this thing is so buggy". The code fulfills its requirements partially or circumstantially.</li> High Quantity to Age Ratio</strong>. You don't need AI to write legacy code. Humans do it every day, but AI can do it faster.</li> </ul> The Confidence Rubric</h1> My Confidence Rubric</em> evaluates the previously discussed factors to score how painful a codebase will be to work in.</p> Spec</th> Docs</th> Code Expert</th> Domain Expert</th> Tests</th> Structure</th> Language</th></tr></thead> ?</td> ?</td> ?</td> ?</td> ?</td> ?</td> ?</td></tr> </tbody></table> Let's fill in the rubric while considering two made-up scenarios.</p> Scenario: Auto Repair Shop</h2> James runs a car repair shop by himself. A YouTube video taught him to use Lovable to write a web app to track his small business's tools and parts inventory. It wrote the frontend in ReactJS and the backend in Python+Flask+Postgres. There are no automated tests, docs, or specs.</p> The app works fine, but Lovable has trouble iterating from there. After James hires two employees, he needs to track who has which tools. He asks Lovable what to do. It recommends implementing identity, authentication, and authorization. That's total overkill: OAuth is hard, and simpler solutions would work. James doesn't know that, so he says go for it. Lovable goes down a rabbit hole and can't get it working. After burning four hours on a Sunday afternoon, James gets fed up and the next day calls a software consultancy.</p> Here's our confidence rubric for James:</p> Spec</th> Docs</th> Experts (Code | Domain)</th> Tests</th> Structure</th> Language</th></tr></thead> ❌</td> ❌</td> ❌ | ✅</td> ❌</td> ?</td> ❌</td></tr> </tbody></table> There's only one thing going for this codebase, which is that you can talk to James.</p> Notice we haven't evaluated the structure. We won't cover that deep topic in this post, but if you have the opportunity, sign an NDA and have a look at the actual code before committing to the job.</p> Scenario: Small VC Firm</h2> Susan studied at a major USA university. She took a year of computer science before switching to an MBA. After college, she worked at Big Enterprise, but for the last five years she's worked at a small venture capital firm. She's not a developer, but she remembers some things from her CS program and her time at the Big Enterprise. She follows a tutorial and has Claude Code write a web app to manage her company's investment portfolio. She asks Claude to write the app using the same technologies she knew worked at the Big Enterprise: ASP.NET Core Blazor + Azure App Service and Managed SQL Database. Following the tutorial, she writes her requirements in a Requirements.md</code> file and has Claude and track its progress across sessions in a Tasks.md</code> file as well as keep a README.md</code> file up to date. She has Claude commit incrementally using git. There are integration tests which run the app in a browser against an in-memory DB, click buttons, fill and submit forms, and verify expected changes in the DB.</p> The app is a hit, since everyone at the firm is tired of sharing spreadsheets. Not long after, Susan retires, and her younger colleague Mark inherits her work. The app hums along unmaintained for months. One day, the CEO is out on the putting green and opens the web app on his phone. He notices that it looks terrible; Susan only ever tested it on her 1080p work monitor. He calls up Mark and asks him to make it mobile-friendly. Mark has no idea and is busy; he immediately reaches out to a consultant.</p> Here's our confidence rubric for Mark:</p> Spec</th> Docs</th> Experts (Code | Domain)</th> Tests</th> Structure</th> Language</th></tr></thead> ✅</td> ✅</td> ❌ | ❌</td> ✅</td> ?</td> ✅</td></tr> </tbody></table> Without even looking at the code, it's already looking like Mark's project will be easier to work on than James, but there is still more to consider.</p> Human and Organizational Factors</h1> Outside of the code, there are nontechnical factors that can affect any software project: there can be difficult personalities, tall management structures, entrenched political actors, and misaligned expectations.</p> While James' code might be a bigger lift, I'll bet working with him would be more straightforward than proxying through Mark to his CEO, who is busy flying around doing VC things. On the other hand, I'll bet that a VC firm is less price sensitive than a car repair shop.</p> Managing Expectations</h2> Stable</em> and boring</em> often describe legacy code. It's often old and business-critical, and an established organization understands that it takes time to turn a big ship.</p> With AI-generated code, there's none of the stable cash-minting of an old lethargic codebase. While it may not be business-critical, there is likely schedule pressure to fix the mess. To the business, you'll feel slow compared to the quick start AI gave them. You'll need communicate expectations and sell the business on the ROI of finishing the job.</p> Summary</h1> When you're offered a job or gig fixing AI-generated Code, give pause.</p> AI-generated code is a lot like legacy code, with some unique characteristics.</li> Not all AI-generated codebases are the same. Use the Confidence Rubric discern between them.</li> Consider the human and organizational factors.</li> Consider the customer's willingness to pay.</li> Bigger headaches merit bigger checks, because you bring more value to the business.</li> </ul> References</h1> It's Not Tech Debt. It's Tech Risk.</a></li> Tech Risk is Business Risk</a></li> Brutal Refactoring</a></li> Working Effectively with Legacy Code</a></li> A Design is a Mold for Code</a></li> Bus factor</a></li> </ol> LLMs are not Bicycles for the Mind 2025-08-25T00:00:00+00:00 LLMs are more like E-bikes. More assist makes you go faster, but provides less exercise.</em></p> A greenway and a sign that says "No Motor Vehicles". Source 1</a></sup> </p> </div> In 1980, Steve Jobs spoke,</p> What a computer is to me is it's the most remarkable tool that we've ever come up with, and it's the equivalent of a bicycle for our minds.</p> </blockquote> I don't think that LLMs are like bicycles for the mind. They are more like E-bikes.</p> Greenways and E-bikes</h1> A few nights ago, I was walking with my wife on the greenway. It's illuminated, so we were easily visible. We were absorbed in our conversation when an e-bike startled us, appearing around a curve and speeding toward us at about 25 miles per hour (~40 km/h). With just a couple of seconds to react, I pushed my wife out of danger and into the damp grass. As the two-tired vehicle passed, I turned toward its rider and yelled, "SLOW DOWN!". He muttered an unintelligible, unconcerned reply and motored on. As he disappeared from sight, I was angry and my wife was distraught.</p> The town where I live has excellent greenways, and I spend a lot of time running and walking on them. Seriously, it's thousands of miles each year, and over the last five years, I've noticed an increase in use of electric vehicles on our greenways: I've seen e-things of all kinds and sizes: bikes, scooters, skateboards, longboards, and unicycles.</p> I suppose people believe that the absence of a gas engine makes a vehicle acceptable on the greenway. The greenway is an outdoor space reserved for humans to exercise and enjoy nature. E-bikes that go too fast deter pedestrians from using it as intended.</p> I am not against electric vehicles on the greenway when riders use the throttle responsibly. Electric assist is a fantastic gateway to a healthy aerobic exercise regimen for those who could otherwise not even start. For example, my older colleague's e-bike gives him the confidence he needs get out in the first place.</p> LLMs are like E-bikes</h1> In software engineering, LLM use is like riding an e-bike on the greenway. Appropriate use comes down to how much "throttle" you use: how much cognitive effort you offload to the bot. Engineering is an intellectual and collaborative space where human minds work hard to solve business and technical problems. When you drop a mostly LLM-generated contribution into a chat or pull request, you zoom by on your LLM-moped, disrespecting and alienating those who are engaging their neocortex without assistance.</p> One of the rudest encounters I've had in my career was when a former colleague contradicted me in a technical discussion with an LLM-generated reply. Their screenshot of ChatGPT was lazy and reinforced an incorrect belief. It amounted to nothing more than an appeal to authority: the AI said it, so it must be true 2</a></sup>. The asymmetry principle 3</a></sup> helps explain why it was so frustrating: my counterpart effortlessly generated the LLM rebuttal which took me time and effort to parse and refute.</p> At my work, the ratio of LLM-generated code in pull requests is rising. The interesting thing about these is the author often doesn't seem quite as, well, authoritative</em>. It seems that when a robot has written the code, a higher portion of my feedback is ignored or answered unsatisfactorily. Since the point of a pull request is knowledge sharing and responding to feedback, it's a bit of a waste of time and feels more like a rubber-stamp request.</p> I'm not pointing fingers: In mid-2023, I completely over-relied on ChatGPT and shipped code I didn't understand to production. It took me three weeks to fix a defect that came up. Pretty embarrassing.</p> Summary</h1> You can depend on LLMs too much. Use them in a way that doesn't atrophy your mental fitness and doesn't exasperate your colleagues.</p> References</h1> What's Wrong with this Picture?</a></li> Appeal to Aithority</a></li> Brandolini's Law</a></li> </ol> Oil Spills Can Create Jobs 2025-08-09T00:00:00+00:00 LLM-generated code is like an oil spill. Real engineers will be there to mop up the mess - and collect the checks.</em></p> Workers clean up LLM slop. Source: US Coast Guard1</a></sup> </p> </div> The job outlook is not so bad</h1> In 2010, after the BP's oil rig Deepwater Horizons</em> dumped 3 billion barrels of oil into the Gulf of Mexico 2</a></sup>, at least $20B of BP's purse was redistributed to a massive mobilization of cleanup efforts. By 2014, this had resulted in a net increase in employment and wages in Louisiana, contrary to predictions of economic loss 3</a></sup>.</p> Last week, a reddit user lit /r/ExperiencedDevs</code> on fire with this post 4</a></sup>:</p> I’m a freelance software engineer...I have noticed a large increase in projects where they paid a ton of money for an internal software and it does not work well at all...most of the time, the people hiring me aren’t technical and don’t understand what the problem is...the code was obviously AI generated. -- kcib</p> </blockquote> In short, a software engineer noticed across a variety of his freelance projects that nontechnical decision makers are using AI to deploy buggy, unmaintainable apps. Then, they call in the calvary to fix the mess.</p> It stands to reason that to keep these systems in production, and with their reputations on the line, many decision makers will hire freelance or full-time software engineers to clean up their AI-generated mess. If this is a widespread pattern, the job outlook for devs may be brighter than one would conclude merely from recent big tech layoffs and boardroom-promulgated narratives about AI replacing tech laborers.</p> The Internet is a shared ecosystem</h1> Even though this oil spill created jobs, we shouldn't encourage them. BP's damage to the Gulf ecosystem is deep and unfathomable.</p> Similarly, we all inhabit the waters and shores of a shared ecosystem called the internet. Low-quality information is the oil of the internet. When people pollute the information space with the unrefined output of LLMs, it spreads and lingers, degrading everyone's quality of life.</p> You don't have to be altruistic. BP lost reputation</em>, and on the internet, reputation is money. Reputation and quality information bring traffic, the lifeblood of companies. That's one reason many subreddits and other online communities disallow LLM-generated content. These communities know their value is connecting with real people.</p> The same goes for publications. I can't tell you how fast I hit the back button when I sense an article was written by an LLM. It feels impersonal, and my trust is broken. My thinking goes: if it wasn't worth the author's time to write, it isn't worth my time to read.</p> The issue with an oil spill isn't that the oil isn't valuable. The issue is where the oil is, which renders it both useless and damaging to the place it ends up.</p> References</h1> Deepwater Horizons Cleanup, 2010-08-19</a></li> as everyone called it then</li> Labor Market Impacts of the 2010 Deepwater Horizon Oil Spill and Offshore Drilling Momentum</a></li> The era of AI slop cleanup has begun</a></li> </ol> Dev Skills for the LLM Era 2025-06-10T00:00:00+00:00 There are certain skills software engineers can practice to further differentiate themselves from LLMs.</em></p> Books I am reading to uplevel my people skills </p> </div> In my last post, AI: Accelerated Incompetence</em>1</a></sup>, I claimed that LLMs can't replace human software developers, but I also wrote "there are certainly things you can do to further differentiate yourself from an LLM". In this post, I want to elaborate on the things I am doing to keep myself indispensable in the LLM age.</p> Chronologically, my focused journey to develop these skills began in 2023, before LLMs were quite as ubiquitous as today. In 2025, I have redoubled these efforts.</p> People Skills</h1> As a younger dev, I wanted it to be true that people skills didn't matter in software engineering: I viewed emotion as a distraction, preferring to get right to the important stuff like defining requirements and writing code. However, as I've gotten into the mid to late years of my career, I've come to understand that awareness and management of my emotions and those of others is at the center of professional work.</p> If you don't believe me, go scroll through /r/ExperiencedDevs</code> on Reddit. I see more posts about people problems than code or architecture.</p> If there's one thing a computer program can't do, it is offer genuine connection and empathy. When an LLM says nice things to me, it feels disingenuous. When a human uses kind words, it stands out. It makes me like them, and I feel like there's some good in this life, and I want to pass it forward.</p> At work, when you don't have any positional authority but need to collaborate, the best card in your hand is that people like and trust you. If you do have managerial authority over people, it's still in your best interest not to default to command-and-control schemes. As a leader, your example sets the tone for everyone else.</p> I've often half-joked that the best thing I've done for my career is get married. Why? My wife loves</em> to talk. Not to make noise, but as a means to connect with me on an emotional level. Younger Doug thought that words were merely for communicating information: e.g. for filing taxes, reading documentation, or writing requirements specifications. I now understand that I can talk to people to, you know, make them feel cared about</em> and to allow them to care about me</em>.</p> To that end, a couple of weeks ago I went on a binge and bought these books, pictured above:</p> How to Win Friends and Influence People by Dale Carnegie</li> Emotional Intelligence by Daniel Goleman</li> What Makes a Leader by Daniel Goleman</li> Getting Along by Amy Gallo</li> Dealing with Conflict by Amy Gallo</li> </ul> Whether its with these books or other resources, improving your people skills is not only likely to benefit your career, it might make you a happier person.</p> Managerial and Communication Skills</h1> Each of us is now a supervisor of machines. I never wanted to be a manager, but thankfully, there is a large body of knowledge for managing people. We just have to contextualize it to machines.</p> What is different about managing LLMs vs people?</p> With people, there is relationship, mutual trust (or lack of it), and shared context. Machines have none of that: there's only your prompt, the system prompt, the context window, and the model's training. Moreover, the model doesn't have feelings and doesn't require feedback and growth.</p> One of the most important aspects of management is communication.</p> LLMs are poor communicators, so you have to make up the difference. Unlike a talented direct report, LLMs don't yet seem generally able to ask the question-behind-the-question or to infer a larger context behind a prompt, or even ask for clarification.</p> For LLMs, the medium of communication is writing. Therefore, it's important to think clearly and write unambiguously. Be explicit, specific, and clear; and ask the LLM to respond the same way.</p> Before prompt engineering was a term, we had technical writing. I recommend you review Google's free courses2</a></sup>.</p> Advanced Software Engineering Skills</h1> Look for ways to advance your software engineering skills.</p> Now that each of us commands a team of fast, confident, often wrong virtual engineers, we can move up the value chain of engineering. LLMs buy us time to do more important things. We don't need to update the package dependencies by hand. We can ask an agent to, and with the time saved, we can talk with users or focus on refactoring the notification platform to an event-based architecture.</p> Where can we go to find advanced training in software engineering? Personally, I turn to books and courses. Paid courses are an excellent opportunity to differentiate from LLMs because being behind paywalls, their content is not scraped up with the rest of the publicly accessible internet. Books, legally or not, are more likely to be in the training dataset. Courses usually get you introduced to the instructor, whom you can reach e.g. by chat or email.</p> Books</h2> It's easy to rattle off a list of books. Here's a curated list that I have actually read, studied, applied in my work, and recommend to you:</p> A Philosophy of Software Design</em> by John Ousterhout</li> Grokking Simplicity</em> by Eric Normand</li> Working Effectively with Legacy Code</em> by Michael C Feathers</li> </ul> Courses</h2> In 2023, I bought access to Jimmy Koppel's Advanced Software Design</em> course3</a></sup>. It's been well worth it. The course touts these benefits, among others, which I can attest to:</p> Rise above subjective debates. Give concrete suggestions your team will understand and respect</li> Escape software influencer dogma. Get your own compass.</li> </ul> </blockquote> For a sample of Jimmy's teaching, have a look at his blog, for example this post4</a></sup>.</p> This year Udi Dahan made Distributed System Design Fundamentals</em> course5</a></sup> available free of charge. The full course is pretty expensive, so it's a fantastic opportunity. Some experienced colleagues of mine took it years ago and rave about it. I've just started it this week.</p> Business Skills</h1> My position in this post and the last has been that LLMs can't replace humans in skilled thought work. If your employer disagrees, there's one sure move you can make: you can employ yourself.</p> Yes, running your own business is allowed, and get this: customers don't care whether you use AI or not to make a product or service. They only care whether you solve a pain for them.</p> In 2023, I started a nascent software business. I quickly did what you're not supposed to do: I built a product based on a "cool idea". Instead of first finding customers and validating my idea, I jumped right in to coding. I spent hundreds of dollars and six months of nights and weekends. In the two years since, FitEdit6</a></sup> has earned a few hundred dollars. In December 2024, I repeated the mistake with Linklever7</a></sup>. In six months, it's made about $40.</p> I'm doing it a better way now. I'm breaking out of the "fail cycle" of building before validating. Last year, I bought access to Rob Walling's course The SaaS Launchpad</em>8</a></sup>. This year, I bought access to Amy Hoy and Alex Hillman's startup course 30x500 Academy</em>9</a></sup>. These courses are teaching me to focus on customers and marketing before writing a line of code.</p> In February 2025, I was fired from my job. No LLMs were involved. I was grateful to be welcomed back to my previous job, but I resolved then that I wanted more financial security. A salaried engineer is a business with one large customer. I'd rather have 500 small customers. My goal is to build a product business that earns me financial independence.</p> Conclusion</h1> Fellow dev, to stay economically valuable in the LLM age:</p> practice soft skills and emotional intelligence. Most of engineering is human interaction.</li> learn to write clearly. You're a manager of machines now.</li> focus on deep expertise and system-level thinking. That's your bread-and-butter. Machines can handle the boring parts.</li> consider starting a business. Then you can decide what mix of LLMs and humans to employ. Beware that coding is just one small part.</li> </ul> References</h1> AI: Accelerated Incompetence</a></li> Overview of technical writing courses</a></li> Advanced Software Design Course by Mirdin</a></li> Abstraction: Not What You Think It Is</a></li> Distributed Systems Design Fundamentals</a></li> FitEdit</a></li> Linklever</a></li> The SaaS Launchpad</a></li> 30x500 Academy</a></li> </ol> AI: Accelerated Incompetence 2025-05-19T00:00:00+00:00 In software engineering, over-reliance on LLMs accelerates incompetence. LLMs can't replace human critical thinking.</em></p> The text in this essay was written without any use of AI.</em></p> A speculative inverse correlation between LLM dependence and IQ </p> </div> By now much ink has dried on the wave of AI and LLMs which crashed upon the public consciousness in late 2022. As an experienced software engineer, I'd like to speak to two troubling engineering perspectives I've observed on LLMs.</p> "LLMs are my friend"</h1> I don't think anyone believes that a computer program is literally their companion, so let's address the euphemistic intent of the above phrase: namely that an LLM conveys magnificent benefits upon its user.</p> Engineers who view LLMs as an ally invariably prioritize or feel pressured to prioritize velocity; for them, production trumps perspicacity. While it's true that LLMs can deliver a lot of code quickly, their use carries a long tail of risks</em>.</p> Risks of using LLMs</h2> Output Risk</strong>. An LLM can give output that is blatantly incorrect, for example code that won't compile. More likely and dangerously, it can give output that is subtly and undetectably wrong, like logic bugs. The risk is elevated if the prompter is not qualified to evaluate the output, for example project managers prompting for source code.</li> Input Risk</strong>. An LLM does not challenge a prompt which is leading1</a></sup> or whose assumptions are flawed or context is incomplete. Example: An engineer prompts, "Provide a thread-safe list implementation in C#" and receives 200 lines of flawless, correct code. It's still the wrong answer, because the question should have been, "How can I make this code thread-safe?" and whose answer is "Use System.Collections.Concurrent</code>" and 1 line of code. The LLM is not able to recognize an instance of the XY problem2</a></sup> because it was not asked to.</li> Future Velocity</strong>. This is your typical "tech debt" argument, but more urgent. AI can degrade the quality of your codebase so fast</em>. Have you ever seen the fruits of hoarding disorder? From the outside, a house or apartment may look fine. But the inside is unsanitary, reprehensible, and nonfunctional. Developers are discovering that without strong guardrails, code produced by an LLM is like such a space.</li> User Infantilization</strong>. An extinction of talent will occur within individuals and organizations that outsource thinking and problem solving to LLMs: As senior engineers are deprived of the opportunity to learn through productive struggle, their existing problem solving and critical thinking skills atrophy: "Microsoft research on knowledge workers found that AI-driven confidence often comes at the expense of critical thinking"3</a></sup></li> "In a world pushing for “reflexive AI usage,” I’m advocating for something different: thoughtful, intentional collaboration with AI that preserves the essence of coding as a craft"4</a></sup></li> "LLMs give me finished thoughts, polished and convincing, but none of the intellectual growth that comes from developing them myself" 5</a></sup></li> </ul> </li> Junior engineers never develop such skills to begin with and so can never in turn mentor future junior engineers.</li> </ul> </li> Loss of Joy</strong>. Many developers are reporting that using AI robs them of flow state and the joy of creation.6</a></sup> AI-generated code is miserable to read and change.</li> </ul> In a future post, I plan to write about mitigations for each of these risks. Be sure to subscribe below if that sounds interesting.</p> "I'll become redundant"</h1> Source7</a></sup></p> No, you won't. That said, there are certainly things you can do to further differentiate yourself from an LLM. To stay on topic, I'll defer that to a future post. (Update: I wrote that post</a>)</em>.</p> There are two programming competences that LLMs cannot furnish: program theory</em> and program entropy</em>.</p> Program Theory</h2> ...programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand</p> </blockquote> -- Peter Naur, Programming as Theory Building</em>, 19858</a></sup></p> Naur was one of the greats in computing. He argued, against popular belief at the time, that a program is not its source code. Rather, the program is a shared mental construct: a theory</em> or design</em>. From that, the engineer derives code, but the work product of value is the design, not code.</p> To help you think about the difference between program theory and program text, consider this thought experiment: Imagine that two engineering teams of equivalent talent, A and B, are locked in separate rooms. Each team is told not to communicate with the other. Team A is tasked to write a program, for example a simple terminal-based Chess game. Team B just waits, plays real Chess, or whatever. When Team A is finished, their source code is handed to Team B. Now each team is asked in parallel to add a feature to the program, for example a virtual chess player so the game can be played solo. (We'll let Team A take a coffee break before they get started).</p> Question</em>: Which team will deliver a better solution?</p> Answer</em>: Team A, because those engineers have a fresh mental model of the program they just created, while Team B has none.</p> According to Naur, the theory matters because inevitably a program needs to be maintained</em>, i.e. modified after its initial creation. If all you have is the source code and not an internalized understanding of its design, the cost for those modifications will be higher. I think we can each remember a time we were introduced to a big existing codebase. At first our productivity was near zero. As we loaded the program theory into our mind, productivity rose.</p> LLMs and Program Theory</h3> LLMs as they currently exist cannot master a theory, design, or mental construct because they don't remember beyond their context window. Only humans can can gain and retain program theory.</p> Program Entropy</h2> Complexity is a fundamental opposing force of programming9</a></sup>, and it correlates with entropy.</p> ...program building is an entropy-decreasing process...program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence</p> </blockquote> -- Fred Brooks, The Mythical Man-Month</em>, 1975</p> Brooks, another prominent historical figure in computing, asserted that after initial construction, the changes made to a program can only make the source code more complex. However, changes made in harmony with the design will do so at a slower rate.</p> LLMs and Program Entropy</h3> An LLM is a token predictor. It works only at the level of text. It is not capable of working at a conceptual level: it doesn't reason about ideas, diagrams, or requirements specifications. Everyone who has prompted an LLM with a large chunk of code has beheld that the LLM tends to apply unnecessary and bizarre changes, and the longer the conversation drags on, the more it diverges. How often have you witnessed an LLM reduce</em> the complexity of a piece of code?</p> Only humans can decrease or resist complexity.</p> Conclusion</h1> We found wisdom for the LLM age by remembering what two forerunners of our discipline had to say about software design and complexity.</p> If you had hoped that AI would launch your engineering career to the next level, be warned that it could do the opposite. LLMs can accelerate incompetence.</em></p> If you're a skilled, experienced engineer and you fear that AI will make you unemployable, adopt a more nuanced view. LLMs can't replace human engineering.</em></p> The business allure of AI is reduced costs through commoditized engineering, but just like offshore engineering talent brings forth mixed fruit, LLMs fall short and open risks.</p> The AI hype cycle will eventually peak10</a></sup>. Companies which overuse AI now will inherit a long tail of costs, and they'll either pivot or go extinct. As such, the long-term value proposition for humans in engineering remains unchanged. The world still needs and will pay for technical skills and deep thinking in engineering.</p> AI will stick around, though. Use it as a tool, not a crutch, and continue to invest in the same fundamental engineering skills that were deemed valuable in 2019.</p> Next...</h1> Subscribe to my email list below. I plan to write more.</p> References</h1> Leading Question</a></li> The XY Problem</a></li> ThoughtWorks Technology Radar Volume 32</a></li> Coding as Craft: Going Back to the Old Gym</a></li> Thoughts on Thinking</a></li> The Hidden Cost of AI Coding</a></li> "I wonder if I'll become redundant"</a></li> Programming as Theory Building</a></li> Grug on Complexity</a></li> Gartner Hype Cycle</a></li> </ol> Tech Risk is Business Risk 2025-04-25T00:00:00+00:00 Tech risk is a business concern. Instead of vaguely bemoaning "tech debt" and hoping to "do things right", explain its potential costs with words the business understands.</em></p> </p> Tech Risks mapped onto Business Metrics </p> </div> Introduction</h2> 5 months ago, Reddit user Agent_Aftermath</em> posted in /r/AskProgramming</em>:</p> Why are so many companies so ambivalent or uncommitted to addressing tech-debt?</p> </blockquote> I think most engineers can empathize with this problem. We've all worked in codebases or infrastructures that smelled worse than a dirty diaper while our organization seemed unmoved or even resisted remediation.</p> The responses enumerated the many disincentives for addressing tech debt and presented only a few tenuous solutions. The top response succinctly captures the diagnosis:</p> It is more difficult to quantify the value of addressing tech debt as opposed to creating a new feature. --oofy-gang</p> </blockquote> The problem is not that tech debt is not real, nor that addressing it is frivolous. The pain lurks in quantifying it</em> and that there are apparently</em> more profitable uses of resources.</p> Note that for the rest of this article, I will use the term tech risk</em> instead of tech debt</em>. Why: In short, unlike mortgages, quality issues exact repayment suddenly and unpredictably. You can read my more detailed explanation here</a>.</p> What a Business Values</h2> Boardrooms always optimize for business metrics, and in capitalism, all business processes reduce to revenue and profit*. If technical issues have no anticipated</em> effect on the bottom line, then leadership will readily prioritize other capitalizable work.</p> It would be ludicrous for a CTO to stand up in a board meeting and declare, "I'm happy to share that engineering has closed all open bugs in the backlog." This statement conveys no meaning to the board. It is unactionable techno-babble. Rather, the CTO knows to translate to business-speak: "I'm happy to share that this quarter we'll able to deploy 100% of our resources to new feature development, and because of this efficiency we will not renew our offshore QA contract, saving $3M over last quarter."</p> The key word above is anticipated</em>. There is high-quality research^[1</a>]</sup> and literature^[2</a>]</sup> demonstrating that internal tech quality is a business concern after all</em>. Indirectly, the board does</em> care about the engineering backlog, because engineering is a business unit, and business units cost or earn money.</p> Let's now focus on how you, a technical person, can present engineering concerns as business concerns. I have distilled your task into three steps:</p> Identify business metrics</li> Identify tech risks</li> Map tech risks onto business metrics</li> </ol> * Funded startups, nonprofits, and businesses with philanthropic goals may have more nuanced motives than just net profit.</p> Identify Business Metrics</h2> If you're not sure what metrics your business is tracking, ask. They will usually be instantiations of "make more money" or "spend less money". However, revenues and profit may be linked to business processes with second-order metrics and performance indicators. For example, a food distributor must:</p> procure raw foods from producers</li> store raw foods cleanly</li> process and package foods efficiently and safely</li> find and retain customers</li> distribute food quickly to customers via truck, rail, or air before it spoils.</li> </ul> The overall business metric "net profit" will be a complex result of its many business processes.</p> Identify Tech Risks</h2> A tech risk is a technology that a business depends on that could have unexpected costs. Examples include a buggy internal codebase, outdated software^[3</a>]</sup>, servers past their vendor support window, and overcomplicated architectures. Quality is correlated with risk: high-quality software has less bugs and is easier to change.</p> These risks can cause events which negatively affect business metrics. For example:</p> An old software package contains a security flaw which results in data exfiltration.</li> A server fails and production is interrupted for a day.</li> A complicated architecture makes it expensive and slow to pivot the business to pursue a new revenue stream.</li> </ul> An FMEA^[4</a>]</sup> is helpful for prioritization, i.e. to decide which risks most merit mitigation. In this style of risk analysis, the risk is quantified in terms of its probability of occurrence and severity of the harm it could cause. You won't be able to fill in the severity column until you've completed the mapping to business metrics below.</p> Tech Risk</th> Probability of Occurrence</th> Severity of Harm</th></tr></thead> Security flaw in shipment DB</td> 1%</td> Low</strong>. Low-value shipment data exfiltrated</td></tr> Security flaw in patient DB</td> 1%</td> Severe</strong>. Protected Health Information exfiltrated</td></tr> Server disk fails</td> 10% after 5 years</td> Moderate</strong>. Production interrupted 1 day</td></tr> </tbody></table> Map Tech Risks onto Business Metrics</h2> Each risk presents one or more harms, each of which can realize cost to the business. Sometimes the path to a business metric will traverse one or more business processes. For example, it may not be immediately apparent how a damaged brand reputation can affect revenues, but a reduced sales funnel conversion rate will directly impact the bottom line.</p> Event</th> Business Metric Impacted</th></tr></thead> Low-value shipment data exfiltrated</td> None; who cares?</td></tr> Protected Health Information exfiltrated</td> Brand reputation damaged → Sales Funnel Conversion % (fewer new customers)</td></tr> Protected Health Information exfiltrated</td> Brand reputation damaged → Churn (customers leave)</td></tr> Production interrupted 1 day</td> Can’t fulfill committed sales → 1% loss of quarterly revenue</td></tr> </tbody></table> Step back for a second and compare the items on the left and right. The CEO's eyes may glaze over at the annual HIPAA training, but connecting a PHI breach convincingly to the company's sales conversion rate will make them listen.</p> Conversely, if you can't meaningfully associate a tech risk with a business cost, then you should accept that it is not a business priority. In the example above, we don't need to prioritize hardening the shipment DB.</p> Conclusion</h2> To convince your company to address "tech debt", map from tech risks to business metrics. Be prepared to discover that some tech risks don't matter.</p> Next...</h2> Subscribe to my email list below. I plan to write more.</p> References</h2> Code Red: The Business Impact of Code Quality</a></li> Accelerate: The Science of Lean Software and DevOps</a></li> End-of-life (EOL)</a></li> Failure Mode and Effects Analysis</a></li> </ol> It's Not Tech Debt. It's Tech Risk. 2025-04-09T00:00:00+00:00 Tech Debt becomes due swiftly and chaotically. Tech Risk is a better metaphor.</em></p> </p> Space Shuttle Challenger, 1986. </p> </div> What is Tech Debt?</h2> Tech debt</em> is a metaphor coined in 1992 by Ward Cunningham1</a></sup>.</p> In software engineering and adjacent disciplines like DevOps, it relates shortcuts on quality to financial debt.</p> We all know how financial debt works: you pay to use someone else's money. The amount you pay is proportional to the amount you borrow, how long you borrow it, and the interest rate. Borrowing can be a good idea since having money right now</em> enables valuable events like buying a house or starting a business.</p> Wardites hold that tech debt, like financial debt, incurs a penalty which over time compounds the amount of labor required to continue delivering. Etiologies vary: Some folks hold that tech debt originates when stakeholders intentionally</em> trade quality for delivery speed. Others say it happens inadvertently</em>. Some distinguish between reckless</em> and prudent</em> tech debt2</a></sup>.</p> Financial Debt is Predictable</h2> The tech debt metaphor appeals because it is easy to explain. Unfortunately, the metaphor is strained. Tech debt is not like financial debt</em>. Let's see why not.</p> Mortgages and other loan products are predictable</em>, for both the lender and the borrower. Borrowers repay on a steady schedule which has a specified maturity term, e.g. 15 or 30 years. The interest rate is fixed or mostly fixed. From day one, a spreadsheet predicts exactly how much principal and interest the borrower will still owe in month 137. For a bank, any loan is part of a diversified portfolio of many loans. While banks do fail3</a></sup>, stricter underwriting rules since 2008 have made it less common. Moreover, the societal harm of any individual bank failure is mitigated by distributing its cost across the entire banking system, facilitated by the full faith and assurance of the US Federal Reserve.</p> Tech Debt Detonates</h2> Here's how financial debt could be like tech debt. Imagine a hypothetical dystopian financial system in which banks could demand full mortgage repayment on a whim. We'll call these detonating mortgages</em>4</a></sup> — If you can't pay a few hundred thousand dollars right now</em>, you lose your home. No, you didn't do anything wrong, but the bank needs some liquidity today, so you and your children are now living in a hotel.</p> </p> A detonating mortgage </p> </div> Tech debt is like a detonating mortgage. Its payment becomes due unpredictably. Its timing is not fair or uniformly distributed.</p> The people who investigated the Challenger disaster5</a></sup> didn't have the term tech debt, but they listed quality shortcuts among the root causes. These quality shortcuts exposed the space program to risk. If NASA could have had at their disposal a spreadsheet predicting that the O-ring would fail on January 28, 1986, they would have decided not to fly.</p> Conclusion</h2> Quality shortcuts create risk. Some risk is necessary to reach our goals; how much we can tolerate depends on the expected reward6</a></sup>.</p> Let's not delude ourselves when we're taking risks. Deferred tech quality is not like a loan. The cost of quality shortcuts doesn't manifest on a schedule.</p> Use the term tech risk</strong>.</p> Next...</h2> Want to identify, prioritize, and mitigate tech risk? Subscribe to my email list below. I plan to write more about this topic.</p> References</h2> Ward Cunningham</a></li> Technical Debt Quadrant</a></li> Banking in Very Uncertain Times</a></li> Patrick McKenzie invented this thought experiment in Banking in Very Uncertain Times</em></li> Rogers Commission Report</a></li> The Most Important Thing</a></li> </ol> Why Programming is Hard 2024-02-16T00:00:00+00:00 Programming computers is hard because, as Hal put it</a>, it isn't about programming, and it isn't about computers.</p> A wizard conjuring a computer program. Generated by Dall-E</p> </div> Even the most mundane of programming issues are rooted in profound questions:</p> "Why are my dependencies broken?" => "What is causality?" ^[1</a>]</sup></li> "Should I check for null?" => "When can we know a program is correct? Design time, compile time, or run time?" ^[2,3</a>]</sup></li> "Why don't I understand this code?" => "What is memory, cognition, and language?" ^[4</a>]</sup></li> "Why is this program buggy?" => "What is a proof?" ^[5,6</a>]</sup></li> </ul> While you'll overhear the questions on the left rising from the desks of developers on a Tuesday afternoon, their answers are surprisingly elusive and timeless.</p> References</h2> Program Actions as Actual Causes</a></li> Null References: The Billion Dollar Mistake</a></li> The Three Levels of Software</a></li> Tacit knowledge</a></li> Curry-Howard correspondence</a></li> Would aliens understand lambda calculus?</a></li> </ol> Grounded Programming Pedagogy 2024-01-25T00:00:00+00:00 In the alum chat for Mirdin</a>, someone posted the following question, "Would it be better to start teaching beginners functional or imperative programming first?"</p> Pretending for a second that FP</a> and IP</a> are the only choices (they're not</a>), an answer depends on where your beginner comes from.</p> A meta-pedagogical (teaching about teaching) answer acknowledges that learning starts in a place the learner feels grounded</a> and connects them from there to new knowledge. For example, subitizing</a> is an innate ability. A developmentally normal child can instantly know how many objects are presented, for values up to about 5.</p> Image: How many dots are there? You just subitized.</p> </div> From there, you can teach a 5-year-old arithmetic, for example to add, by having them subitize groups of objects alongside numerals and the math symbol +</code>. This connects their innate notion of quantity to the abstract notion of numbers.</p> The MIT book and course SICP</a> is a masterpiece in programming pedagogy, and it falls heavily on the FP side. Watch Professor Sussman absolutely rip apart side effects in lecture 5A</a>. But not everybody "gets" this approach easily. Even Hal acknowledges in this Corecursive interview</a> that the FP approach didn't work for everyone:</p> In the very beginning days, we would teach a sort of short courses for MIT faculty and some of the electrical engineers would just get stuck. "You haven’t showed us how the transistors work". ...People think different ways. Some people have to be grounded on where they’re comfortable and for some people, well, it really is transistors.</p> </blockquote> Contrast that to somebody who knows what a function is, in the math sense. The machinery of a transistor</a>, of gates, sources, drains, and TTL</a> will be an irritating detail, like multiplying matrices by hand.</p> So in the dichotomy between introducing FP and IP first, the answer might depend on where the learner is coming from. I learned IP and OOP first because that's what material was available. I was first exposed to FP in college in the form of Scheme. It was disorienting. I couldn't count all the parentheses, let alone grok tail recursion. I wish it could have been presented to me grounded in terms of what I was already comfortable with, for example high school algebra.</p> I say, introduce multiple programming paradigms early, and ground it in what the learner knows. A fundamental programming skill is to think at multiple levels of abstraction</a>. The Haskell programmer needs to be aware that even monads at some point are just bits in a memory hierarchy, just as it's important for an assembly programmer to know that while register allocation is critical to performance, registers are not really what the program is about.</p> To close, let's ground this discussion in something we all know. To design a cathedral, the architect needs to know what bricks will be used. To build a cathedral, the bricklayer needs to envision the noble end to which each brick is set down.</p> A Design is a Mold for Code 2024-01-15T00:00:00+00:00 I'm always in search of good metaphors for software design. Good or not, here's one:</p> A Design is a Mold for Code</p> </blockquote> In manufacturing, a mold is a hollow shape that fills with fluid material which expands into the space and sets to form a casting.</p> Image: A useful mold. Generated by Dall-E</p> </div> Like in manufacturing, code fills the negative space</a> of a software design. Over time, code sets and becomes harder to change.</p> Imagine two engineering teams who independently "fill" (implement) a design, and the design is the set of standards for a web browser. The two implementations are Chrome and Firefox. The two browsers have independent codebases^[1</a>]</sup> which take vastly different shapes, but as far as web standards are concerned, the two are equal. You could switch from Chrome to Firefox (which I recommend</a>) and still browse compliant web pages with no discernible change.</p> Programmers who also like math sometimes call two pieces of code which can be swapped isomorphic</a> with respect to the spec.</p> It's important not to reverse the causality: a design causes the work product, not the converse. A mold causes a casting, and a software design causes code. Nevertheless, to some extent, one can go in reverse, i.e. reconstruct a mold from a casting or infer a design from code.</p> The reconstructed mold might lose some fidelity, like sharp edges or precise dimensions, but it's far worse for code. Looking at code without supplemental information, a new dev can only infer a dim, vague notion of its design. She might even sense the mind(s) behind the design. However, it would be costly if even possible to losslessly reconstruct the design, i.e. to such a fidelity that it could be the basis for an isomorphic implementation.</p> In pseudocode:</p> [Test] </span>fn Reverse_ProducesIsomorphicDesign() </span> let design1 : ... </span> let code1 = implement(design1) </span> let design2 = reverse(code1) </span> let code2 = implement(design2) </span> assert(isomorphic(code1, code2)) // Fails </span></code></pre> Above: The roundtrip from a design to code back to design is lossy.</p> There are a few reasons for this:</p> A codebase maybe too large to fit into a dev's head. The codebases for Chrome and Firefox are huge. Like the limited context window of ChatGPT, a human has limited working memory and forgets. Though with time and repetition, knowledge transitions to long-term memory.</li> It's hard to infer high-level concepts from low-level details. For example, decompiling assembly back to C.</li> Design and code have a many-to-many relationship. There can be many implementations that satisfy a design.</li> There can be many designs that result in the same code.</li> </ul> </li> </ul> This is a problem for software that outlives its creator(s). The software will languish unless knowledge is retained</a> and replicated</a>.</p> There are some things developers can do to keep their software alive:</p> Write down the design. Use natural language</a></li> Make the design apparent in the code</a></li> Use precise abstractions</a></li> Use effective</a> metaphors</a></li> Make the code fit in your head</a></li> </ul> Notes</h2> Firefox and Chrome are not truly independent by this definition. Plenty of people who have worked on one browser have also worked on the other. Moreover, as open source projects, both teams can see the other's code. Chromium source</a> and Firefox source</a></li> </ol>

Don't believe "software never fails"

Fix: Use better metaphors</h3>
In It's Not Tech Debt. It's Tech Risk</a>, I show that the metaphors we use shape how seriously we take software problems.</p>

When the Machine Metaphor Breaks Down

Stabilizing Phase</h3>
Like hardware, there is an "infant mortality" phase. New programs tend to be buggy. The customers complain and the team scrambles to fix the bugs. Once the bugs are fixed, the program enters a stable phase with relatively few failures.</p>

References</h1>

IBM: What is COBOL?</a></li>
Dijkstra: On the cruelty of really teaching computing science</a></li>
Wikipedia: Bathtub curve</a></li>
Wikipedia: Mean Time Between Failures</a></li>
IEEE 610.12 Standard Glossary of Software Engineering Terminology</a></li> </ol>

Who wins in an Arms Race?

References</h1>

Nike's Controversially Fast New Shoes</a></li>
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</a></li>
Your Brain on ChatGPT</a></li>
LLMs are not Bicycles for the Mind</a></li>
Software as a service</a></li> </ol>

How to say no without authority

It's Time to License Software Engineering

Objections</h1>

Is software free speech?</h2>
In the US, yes 9</a></sup>, but causing public harm or encroaching on others' rights is not protected. For example, DeCSS was ruled to be illegal 10</a></sup> even though it was free, noncommercial software.</p>

What about versioning? Do I need a sign off for minor revisions and bugfixes?</h2>
Each public release of commercial software needs a sign off.</p>

So my WordPress blog needs a sign off for each post?</h2>
That's publishing, not software, and requiring sign off on writing would encroach on free speech.</p>

How would it be enforced?</h2>
Probably via courts. We should look to the existing engineering disciplines for guidance and precedent.</p>

Next...</h1>
Subscribe to my email list below. I plan to write more.</p>

About that Gig Fixing Vibe Code Slop

LLMs are not Bicycles for the Mind

Summary</h1>
You can depend on LLMs too much. Use them in a way that doesn't atrophy your mental fitness and doesn't exasperate your colleagues.</p>
References</h1>

What's Wrong with this Picture?</a></li>
Appeal to Aithority</a></li>
Brandolini's Law</a></li> </ol>

References</h1>

What's Wrong with this Picture?</a></li>
Appeal to Aithority</a></li>
Brandolini's Law</a></li> </ol>

Oil Spills Can Create Jobs

References</h1>
Deepwater Horizons Cleanup, 2010-08-19</a></li>
as everyone called it then</li>
Labor Market Impacts of the 2010 Deepwater Horizon Oil Spill and Offshore Drilling Momentum</a></li>
The era of AI slop cleanup has begun</a></li> </ol>

Dev Skills for the LLM Era

AI: Accelerated Incompetence

Tech Risk is Business Risk

Conclusion</h2>
To convince your company to address "tech debt", map from tech risks to business metrics. Be prepared to discover that some tech risks don't matter.</p>

Next...</h2>
Subscribe to my email list below. I plan to write more.</p>

It's Not Tech Debt. It's Tech Risk.

References</h2>

Ward Cunningham</a></li>
Technical Debt Quadrant</a></li>
Banking in Very Uncertain Times</a></li>
Patrick McKenzie invented this thought experiment in Banking in Very Uncertain Times</em></li>
Rogers Commission Report</a></li>
The Most Important Thing</a></li> </ol>

Why Programming is Hard

References</h2>

Program Actions as Actual Causes</a></li>
Null References: The Billion Dollar Mistake</a></li>
The Three Levels of Software</a></li>
Tacit knowledge</a></li>
Curry-Howard correspondence</a></li>
Would aliens understand lambda calculus?</a></li> </ol>

Grounded Programming Pedagogy

A Design is a Mold for Code

Notes</h2>

Firefox and Chrome are not truly independent by this definition. Plenty of people who have worked on one browser have also worked on the other. Moreover, as open source projects, both teams can see the other's code. Chromium source</a> and Firefox source</a></li> </ol>

Doug Slater

Relieve your context anxiety with modular thinking