I like building. Give me a feature idea and an evening, and I'm happy. Give me a list of ten people to write to about my app, and I suddenly notice that the settings screen needs a better empty state.
For a long time I didn't see this as a problem. I was working every day, after all. My app, AimYear, kept getting new features. What it didn't get was users. Users come from writing to people, asking what they think, posting what I made and hearing "no".
At the end of September I started recording my own time in AimYear. My agent starts a timer when I begin a task and writes down what I did, so I don't fill in anything. In the first week of October I spent about 20 hours a week on my aim, and 8 of them went to comfortable work: features, polishing, small fixes that felt productive. Nobody had asked for any of it.
Last week the same record said 15 hours on the aim, and 46 minutes of it comfortable. My agent marked the rest as the hard part: outreach, publishing, selling. It isn't perfect: I finished my planned main step only on friday evening. But now I know where the week went.
I'm not unusual. On Hacker News a solo founder put it like this: "I physically cannot stop building even when I know I should be doing something else" (HN). On r/SaaS another one wrote: "I wasnt building because users needed features. I was building because building feels good and selling feels terrifiying" (Reddit).
Why the comfortable task wins
We pick what feels urgent, even when it pays less. In five experiments, Meng Zhu, Yang Yang and Christopher Hsee gave people a choice between a task with a bigger reward and a task that only looked urgent, with an expiry that meant nothing. People chose the urgent one, and the effect was stronger in people who saw themselves as busy. Reminding them of the payoffs at the moment of choice reduced it (Journal of Consumer Research, 2018). A failing test or a small bug always looks urgent. A message to a customer never does.
Under load, we also pick what we can finish. Doctors in a hospital emergency department took easier patients when the department got busier. In the moment it looked efficient, but after adjusting for how hard the cases were, it meant worse throughput, and those doctors learned less. In the lab study of the same paper, 76% of people under a heavy workload picked the easy task next, against 64% under a light one. The reasons were fatigue and the good feeling of crossing something off (KC, Staats, Kouchaki and Gino, Management Science, 2020; summary at Kellogg).
And we put off what makes us feel bad. Fuschia Sirois and Timothy Pychyl describe procrastination as short-term mood repair: we avoid a task because of how it makes us feel now, and the cost lands on our future self (2013 review). A pull request makes me feel competent and a cold email makes me feel like a beggar, so I open the pull request first.
I expected to find proof that willpower is a battery that runs out, and didn't. That idea, called ego depletion, was tested in 23 labs with 2,141 people using the same protocol, and the effect was close to zero (Hagger et al., 2016). So when I tell myself "I'm out of motivation", something else is probably going on: every time I pick the next task, I choose again, and the comfortable task wins most of those choices unless something makes the other one visible.
Try it: ask your agent where your week went
If you work with a coding agent every day, it already saw most of your week. It can read your commits, and Claude Code and Codex keep your past sessions on disk. So ask it. Paste this into Claude Code, Codex, Cursor or any agent that can read your files:
Look back at my last 7 days of work and tell me where the time went. Read only: change nothing.
1. Ask me for my git author name and where my projects live, if you don't know them.
2. Gather what you can see: git commits I authored in the last 7 days in each of my repos, your own past sessions with me if you can read them (Claude Code keeps them in ~/.claude/projects, Codex in ~/.codex/sessions), and my calendar if you have access to it. Skip automated sessions: anything run by a scheduler, a script or from a temp folder.
3. Estimate time from the gaps between timestamps, not from the number of commits. Treat a gap of more than 90 minutes as a break.
4. Sort the work into three groups:
- Building: code, features, refactoring, tooling, design, research.
- Reaching people: talking to users, sales and outreach, posting or writing in public, answering feedback. Anything a person outside could see or reply to.
- Everything else.
5. Give the hours and the share of each group, say what you could not see, and mark each figure as measured or guessed.
6. Name up to three things I built that nobody has asked for yet, and the one people-facing task I kept putting off. If you can't tell, say "not enough evidence" instead of guessing.
7. End with one line I can share, in this form: "Last week: X% building, Y% reaching people, Z% other. What I put off: ..." Everything above that line is for me; the line itself must have no client names and no private details.
The hours are an estimate, so don't trust the decimals. The useful parts are the share and the last line, because they're hard to argue with.
Here's mine, from running it on my Mac today:
Last week: 75% building, 18% reaching people, 7% other. What I put off: the first outreach for a new pilot offer, open since October 30.
That's much less flattering than the AimYear number above, and both are true. AimYear counts only the time toward my aim; the prompt counts all of my work, including a client project and a second product I kept building. The agent also found the task I'd been avoiding by reading the dates in my own task notes, and it was right.
Share your line in the comments. I'm curious how many of us are at 90% building, and I'll reply to every one.
What helped me: reporting in public
I knew I was avoiding outreach long before I measured it, and knowing didn't change much. What changed my week was having to say in public what I actually did.
A meta-analysis of 138 experiments with almost 20,000 people found that monitoring your progress helps you reach a goal. It helped more when the progress was written down, and more again when it was reported or made public: an effect size of 0.47 to 0.55 for reported or public monitoring, against 0.19 for monitoring kept private (Harkin et al., Psychological Bulletin, 2016). Most of those studies were about health goals like weight or blood pressure, and I see the same pattern in my work.
Two findings shape how to do it:
- Post what you did, not what you will do. When people announced an identity goal ("I'm going to be a lawyer") and others noticed it, they then worked on it less, because the attention gave them a premature feeling of being there already (Gollwitzer et al., Psychological Science, 2009). A report of what you did can only come after the work, so it can't give you that feeling in advance.
- Choose an audience whose opinion matters to you. Sharing a goal raised commitment and performance when the audience had higher status than the person, and did nothing when it had lower status (Klein et al., Journal of Applied Psychology, 2020). A post that nobody you respect will read doesn't create much pressure.
(You may have seen "people who send weekly progress reports to a friend reach 76% of their goals". That number comes from a small 2007 conference study with 149 people. The meta-analysis above is much stronger evidence for the same idea.)
Where to post
Each place gives a different audience, so it's worth picking by who you want watching:
- LinkedIn: colleagues, former bosses, possible clients, the higher-status audience from the Klein study. Post here rarely, about things that matter: a launch, an article, a result.
- WIP: a community of makers who post what they finished each day, often as short todos tied to a project. Good for the daily habit, and people there notice when you go quiet.
- Bluesky: a calmer developer crowd. A short daily or weekly post fits.
- X: the #buildinpublic crowd is large and fast. Good for weekly numbers and screenshots.
What I post: what moved this week, one number (the share of time on the hard part), and the thing I put off. The last one is the most uncomfortable to write, and it's the one that makes me do it the next week.
Where AimYear fits
I built AimYear for exactly this, and I use it every day. It works inside the agent you already use: Claude, ChatGPT, Claude Code or any MCP client. You set one big aim for the year, your agent plans one main step a day with you, starts the timer, and writes down what moved. You never fill in a form, and at the end of the week you see the share of your time that went to the hard part, without asking for it.
Connecting your agent is free today: aimyear.com. The apps for phone and computer are coming soon. They show the same record and timer, so you can start work at the desk and check the week from your phone. With Pro, AimYear will also draft an evening post from what you actually did, never from plans, and send it to WIP and Bluesky when you press Post. If you'd rather start with the method, the guide walks through setting an aim you can count and finding the hard step in it.
Either way, run the prompt and post your line in the comments.
Top comments (0)