A ~10% gain is consistent with what we’re hearing from engineering leaders more broadly: most organizations are landing in the 8–12% range. It is a real improvement, but it’s a long way from the 2–3x gains many executives and boards have come to expect. AI is moving the needle, but leaders may need to reset expectations internally.

Justin Reock

Wirth's Revenge

• 📈 Wirth's Law confirmed — Software is getting slower more rapidly than hardware becomes faster, as demonstrated by a 1995 essay lamenting that text editors grew from 8KB to 800KB while becoming slower overall
• ⌨️ Input lag paradox — The Apple 2e from 1983 still has the lowest input latency of any computer ever measured, despite decades of hardware improvements, because modern systems add layers of complexity
• ☁️ Cloud computing trade-offs — Moving from garage startups to cloud infrastructure added cost but enabled massive scalability and reduced capital risk, representing a "good" Wirth trade-off that provided real value
• 🔥 ORM performance disasters — Innocent-looking template loops can generate hundreds of thousands of database queries due to lazy loading, creating a "bad" Wirth trade-off where convenience masks devastating performance costs
• 🤖 LLM efficiency trap — Using AI to calculate 2 × 3 costs "several seconds, milliliters of water, and enough power to watch 5% of a TikTok video" when your computer can do it a billion times per second
• 💸 The $20 sleep incident — A personal AI agent asking "is it daytime yet?" repeatedly throughout the night cost almost $20 in API calls, highlighting the importance of using deterministic solutions for repetitive tasks
• 🧠 Skill erosion concern — Research shows AI use "impairs conceptual understanding, code reading, and debugging abilities" when people ask AI to solve problems instead of learning to build solutions themselves
• ♾️ Busy Beaver reality check — The mathematical function BB(6) has a lower bound "so large that it is impossible to explain how large it is" — suggesting software's capacity for inefficiency may be theoretically unlimited

Chaos vs. Bureaucracy: Pick Your Poison

• ⚖️ The Pendulum Swing: Engineering teams typically oscillate between unorganized chaos and suffocating bureaucracy instead of finding a healthy balance between standardizing systems and trusting human judgment.
• 🌪️ The Chaos Trap: Moving fast without systems creates a fragile environment that relies heavily on undocumented tribal knowledge and exhausted "hero" engineers to keep things running.
• 🛑 The Bureaucracy Trap: Process often creeps in to prevent past mistakes, eventually replacing trust with rigid approval chains that frustrate top performers and kill velocity.
• 🎯 Minimum Viable Process: The optimal state is the "edge" between the two extremes—using just enough structure to coordinate work and capture learning, without stifling independent critical thinking.
• 🏗️ Escaping Chaos: If your team lacks structure, systematically document the criteria you use for recurring decisions, create flexible templates, and centralize your team's knowledge into a single source of truth.
• ✂️ Escaping Bureaucracy: If your team is bogged down by rules, shift from "ask and wait" approvals to "inform and proceed" ownership, and schedule recurring sessions to actively delete outdated processes.

Why We've Tried to Replace Developers Every Decade

• 🔄 The 50-year cycle: Every decade promises to replace developers with simpler tools — from COBOL in the 1960s to AI today — but the pattern keeps repeating because software complexity can't be eliminated, only managed
• 🌙 Apollo's legacy: Margaret Hamilton's team proved software could be mission-critical, but also revealed that quality development requires specialized knowledge, intense focus, and significant time — setting up decades of attempts to shortcut this reality
• 📝 COBOL's false promise: Making syntax readable like English sentences didn't eliminate the need for specialized programmers — business analysts still couldn't handle logic complexity, data structures, or system design
• 🔧 CASE tools disappointment: 1980s visual programming tools promised 10x productivity but failed because drawing accurate diagrams required the same logical complexity as programming — changing the interface didn't change the fundamental challenge
• 🖱️ Visual Basic's partial success: Unlike COBOL and CASE tools, VB and Delphi acknowledged programming knowledge was still needed but lowered barriers — more people could build simple apps, but complex systems still required experienced developers
• 🤖 AI's familiar pattern: Current AI coding assistants represent genuine progress and help developers work more efficiently, but they amplify capability rather than replace the need for human judgment about complexity
• ⚡ The capability paradox: Despite extraordinary advances in computing power and development tools, demand for software still far exceeds our ability to create it — the constraint isn't typing speed or syntax, it's thinking through complexity
• 🎯 Better leadership questions: Instead of asking "Will this eliminate developers?" ask "Will this help developers work more effectively on complex problems?" and "Does this reduce repetitive tasks so developers can focus on unique challenges?"
• 🧠 The irreducible core: Software development is "thinking made tangible" — you can't shortcut the reasoning required to handle complexity any more than you can shortcut architectural design or medical diagnosis
• 💡 The dream's purpose: The recurring pattern isn't a mistake but necessary optimism that drives tool creation — each attempt produces genuine value even when the original vision doesn't materialize as imagined

Ideas Over Implementation

• 🎯 Focus on outcomes, not outputs — Get attached to what you're trying to achieve rather than what you've built, giving yourself permission to pivot when needed
• 📊 Early decisions have the least data — Initial choices are made with incomplete information, so treating them as unchangeable makes learning unnecessarily expensive
• 💸 Sunk costs are inevitable, rigidity isn't — Accept that some investments won't pan out, but don't compound the problem by stubbornly sticking to failing approaches
• ❤️ Don't fall in love with your tools — Attachment to specific architectures, technologies, or methods forces you to get everything perfect upfront — an unrealistic standard
• 🔄 Progress requires revision flexibility — Be willing to change the "how" while keeping the "why" constant to maintain forward momentum
• 💪 Strong teams hold ideas lightly, goals firmly — The best teams balance adaptability in execution with unwavering commitment to objectives
• 🏃 Understanding improves with motion — Flexibility isn't indecision — it's recognizing that you learn more as you move forward and should adjust accordingly

Nobody knows how the whole system works

• 🧠 Nobody truly understands entire systems — Even experts have partial knowledge of complex technologies, with understanding limited to specific layers or domains
• 📱 The telephone paradox — MIT professor Louis Bucciarelli argues that "knowing how a telephone works" can mean anything from dialing to quantum physics to corporate finance — no single person grasps the full system
• 💻 Technical interviews reveal knowledge limits — Brendan Gregg's approach of asking progressively deeper questions until candidates hit their knowledge boundary shows everyone has limits, and honesty about those limits matters more than pretending to know everything
• ⚡ Magic vs. transparency debate — Simon Wardley warns against building on systems we don't understand (calling obscured frameworks "magic"), while Adam Jacob argues AI tools are too valuable to avoid despite creating more abstraction layers
• 🏗️ We've always built on incomplete understanding — Bruce Perens points out that developers already work with mental models that are "incorrect in fundamental ways" about CPUs, operating systems, and other foundational technologies
• 🤖 AI accelerates an existing trend — While AI will worsen the problem of building without deep understanding, we've been operating with partial knowledge of complex systems for decades — it's the nature of modern technology, not a new crisis

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