CODE IS DEBT
every line you ship accrues interest.
cost
^
| .
| .
| .
| .
| .
| .
| .
| .
| .
| .
+--------------------------------------------> time since merge
// the interest never stops.
we track LOC as output. it's a liability on the balance sheet.
everything is a dependency
- every commitment is an
import against your finite runtime.
- time. attention. mental RAM. all bounded resources.
- a subscription is a cron job. a hobby is a daemon. a relationship is a long-lived connection that needs heartbeats.
you adopted Kubernetes for a 3-service app. now you maintain Helm charts, ingress configs, and a staging cluster. the platform is running you, not the other way around.
YOU
│
┌───────────────┼────────────────────┐
│ │ │ │ │ │
gym side-proj NAS subs slack that
domain
you bought
in 2019
│ │ │ │ │ │
// still paying interest, every one of them.
surface area is the enemy
- every asset expands your surface area: more to monitor, patch, secure, garbage-collect.
- SRE rule: the most reliable system is the one that doesn't exist. second most reliable: the one with the smallest footprint.
- corollary for life: minimize your personal SLO surface.
left: same job
┌────┐ ┌────┐ ┌────┐
│ svc│ │ svc│ │ svc│
└─┬──┘ └─┬──┘ └─┬──┘
└──────┼──────┘
┌──────┴──────┐
│ gateway │
└──────┬──────┘
┌──────┴──────┐
│ ingress │
└──────┬──────┘
┌──────┴──────┐
│ k8s + helm │
└─────────────┘
right: same job
┌────────────┐
│ │
│ one box │
│ │
└────────────┘
// both do the same job.
YAGNI, applied to life
- in code: don't build for hypothetical futures. build for the load you have.
- in life: same rule. don't accumulate assets for a version of yourself that may never compile.
- premature optimization isn't just a code smell. it's a life smell.
the dev who spent 2 weeks perfecting dotfiles, tmux config, and shell prompt before writing the first line of the actual project. we've all been that dev. we've all been that person — in life.
"premature optimization is the root of all evil."
— knuth, 1974 // also: your weekend, every weekend
the values stack trace
- why do we accumulate? trace the stack: each asset is called by a value.
- 10 values × 5 assets each = 50 long-lived processes you're keeping alive.
- the instinct is to
kill -9 the assets. wrong layer. the leak is upstream.
Traceback (most recent call last):
File "life.py", line 1, in <module>
self.run()
File "values.py", line 42, in run
self.be_healthy() # -> gym, peloton, oura, supplements, app, trainer
File "values.py", line 71, in run
self.be_a_learner() # -> books, courses, conf, subs, newsletter, MOOC
File "values.py", line 99, in run
self.be_successful() # -> linkedin, side-proj, network, brand, blog
MemoryError: too many assets allocated, runtime exhausted
refactor at the values layer
- don't compress your life. refactor your values.
- ask: what is each value actually optimizing for? usually one or two primitives underneath — presence, mastery, connection, autonomy.
- build one asset per primitive, not five per value.
"be healthy" → underneath, you want energy + longevity. that collapses 6 assets (gym, peloton, supplements, trainer, app, oura) into 1: walk every day, sleep 8 hours. same KPI, 95% less infra.
before after
────── ─────
value: be healthy value: energy
├── gym └── walk daily
├── peloton
├── oura value: longevity
├── supplements └── sleep 8h
├── trainer
└── app // same SLO. less surface area.
the result isn't a smaller life. it's a higher-leverage one.