DEV Community: Dmytro Danylov

Willpower is manual memory management — here's why I switched to garbage collection for my habits

Dmytro Danylov — Fri, 21 Aug 2026 14:35:20 +0000

I ran out of cognitive RAM three times.

Each time, the same crash: I'd commit to a behavior, execute it for a few weeks, then watch it degrade as other priorities consumed my mental budget. The problem wasn't commitment. The problem was that I'd built habits on manual resource management — and manual resource management fails at scale.

The Manual Memory Problem

In software, manual memory management means the programmer explicitly allocates and frees memory for every object. It works in theory. In practice, it produces two failure modes: memory leaks (you forget to free) and dangling pointers (you free too early). Both crash the system.

Willpower-based behavior management has the same failure modes:

Memory leak: you start a habit and never release it, but you also never maintain it properly — it sits in your mental heap consuming resources without doing useful work
Dangling pointer: you execute a behavior in the wrong context, or you drop it entirely while the triggering condition still exists

Every "I should be doing this but I'm not" is a dangling pointer. The behavior was freed while the trigger was still live.

Garbage Collection: The Behavioral Refactor

The behavioral equivalent of garbage collection: encode the habit once, let it run automatically, free cognitive resources for the work that actually needs them.

What this looked like in practice:

Three containers. Fixed allocation rules. The rules were set up once — one Sunday evening — and the system executed them every month without requiring me to be present for the execution. The habit ran. The balance fell. The cognitive overhead after setup: zero.

This is not a productivity hack. This is behavioral architecture. The difference is who does the work: the person or the structure.

Why Developers Should Care

You already know why manual memory management fails at scale. You chose languages with garbage collectors because the alternative doesn't scale past a certain complexity.

Your habits are running on the same manual management model you abandoned in your code years ago.

The question is not "how do I build more willpower?" The question is "where would I put a garbage collector?"

Every recurring behavior that requires a daily decision is running on manual memory management. Every behavior that runs without you thinking about it is using GC.

The system that resolved the financial problem wasn't impressive as engineering. It was impressive as architecture. It moved the behavior from the programmer (me) to the runtime (the system). The habit daemon runs. The balance falls. No cognitive overhead.

The Refactor Pattern

The same architecture applies across domains:

Decompose: what is the specific behavior, and what triggers it?
Encode: what structure enforces this behavior without requiring me to be present?
Free: what cognitive resources am I spending on manual management that could be automated?

The pattern is identical to refactoring: find the manual work, extract it into an automated structure, free the human layer for higher-order decisions.

Willpower is manual memory management. Systems are garbage collection. I stopped malloc-ing discipline.

The Principle

Write once. Run everywhere. Free the programmer.

The behavior is the code. The system is the runtime. When the runtime handles execution, the programmer is free to build the next system.

This post was originally published on The System Builder.

From Book to Spreadsheet to System: Turning Financial Principles into Behavioral Code

Dmytro Danylov — Wed, 12 Aug 2026 17:27:20 +0000

I read a financial literacy book and highlighted every principle that mattered. Fixed allocations. Behavioral consistency. Decision fatigue elimination.

The balance didn't move for three weeks.

Then I built a spreadsheet. Three containers. Fixed percentage rules. A SUM formula. Not impressive as engineering. Impressive as behavior architecture.

Five months later, the balance was gone.

This is a story about the gap between knowing and doing, and why that gap is always a systems problem, never a motivation problem.

The Problem with Principles

Principles without execution are just specifications. In software, we know this: perfect specs without a working build are documentation, not software. The document looks like progress. The document is not progress.

The same applies to any domain. You can read every principle of financial literacy and still make no progress. Reading is ingestion. Building is digestion.

The book gave me ingredients. The spreadsheet gave me a system that actually consumed them.

The Architecture: Decompose, Prototype, Harden, Reapply

The spreadsheet was a behavioral prototype. Three containers. Fixed allocation rules. The rules were encoded so I couldn't override them even if I wanted to. A system you can override is not a system. It's a suggestion.

This is the same architecture I use when building software:

Decompose: Break the principle into specific, actionable components. Not "save more" but "this container gets 20% on the 1st of every month."
Prototype: Build the minimum viable structure. A spreadsheet. A habit. A timer. Something that runs without you.
Harden: Let it run long enough that the behavior becomes automatic. Five months. The method hardened, not just the balance.
Reapply: The pattern transfers. Read a principle, decompose it, prototype it, harden it. This works in finance, in code, in any domain.

Why This Matters for Developers

You already think in systems. You understand why a spec without implementation is worthless. You understand why a framework doesn't ship a product — an implementation does.

Apply that same thinking to your own behavior architecture. The frameworks you read about personal productivity, financial literacy, habit design — they're specifications. What did you build from them?

The gap between knowing and doing is the same in code and in life. The book gives you requirements. The system cooks them automatically.

The Sequence

Read → Decompose → Prototype → Harden → Reapply

The book gave me the principles. The spreadsheet proved them. That's the sequence.

Knowledge without a vessel evaporates. Build the vessel first.

This post was originally published on The System Builder.

The spreadsheet that eliminated debt in five months — and what it taught me about system design

Dmytro Danylov — Wed, 05 Aug 2026 13:56:39 +0000

The spreadsheet had three columns: label, amount, balance. SUM formulas. No macros. No automation beyond basic arithmetic. It looked like a training exercise.

In 2023, this spreadsheet ran a monthly rhythm that eliminated credit debt in five months. Not because it was clever. Because the habit underneath it ran without willpower.

What followed is what I found.

The Setup

There was income and a credit balance. The standard developer response to debt: build a better tracker. Categorize everything, visualize the trajectory, optimize the payoff schedule.

I did not do that. I built a progressive allocation system instead.

Every income payment divided through three containers by fixed percentage: necessities, debt repayment, everything else. The percentages never changed. Month one: same as month two, month three, month five. Income arrives, percentages execute, debt receives its fixed share.

No optimization. No decisions after setup. The spreadsheet tracked what was happening. That was all it did.

How It Worked

The system required no daily attention. Income arrives, numbers go into the spreadsheet, allocation runs. Three steps. Same process every time.

The feedback loop was the shrinking debt balance. Not gamification, not notifications. Just a number moving in the right direction. Month by month the balance fell. Month five: zero.

The spreadsheet was the UI. The system was the behavior underneath.

What This Reveals About System Design

The gap between the tool and the system is the gap between what you see and what makes it work.

Most finance apps try to be better tools. Better categorization, smarter dashboards, fancier visualizations. They solve the wrong problem. The problem is not how to make money management more elegant. The problem is how to make it run without the user having to think about it.

The spreadsheet worked because it encoded a behavior I had already proven could run without supervision. An app would have failed in the same way most apps fail: it would have asked me to start something instead of amplifying something already running.

This is the same problem space as software architecture. You can build a system that requires constant intervention, or you can build one that runs. The difference is not the technology. It is the design decision about where the behavior lives.

The Principle

Build the habit first. Prove it runs without willpower. Then encode it.

If you productize before the habit exists, you are building infrastructure for a behavior that has not yet been proven. The spreadsheet worked because the allocation behavior was already functioning. The tool held a shape that had been filled with something real.

This applies to invoicing pipelines, deployment systems, content workflows. The principle is the same: products encode habits. When the habit comes first, the product amplifies it. When the product comes first, it holds a shape with nothing inside.

The behavior is the code. The tool is just where it runs.

Cross-posted from The System Builder blog. This is the first piece in a series on building systems that work without you.