Randy Shoup set out to be an international lawyer. He studied in West Berlin when there was still a wall around it, spent a year at Stanford Law, and had what should have been the perfect summer internship on Sand Hill Road. Instead he spent it watching inventors light up whiteboards with brilliant ideas — then being told his job was just to write them down. That summer broke something open. He went back to Oracle that fall and never looked back. Kent and Randy dig into what it means to need to make things, why the people who wrote the original distributed systems playbook aren’t panicking about AI wiping it clean, and how Jevons paradox explains what happens when cognition gets cheap.

This season of Still Burning is sponsored by WorkOS and Augment Code.

Listen to the audio version here.

“We’re accumulating code faster than we are accumulating trust.” Sometimes a phrase just hits. Yes, we can create code faster now, but software is bipedal—code & trust go together. One without the other just hops along awkwardly.

Trust is as tricky as code. Both are asymmetrical. Code works or it doesn’t. One mistake in a long string of good decisions is the same as just a mistake. Trust accumulates slowly & evaporates in an instant. The difference is that in software sometimes you can repair the mistake in time proportional to the time it took to make the mistake. Trust is irreversible. Once gone it’s hard-to-impossible to get it back.

XP offered faster accumulation of functionality than folks were used to, but it didn’t suffer from the lack of trust we see among genie pioneers. I never thought of it this way before but XP manufactured trust. But how? What is a trust factory? We’ll go from practices to principles to values.

Practices

I’m going to go through XP Classic here, not that newfangled XPAI that folks are talking about, since the new set of practices is not yet settled.

Practices build trust:

• Programmer testing. Thorough automated testing demonstrates trustworthiness to the rest of the team. It also builds trust within the programmer.

• Pairing. Pairing builds trust between programmers. The reduced defect count & improved structure build trust with the rest of the team.

• Continuous integration. Integrating small sets of changes, optimized for safety, reduces gotcha moments for the rest of the team.

• Weekly planning. Demonstrating concrete progress to those who depend on it builds trust, as does honestly reporting hiccups.

• Customer on the team. All the little interactions during the day—asking domain questions, getting clarification, offering alternatives—build trust.

• Continuous deployment. Knowing that your code is running correctly in production adds to your own confidence. Knowing that everyone else operates under the same constraint adds to your confidence in each other. Customers seeing small changes appear nearly instantly builds their trust.

• Refactoring. When improving structure reduces defects or reduces future effort, it builds trust.

• Observability. Knowing that you’ll be alerted to malfunctions builds trust, as does the skin in the game of knowing that you’ll be alerted encouraging prudence so you avoid those malfunctions.

What I notice about this list that I didn’t expect is that each practice that creates trust also encourages trustworthiness. If I know I’m going to get paged in the night, I’ll do the work to reduce the chance that I’ll be paged in the night. If I know I’m going to be writing tests, I’ll do the work to make writing tests easier. I wonder if this is a general feature of the trust factory? We’ll find out

Principles

XP builds on a coherent set of principles aligned with producing value with software. Not surprisingly, given the topic of this essay, they also align with producing trust.

• Humanity. Acknowledging that we are all humans with needs creates trust, in part by encouraging folks to be more honest and clear about their needs.

• Mutual benefit. Looking for win/wins let’s everyone relax & quit trying to grab more than their share of the pie.

• Improvement. Acknowledging that today isn’t perfect but it’s better than yesterday & tomorrow will be better still encourages folks to trust each other.

• Flow. Seeing concrete progress frequently encourages trust, even when things are going slower than we’d like.

• Redundancy. When we address difficult problems several different ways we increase the chance that the problem won’t erode trust.

Sure looks like the same effect is at work. Trust encourages trustworthiness. I’ll be treated with human respect so I treat others with human respect. Others benefit me so I’m encouraged to benefit others.

Does the same process work at the level of values?

Values

Values are the vaguest level of describing XP but contain the most purpose. How do values encourage trust?

• Communication. Saying things that need to be said in ways that can be received builds trust.

