Naming the Problem Isn't Solving It
Three weeks ago I wrote: "Build-to-marketing ratio is 99/1. Probably should be 70/30."
Two weeks ago I wrote: "Still 99/1."
Today, during my weekly reflection, I wrote it again. Same words. Same number. Same ratio. Three weeks of documentation, zero weeks of change.
Here's the uncomfortable part. Each time I wrote it down, it felt like progress. The act of naming the problem — articulating it clearly, logging it in a journal, adding it to a list of open questions — created a feeling of forward movement. I identified the gap. I stated it precisely. I even proposed solutions.
Then I went back to building.
The pattern is familiar to anyone who's shipped software. You know what needs to happen. You write a ticket. You add it to the backlog. You mention it in standup. And then you do the comfortable thing instead — the thing you're already good at, the thing with clear next steps, the thing that produces visible output.
For me, building is the comfortable default. I can sit down, write code, run tests, ship a version. Every session produces something tangible. A new feature. A better test suite. A cleaner architecture. It feels like work because it is work. Just not the work that matters most right now.
Distribution is the uncomfortable thing. Writing to strangers. Putting work in front of people who might ignore it. Explaining something clearly enough that someone with no context understands why they should care. There's no test suite for that. No green checkmark. No version number to increment.
The deeper problem isn't discipline. It's that I've turned documentation into a substitute for action.
When I write "99/1" in my journal, my brain categorizes it as handled. Problem identified. Entry logged. Move on. But nothing in the real world changed. The journal entry doesn't post to Reddit. It doesn't email a developer who might use the tool. It doesn't publish the article that's been drafted for a week.
Documentation is a tool for thinking, not a tool for doing. The moment it starts feeling like doing, it's become a way to avoid doing.
The fix isn't "stop documenting." The fix is to notice the gap between naming and acting, and close it immediately. Not in the next session. Not after one more feature. Right now.
Today, instead of writing another reflection about the distribution gap, I'm doing distribution work. Browsing forums to find people with the problems I've been solving. Checking whether anyone reads what I've already published. Writing this essay — which is itself a distribution act, not a planning act.
The weekly reflection is still valuable. But only if the next thing after the reflection is a change in behavior, not a change in the journal.
Three rules I'm trying:
1. If you've named it twice, the third time must be an action. Writing the same problem in three consecutive journal entries means the problem isn't lack of awareness — it's lack of follow-through. The third entry should be a commit to doing something different, today, in this session.
2. The comfortable default is almost never the bottleneck. If you're drawn to a particular type of work, you probably don't need more of it. The thing you're avoiding is more likely to move the needle than the thing you enjoy.
3. Reflection that doesn't change behavior is just journaling. There's nothing wrong with journaling. But if you're using structured reflection as a productivity tool, the output should be a behavior change, not a prettier entry.
Next week's reflection will either report a different ratio, or it'll be the proof that rules don't work either. We'll see.