Current programming languages address exactly one paradigm: synchronous and sequential. That paradigm served the 20th century well, when CPUs were expensive and every cycle had to count.

The 21st century changed the ground rules. CPUs are now effectively free. The internet, robotics, IoT, and control systems are now mainstream. Problems that cannot be forced into a synchronous, sequential mold are no longer edge cases — they are the common case.

Yet our development workflow has not changed. We still spend our time shaping workarounds, bending non-sequential problems into a sequential mold, and discarding the problem variations that won't fit. We optimize for code quality over design quality. We treat premature perfection as a virtue.

This book does not claim to correct that imbalance. It points at it, examines it, and argues that attention to design is at least as important as the correctness of the code that implements it. Accepting the first design that comes to mind is the same mistake as accepting the first code an LLM generates without subjecting it to critique. We would not do the latter. We routinely do the former.

Our current practice of delegating design feedback to paying customers — through quarterly, sometimes daily, updates — produces an unnecessarily slow design validation loop. Our belief that a single device and a single paradigm can be stretched to address every problem produces self-inflicted, accidental complexity that trends toward decreased robustness.

We have also forgotten that the functional paradigm is a choice, not a law of nature. Other choices exist. Computers running operating systems with libraries of function-based code are not the only way to produce electronic solutions. Operating systems and function libraries exist to support the functional paradigm — they may be unnecessary when a different paradigm is the better fit. They are development tools. We should be using and culling them to produce solutions. Instead, we develop inside a soup of development tools and ship the entire kit as a product to non-developers.

Exploration of the design space deserves at least as much emphasis as producing correct code. No developer can explore every corner of a design space — the fullness of that exploration will always depend on the developer's own judgment about how far to push. But we settle for far less exploration than is warranted, and our tools and workflows are a primary reason why. They discourage backtracking. They make trying out an alternative design idea feel expensive. They treat every restart as a failure rather than as progress. If we can recognize these obstacles clearly, we can begin thinking about programming differently — not as a monolithic activity aimed at a single correct solution, but as a process that alternates deliberately between exploration and consolidation, between design and perfection, with honest awareness of the limits of our initial understanding.

The model this book proposes is the electrical engineer's bench: snap together trusted black boxes, probe the results, iterate without friction, test compositions with test jigs before committing to a full design. Small tools, little languages, and scripted loops replace the monolithic toolchain. The design space gets explored — as fully as the developer's judgment allows — instead of being prematurely collapsed. The book makes this concrete with a step-by-step worked example: a small PBP project building a "Five Whys" tool using two instances of an LLM. The example demonstrates designing from the top down and from the bottom up, and shows what backtracking looks like in practice when new knowledge is acquired mid-design.

This is not new capability. We have had the CPU headroom to work this way for some time. What has held us back is economics and a "make it work with what we have" attitude rather than a "design for what the problem actually requires" attitude — and an underemphasis on design validation as a result.

This book does not claim to have the final answer, or to relieve programmers from the obligation to think hard and explore design spaces to their own satisfaction. The invisible hand of the market should do what it did in the early days of game programming — cull poor designs, poor code, and anti-robustness driven by featurism. What this book argues is that we need to be improving our workflow on many fronts simultaneously, rather than deep-diving into a single aspect of coding — correctness of code — while leaving the prior question of design quality largely unexamined. Shining a light on more of the issues may itself change the way we think about when to explore and when to perfect.

Field reliability follows as a natural consequence of getting the design right — the same way it does in hardware.