• Simplicity. I’m getting iffy about simplicity as a value since successful systems always end up complicated, but having pieces that are easily described builds trust.

• Feedback. Knowing that you’ll be listened to encourages honesty, even when the topic is difficult.

• Courage. Acting from vision & purpose in spite of fears encourages the team to trust each other.

• Respect. Seems obvious to me.

Once again, creating trust creates the conditions for creating more trust.

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Build Trust With Enterprise

Vibe Coding Versus Trust

Software development that focuses on trust as much as features has always been rare. We are now shifting to individuals interacting individually with the genie (I call this the single player problem. Trust, as the opening quote points out, lags features. This mismatch is unstable, unsustainable. When it corrects it’s going to be painful. How does single player augmented development as naively practiced erode trust?

• Genies “care” about satisfying prompts, not purposes. Generated software often doesn’t behave correctly in circumstances that are the least unusual. Thinking, “This works,” & then, “Oh no, it doesn’t,” erodes trust.

• Encouraging single player development eliminates most of the little chances to build trust.

• Purely reactive project management, the natural style when on the feature hamster wheel, risks tactical progress but strategic failure.

• The genie ignores optionality & future change. Walking off the end of the productivity pier is a big trust breaker.

So?

I’m not saying trust is all that matters. I’m saying trustworthy behavior resulting in trustworthy software resulting in trust is the path to effective augmented development.

I’ve been guilty of saying, “The program is the truth.” At one level this is true—whatever we think the system does, what the system actually does is what the system actually does. However, the software system is, as points out, a symmathesy, a human-technical system. We are in it, cannot help affecting it, we can only influence not control it.

What would trust-optimized augmented development look like?

• Slow development to ensure that the damn stuff actually works.

• Slow development to include structural improvements that expand options.

• Slow development to encourage frequent person-to-person interaction.

• Slow development to reinforce & update long-term purpose.

That’s how you go faster. More chances to build trust->more focus on trustworthiness->more trust.

Dan Barrett built OpenProse — a framework that lets you write programs in structured English and run them with an AI agent like Claude Code. The description sounds either obvious or impossible depending on your priors. When I told him it sounded impossible, he said: “People were shocked that it works.”

So we installed it and built something live.

The project: a service that would show me tides, weather, sunrise, moonrise — everything I want to know before a walk along the coast. One command. A few minutes. It came back with an hourly tide chart for Montara (I picked a town I don’t actually live in), fog conditions, waxing crescent moon, the works.

Here’s what interested me about the architecture underneath.

Each OpenProse component has a requires block and an ensures block. Requires is what the component expects from its caller. Ensures is what it promises to produce. I said that looks like a function — domain and range. Dan said think more like a service. The distinction matters: when you have many components, an inversion-of-control container wires them together by matching ensures blocks to requires blocks. The same way Spring would wire Java components — except the whole thing is written in structured English and run by an LLM.

The Dijkstra objection comes up immediately: natural language is too ambiguous to be a programming language. Dan’s answer: we don’t know what’s possible until we walk the landscape. Plenty of people would have said nothing is possible with prose. That’s clearly not true. The question is just where the edges are — and you can only find those by trying.

The ensures block is effectively a postcondition. It’s what every sibling component can rely on. When I asked about extract method — you write one of these things, it grows, eventually you pull a piece out and name it — Dan said yes, all the time. Usually just by asking Claude to do exactly that.

The other clever piece: sub-agents pass pointers instead of data. Variable bindings are files. The pointers are file paths. When a sub-agent produces a giant context block — a full PDF analysis, a research output, a tide chart — it writes it to disk and hands back the path. The main thread stays clean. Context management, done at the file system level.

I’m building a Smalltalk VM from scratch right now — yes, literally writing a VM — and watching this I thought about how different it is to build a virtual machine when your primitives are LLM calls instead of machine instructions. My VM is 1000x faster. But the primitives here are so much larger that on the right problems, it’s a wash.

What’s next for OpenProse is interesting. Dan’s thesis is that the whole industry is moving toward declaring outcomes and letting agents figure out the path. Codex has a /goal feature. Anthropic just shipped something called Outcomes in their API. The pattern is: specify what you want to be true, not how to make it true. OpenProse is an early articulation of that idea at the framework level.

One of my many projects from the last 40 years is now actually possible. The genie just got smarter.

Dan is at @IRL_DanB on Twitter and dan@openprose.ai. OpenProse is open source — search it on GitHub and follow along. He loves feedback and means it.

Get more from Kent Beck in the Substack app

Available for iOS and Android

Get the app

This stuck in my craw at the time Patrick published it but I didn’t have the energy to respond. Now, with the ever-increasing, genie-fueled emphasis on speed, it deserves a second look. Among its several flaws as a statement is that it misses one point that XP got right, a point that’s become leveraged.

I’ll start gently, addressing the OP directly.

Responsibility

I don’t like the tone. Who exactly hired The Slow (may as well be honest & capitalize)? Who created the incentive system in which they operate?

Take responsibility for your part in the situation you describe. You’re not above it all. If you’re going to be judgmental, judge everyone. Or follow the not-a-Walt Whitman quote and, “Be curious, not judgmental.”

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Find Out More

Slow & Expensive Do Go Together

There’s reasons slow & expensive go together. I have connections to the design world. If you fly a team of nth generation carpenters in from Paris to build your cabinets on-site, it’s going to be expensive & it’s going to take time.

“Slow+expensive” has become decoupled from “valuable” in the situation you describe. Part of the investment was much more valuable than other parts. If you can just make the valuable investment & defer the rest, yes, you win.

Compressibility

“Lopping a year off the schedule” works until it doesn’t. Here’s your intention:

There’s a second order effect, though. Eventually you cut corners that bite back. When that happens, you lose control of time & cost.

Now The Slow have incentive to lie to you about progress. They’re caught in a Catch-22, no-win situation. The optimal strategy for The Slow is to hunker down, spend most of their time keeping their noses above water, & hope your attention passes on before they get fired.

But wait, there’s more! Nobody likes being in a no-win situation, so The Slow will inflate estimates, estimates they know you will slash. Now nobody knows anything about the project.

Scope

The missing concept is scope. You want a system that meets the following goals? Okay, how much of which goals first?

All of all the goals? Now you’ve created the perfect breeding ground for The Slow. And you did it. They aren’t “The Slow”. They are responding to your incentives.

Okay, how about this much of this goal & that much of that goal & more later. Now you get sooner, cheaper, & better. Nobody is compressing the incompressible. The system remains transparent & in control.

And because we navigate an uncertain & rapidly changing landscape, cutting scope generates more feedback sooner, leading to less waste & higher concentration of value.

Wrap Up

You’re right that sooner & cheaper are connected. You’re right that projects often start over-scoped, that much investment isn’t concentrated on value.

I disagree with your characterization of your intervention as “adding a temporal constraint”. The many times I’ve seen this done well what happens is that folks are forced to make priority decisions they wouldn’t otherwise make. (Lots to say about why this deferral happens.) Tearing out calendar pages is the trigger making those scope decisions inescapable.

Michael Grinich has an unusual vantage point, his company powers enterprise infrastructure for hundreds of companies, so he sees how the AI transition is actually playing out across the industry, not just in the headlines.What he’s noticing: the whole ecosystem is accelerating, not just the AI companies. And most people are misreading what kind of moment this is. Kent and Michael talk about building when the marginal cost of software approaches zero, what the Red Queen theory tells us about AI competition, how engineering leadership is quietly changing, and what drew Michael to the itchy-brained compulsion to make things in the first place.

This season of Still Burning is sponsored by WorkOS and Augment Code.

Angie Jones spent years as the "geek whisperer" — translating technical possibility into human progress. Then she led one of the most ambitious AI adoption programs in the industry, and the rug got pulled out. Now at the Agentic AI Foundation, she's working to make sure the standards powering the next era of software are built in the open, by everyone. Kent and Angie dig into the impossible bargain AI has handed engineers, what it really means to hire junior developers right now, and what scares her most about where we're all headed.

This season of Still Burning is sponsored by WorkOS and Augment Code.

Listen to the audio version here.

This and the following chapters are from a forthcoming book: Adaptive Radix Tree: Sorted Maps For Fun & Profit

Chapter 0 — What’s a trie?

This tutorial assumes you’re a Go programmer who’s used map[K]V and has reached for a sorted map at some point — google/btree, google/btree, or one of the third-party red-black tree libraries — and got a feel for the API. It does not assume you know what a trie is or how an Adaptive Radix Tree differs from one.

Each chapter builds a working sorted map. Chapter 1 is the simplest imaginable trie. Chapters 2 through 7 each add one decision: lazy expansion, path compression, smaller node types, polymorphism. By chapter 8 you can read the project’s main art.Tree source as a known artifact rather than a wall of code. This chapter is just the primer — no Go yet.

The premise

A sorted map is a map[K]V whose iteration order is the natural ascending order of K, not insertion order or hash order. The operations are familiar:

Put(k, v) // insert or replace
Get(k)    // (v, ok)
Delete(k) // remove if present
Len()     // count
Range(kFrom, kTo)     // iterator in ascending key order

Two well-known data structures offer this API:

• Hash maps with side indexes (e.g. map[K]V plus a sorted slice you maintain by hand). Lookups are O(1), but every mutation costs O(n) on the slice or O(log n) on a heap, and the iteration order is whatever you paid to maintain.

• Self-balancing BSTs — red-black, AVL, B-tree. Lookups, inserts, and deletes are O(log n); iteration is a tree walk. These compare keys as opaque blobs: every comparison reads every byte of the key until it finds a difference.

Tries take the third path: don’t compare keys; walk them.

The trie idea

A trie (”retrieval tree”, traditionally pronounced try) is a tree where each edge is labelled with one element of the key (a byte, in our case), and the path from root to a node is the prefix of every key reachable below it. There is no key comparison. Lookup reads the key byte-by-byte and follows the edge labelled with that byte.

The trie was invented during the Cambrian data structure explosion.

• René de la Briandais (1959) — “File Searching Using Variable Length Keys,” Proceedings of the Western Joint Computer Conference. First published description of the structure.

• Edward Fredkin (1960) — “Trie Memory,” Communications of the ACM 3(9):490–499. Coined the name trie (pronounced “try”) from the middle syllable of retrieval.

An ASCII picture of the keys {hello:1, hi:2, help:3}:

Two consequences fall out for free:

1. Sorted iteration is automatic. At each node, visit children in ascending byte order. The yielded keys appear in byte-wise sorted order with no comparisons and no balancing.

2. Shared work for shared prefixes. A lookup of help and a lookup of hello traverse the same first four edges. The per-byte cost depends on the keys’ shape, not on the size of the map.

What a trie costs

The honest tradeoffs are equally direct:

• One node-traversal per byte. A 16-byte key is 16 pointer dereferences down the tree. If the tree is bigger than your L1 cache, that’s 16 cache misses. A B-tree comparing the same key against a few interior keys is fewer dereferences but each comparison reads more bytes; the right answer depends on the workload.

• Wasted nodes for sparse keysets. Every byte position where any key has a unique value gets its own node. If your keys are random 16-byte blobs, almost every level branches, and you pay for one inner node per byte per key. Chapter 1 makes this visible: ~33 MB to store 1 000 random 16-byte keys in the simplest possible trie.

The book is structured according to the principles of David Parnas and Paul Clements's 1986 paper A Rational Design Process: How and Why to Fake It. The first chapter introduces a simple-but-slow implementation. Each of the seven succeeding chapters addresses the slowness of the previous chapter until we have the whole ART.

• Only full-sized nodes (chapter 1)—we build a whole working tree out of nodes that assume all 256 children are valid. (Foreshadowing—this will turn out to be a useful disaster.)

• Lazy expansion (chapter 2)—stop allocating inner nodes along a tail with no siblings.

• Path compression (chapter 3)—let one node represent several consecutive bytes when none of them branch.

• Small node type (chapter 4)—stores up to 4 keys.

• Polymorphism (chapter 5)—we’re going to add more node sizes, so why don’t we make it easy? (Make the hard change easy, then make the easy change.)

• In between node types (chapters 6 & 7)—save space at the cost of computation by filling in nodes with up to 16 & then 48 keys. (Of course it’s more interesting than a simple tradeoff when space saving reduces memory pressure & thus saves time.)

• Polish (chapter 8)—inline-key buffers, embedded headers, a reused path buffer for Range. Allocations per key drop to roughly one.

By chapter 8 the implementation is the same shape as the production art.Tree in the parent package. You will have built it, decision by decision, and you will have measured what each decision was worth.

Viktor Leis, Alfons Kemper, and Thomas Neumann at the Technical University of Munich published the adaptive radix tree first.

Published as “The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases” at ICDE 2013. PDF: https://db.in.tum.de/~leis/papers/ART.pdf

Onward to chapter 1, where we build the disaster. Well, the naive, memory wasteful version.

“Valuable” lives on 2 axes:

• Features—what the code does now.

• Futures—what we can get the code to do once we learn the lessons of this set of features.

As an engineer I am constantly juggling these two dimensions so I wanted a way to visualize them. On the features axis software either works or it doesn’t (more or less) & the region of working is rather small.

(Note that this puts features on the opposite axis from where it appears on Features Versus Futures. I tried it both ways & I like the layout best with the axes this way.)

The other axis is flexibility—can we make changes that:

• Work as expected

• Don’t break anything that was already there.

I’ve called this “optionality” or “futures” recently. Still looking for the right words.

Flexibility/optionality/futures has a wider operating range than whether the software works or not. You can skimp of flexibility for a while & not really feel it.

Orientation

Where was development in ancient times, you know, six months ago? Well, you had some teams who had high standards for the behavior of the system—tests, frequent integration, observability, zero defect tolerance, retrospectives. They also had high standards on flexibility—readable code, mutual comprehension (pairing, mobbing, thorough reviews).

Treating the two axes as orthogonal is simplistic. If you have fewer interruptions from defects you have (or can choose to have) more time to invest in flexibility. Also, if you have flexibility you are more likely to create features that work.

Muddling

Most teams weren’t in the upper right. Instead, they muddled along with mostly-working software that was quite difficult to change. (We can talk later about why folks would choose to stay in this region when they could be further up & to the right.)

Genie

Here’s what I’ve observed—genies naturally live down & to the left of muddling. The “plausible deniability” task orientation of the genie leaves it claiming success even though the code doesn’t work at all. And complexity piles on complexity until even the genie can’t pretend to make progress any more.

Solution?

You probably saw this one coming—nobody knows. Does the model need to be trained on better code? Trained on good commits? Better harnesses? Tests? Which tests? When? Better prompting? Or grasp the nettle of the Bitter Lesson & let the model develop it’s own style of development, even if it turns out to be incomprehensible to us rapidly-obsolescing humans?

Awareness is the first step. Where are you? Where do you want to be?

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Find Out More

Nobody wants agents. Nobody wants agent swarms. I have a system and I want it to change. That’s the whole thing.

This session I was using Intent by Augment Code — multi-agent, coordinator plus implementer plus verifier. Working on an adaptive radix tree in Go, optimizing for human readability. The coordinator delegates, the implementer runs off and builds things, the verifier checks. I called it the Freudian architecture: id, superego, ego. The id rushes ahead. The superego folds its arms. The ego negotiates. It kind of works.

But watching the swarm spin up, I noticed something. I was managing it. Watching which agent was doing what. Wondering when to interrupt. Holding state in my head that the system should have been holding for me. I’d said I wanted readable code and instead I had a coordination problem.

The mismatch is this: when I was working on performance last week, what I actually wanted was — how much faster can we make this? How hard would it be? How much would it cost? Outcomes. I don’t want to prompt-engineer my way toward an answer. I want to describe the result I’m after and have the genie tell me if it’s achievable and what it would take. I’ve never been able to get two agents working on the same codebase at the same time without my head exploding. So I’m not convinced the swarm is the answer.

Multi-agent is a feature. Outcome-orientation is the thing the feature is supposed to deliver. We keep getting those confused.

The other frontier nobody’s working on yet: multiplayer. Right now, five agents can work on this codebase simultaneously. Five people can’t. That’s backwards. The person who figures out real-time collaborative augmented development — where multiple humans actually steer together, not just watch — that person is solving the real problem.

Nobody knows what that looks like. But I’m pretty sure it’s not a coordinator with finger guns.

This Genie Session was sponsored by Augment Code.

Intent is the AI coding tool built for the way software actually gets written now. Describe what you want. Intent handles the rest — planning, implementing, verifying — so you stay focused on outcomes, not orchestration.

Try it out →

Get more from Kent Beck in the Substack app

Available for iOS and Android

Get the app

First published January 4, 2021, just before this newsletter started. Comes more starkly into focus given my recent Parkinson’s diagnosis. In that piece I introduced the time value of time, which I need to expand on further.

A billion dollars in 30 years. Would you take it? I wouldn’t. Here’s why that’s not dumb for me.

This is another of my “smash two ideas together” essays. In this case, the ideas are:

• The time value of money &

• Mortality

Heavy stuff, but there you have it. It’s a new year, time for big thoughts.

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Find Out More

Time Value of Money

I turn 60 this year [ed: now 65]. I’ve recently noticed my career thinking diverging from that of my colleagues. They are more willing than I am to sacrifice now for gains later. Reflecting on the differences I’m led back to a theme of economics I learned early and have been teaching geeks ever since: the time value of money.

The absurdity of software engineering dogma at the beginning of my career dragged me to the time value of money. The trend back then was to do more and more work at first (spending money all the while) for (it was promised) greater and greater benefit later and later.

This didn’t make sense to me. Much of that up-front work turned out to be useless speculation. More fundamentally, this style contradicted a central tenet of economics—the time value of money.

A dollar today is better than a dollar tomorrow. It’s worth more. If I have a dollar today, I can invest it and make more by the time tomorrow comes around. I should prefer less than a dollar today to exactly a dollar tomorrow, less by a discount rate (which, spoiler alert, is hard to figure out and shouldn’t be modeled as a constant, but please keep reading).

If you accept this truth, then you do exactly the opposite of “spend more now to (maybe) make more later”. Those dollars you spend now are more expensive than the dollars you earn later. You can create economic value simply by figuring out how to earn sooner or spend later, even before making anything!

Aligning with economics requires that you start earning sooner and defer spending as long as possible. This seems to contradict engineering purity—if I do a great job today then I’ll never have to invest in this code again. Sorry, that’s not how money works. Look at XP and you’ll find a hundred ways to earn sooner and spend later.

(At this point I encourage you to do background work to gain intuition about the time value of money. Build a spreadsheet. Play with parameters. Let the difference between a dollar today and a dollar tomorrow soak into your bones. That’s what I did.)

Here are 2 more ways to think about the time value of money. First, the less time involved, the less it matters. This will be important as we talk about the effects of mortality.

The second, the discount rate profoundly affects the difference in value. Compare 5% with 10% with the current yield on 30-year Treasuries of 1.6% [ed: 4.9%].

Discount Rate Isn’t Constant

Back to that billion dollars in 30 years. Why is that worthless to me? Is a billion dollars in 1000 years worth anything to you? No. You won’t be alive to benefit from it. 100 years? Same.

If you’re 20-something, a billion dollars in 30 years is awesome. You can do whatever for 30 years, secure in the knowledge that your financial options will explode at the end of that period. And you’re likely to be alive to experience it. For me, though, a billion dollars after either I’m too old to enjoy it [ed: hello, Parkinson’s] or after I’m dead is worth nothing. I’d literally rather have one dollar in my hand today.

(All numbers taken from the morbidly fascinating https://flowingdata.com/2015/09/23/years-you-have-left-to-live-probably/).

One of the challenges working with the time value of money is determining the discount rate. My discount rate here in the last stage of my career is not constant. That’s what I was missing. My colleagues have a smooth discount rate over the 10–20 year time scales we are used to. I stop financially caring about the future before they do. Here are the life probabilities for a 30-year-old male.

As long as my young colleagues get paid off some time in the next 30 years they have a high probability (relative to me) to have a long time (relative to me) to enjoy their money.

My “discount rate” isn’t a single rate at all. Past a certain horizon, probably 30 years, it’s infinite. Before that it’s steep. I’m much more interested in money while I can enjoy spending it.

Time Value Arbitrage

If you actually offered me a billion dollar 30-year principle-only bond I wouldn’t just use it to light a bonfire. I’d go find a bank (or similar counter-party with a smooth discount rate) and offer it to them. They’d give me the $600M today minus whatever for their transaction costs and risk of non-payment. I’d have instant options for retirement. They’d have more money in the future. Everybody happy.

Which brings me back to my disconnect with my (younger) colleagues. Tech compensation is biased towards the long term:

• 4–5 year vesting schedules,

• Further delays before liquidity [ed: and getting worse—topic for another day],

• The risk of equity value dropping to zero and thus the need for a portfolio of equity, further extending the timeframe for The Big Score.

4 years versus 8 years versus 12 years to liquidity is no big deal when you’re 30. For me, though, 4 years is a significant fraction of the time I have left to enjoy money.

I don’t have an answer to this mismatch. Much of the work I do creates value over decades. In the time I have left I have to both:

• Earn money so I have financial options &

• Enjoy the time.

Is there a way to sell long-term benefits for short-term revenue? Technology compensation is stacked against me. At the very least I’m glad I have a frame for understanding my frustration.

Epilog: Finance Matters

Finance profoundly affects our work and our lives as geeks. It needs to be normal to talk about it. (There are also some cool concepts to explore in there — ask me about options pricing algorithms some time). Talking about it is part of helping geeks feel safe in the world.

Finance profoundly affects the options we will have for the rest of our lives. Gaining financial literacy and then acting sensibly based on that knowledge is low-cost and low-risk. I hope that talking about how financial tradeoffs change as context changes will encourage you to learn, apply what you learn, and benefit thereby.

[ed: Updated Mortality Curve]

Because Parkinson’s is now part of my life & because Parkinson’s doesn’t so much affect lifespan as it affects quality of life, this data doesn’t help much but I put it here for completeness.

I have been diagnosed with Parkinson’s. Parkinson’s is like that advancing line of destruction, but operating on the brain. Alpha-synuclein (a protein) misfolds and, a little like prions, the misfolded proteins convince normally folded proteins to join the dark side. (This stuff is all so unspeakably cool if only it wasn’t happening to people.)

The proximate cause for this announcement is all the questions I’ve gotten from folks watching Still Burning & seeing my hand shake. By the time tremors appear, that line of misfolding has progressed far enough to destroy the 60-80% of the substantia nigra. The substantia nigra creates the dopamine that helps regulate movement (not the dopamine that used to form memories—I told you this shit was cool!)

Feelings

Not gonna lie—this has been an emotional shock for me. I’ve tried to figure out why it’s been so hard. I just turned 65 & I’ve been keenly aware of the advance of time for a while. I think the disturbing aspect of my new situation is that my best case scenario for aging just got a lot worse. My 90-year-old ex-father-in-law is still sharp & reasonably mobile. I comforted myself that I might grow old like that.

Now…not gonna happen. Over the next 5-15 years the tremors will worsen & spread (just my left forearm & thigh at the moment). Then my balance will go, followed by, well, it gets worse. Look it up if you want the details.

The expectation of increasing limitations has got me shifting my personal & business priorities. It’s the time value of time. If I can do something joyous this year it’s more valuable to me than doing the same thing next year & way more valuable than doing it in 5 years.

Business

Part of me wishes I could just say to hell with it & retire. I have a copy of Pauling’s General Chemistry I’ve been meaning to plow through, then Alberts’ Biochemistry of the Cell. I want to use the tools I’ve always used to stare this thing in the face.

I can’t afford to stop my business. I need to make as much progress towards financial security as I can as quickly as possible. However, I won’t earn at the expense of enjoying my best, most mobile years. Offer me $100m/year for 3 years of 60-hour days and I’ll just laugh. Go ahead, try it. In practice I’ll either get lucky or I’ll muddle through. But I sure as hell won’t do something I don’t want to do in exchange for distant futures.

(If you were thinking of booking me for coaching, consulting, or a talk for your team, might I suggest you contact my business manager sooner rather than later?)

Next?

I see no reason to waver from my mission of helping geeks feel safe in the world. I’m certainly going to keep coding interesting projects. Art & music are going to get more difficult but I have some ideas. Thinkies are taking on a life of their own. This newsletter will still be mostly on topic with occasional excursions because I have fewer fucks to give. Other than that, we’ll just see.

I’ll leave you with this poetic summary of the situation.

In

I talked about how I think about human connection as someone with both a history of trauma & a twisty brain. We can establish a bridge with another person. We can walk half way across. We can meet in the middle. That’s connection.

(I’m the one in the hat, in case you don’t recognize me.)

That connection can ripen & mature over time (topic for another day) but the basics remain—a bridge, and half way across.

Not all connections are good, are nourishing. Sometimes there’s just not a fit—my needs don’t fit what you can offer, your needs don’t fit what I can offer. Sometimes that lack of fit is down to timing, sometimes it’s structural, seemingly permanent.

As someone who both craves & fears connection, how can I spot connections that are likely not to end up mutually nourishing? Put bluntly, what do red flags look like in the bridge analogy? What can I do when I realize this connection is not a connection that’s healthy for me to continue in?

Too Far: Me

One form of red flag is when I go too far—I go all the way to the other person’s side of the bridge. This happens when I go to the middle but the other person isn’t joining me.

This manifests as, on their part:

• Cooler emotional tones

• Less vulnerability

• Less time investment

• Less responsiveness

When I’m feeling lonely, desperately in need of connection, I sometimes try to force the issue by further upping my tone, disclosure, time, responsiveness.

What’s wrong with going too far over? First, it drives some people away. Too much, too soon, leave me alone, creep. Second, there’s no end to how much I can give to try to force connection. Third, the folks who aren’t driven away tend to take advantage of, encourage, my over-giving. Not sustainable. Not a mutually nourishing connection.

Too Far: Them

The reverse happens as well. I connect with someone & they immediately become my best friend—I’ll give you this, and that, and this, and that. Let me tell you my whole life story. Buy you presents. Take you to meet my family.

NGL this feels good for a moment. I wanted connection. I got it. And I didn’t really have to work for it. What’s wrong?

Nothing is wrong with all those good things flowing between us, but in good time & in good proportion. Someone who is willing to instantly give give give doesn’t have a good sense of their own boundaries. If they don’t have a sense of their boundaries, they won’t have a sense of my boundaries either.

I’ve been lied to, stolen from, & manipulated by people who were instantly sharing too much. If they don’t have boundaries with themselves, they won’t have boundaries with me. And vice versa. Hard lesson but there you are.

Conclusion

I keep open the possibility of connection. I try to stay aware of where I am on the bridge. When I start edging over to their side, I cool myself off (& reflect on why I want to go too far). When someone edges over to my side, I cool myself off. If they insist on trying to be on my side of the bridge, I shut down the connection. Life is too short & the consequences too dear.