Who Am I and Why Should You Care?

I'm a retired electrical engineer who ran a software consultancy for over 25 years. Embedded systems (credit card terminals, the kind of hardware that has to work every single time), Y2K renovation of COBOL codebases using advanced parsing and backtracking tools and design recovery, tax platforms, business strategy tools — I've built the unglamorous stuff that actually runs the world. None of it was glamorous. All of it taught me something.

What it taught me, mostly, is that software is far more complicated than it needs to be.

Hardware designers work with schematics and ICs — reliable, composable, and honest about time. Software designers inherited notation from the 15th century printing press, then the 19th century QWERTY typewriter, and never stopped to ask whether those tools were the right fit for a fundamentally different medium.

They aren't.

There's a trap worth naming early: casting deep thinking into mathematical form is a one-way operation, not two-way. Once you understand something, you can express it in math — but the math doesn't contain everything you understood. Whatever was elided to make the expression concise is gone. The map is not the territory, and the equation is not the insight. I try to keep that distinction front of mind in everything I write here.

The core thesis

Real life is asynchronous. Software pretends it isn't. That pretense is the source of most of the accidental complexity we spend our careers managing — callback hell, promises, mutex locks, race conditions, the whole zoo.

I've spent years asking one question: why are hardware designs more robust than software designs? Hardware is fundamentally asynchronous — components react to signals, they don't wait their turn. If we expressed software the same way, would reliability go up? I think yes. And I don't think the current answers — threads, promises, async/await — are the right path. Bolting asynchrony onto a synchronous foundation feels fundamentally backwards. What we're doing today is like writing assembler. We need better notations for expressing compositions of asynchronous components. Can we just start from asynchrony instead? I'm now convinced the answer is yes, and that doing so leads to something almost embarrassingly simple. If you know how to build a queue, you're most of the way there.

What I publish

I've put out hundreds of articles on GitHub Pages and Substack, and hundreds of videos on YouTube. Most of it is free. I believe in partial marks — publish the unpolished thought, not just the finished paper. A lot of what I write reads more like a working diary than a journal article, and I think that's a feature, not a bug.

The topics look scattered from the outside. Diagrams as code. Prolog. Forth. Functional programming's hidden assumptions.

They're connected. The connecting thread is always the same question: what is being elided, and what does that cost us?

What I'm driving at

We are still using 2D notation — text, math symbols, sequential syntax — to describe programs that run on hardware that lets us think in four dimensions. x, y, z, and time. We have the technology to express programs in 4D. We just haven't built the habit.

Functional programming elides time and ordering. That's fine for ballistics computations. It is not fine for systems that need to respond to the world as it actually is — concurrent, event-driven, asynchronous by nature.

I'm not arguing that functions are wrong. I'm arguing that functions are not enough, and that treating them as the only legitimate notation is what got us into this mess.

The path out involves asynchronous-by-default design, diagram-based notations, staged computation, and the willingness to admit that no single notation covers all bases. Software is catching up slowly.

I'm trying to help it catch up faster.