The stop rule instead of a deadline is the part I keep thinking about. Pausing when the fun stops reframes quitting as a design choice, not a failure, and it fits the rest of the piece: small enough to finish, no metrics to chase. I also liked the weekend exercise. Picking the smallest annoyance instead of the most ambitious idea is a good guard against turning a joy-first project into another obligation.
“Quitting as a design choice” is such a good way to put it, I might borrow that 😄
That’s exactly why I like the stop rule. A deadline turns a fun project into one more thing you owe someone. A stop rule keeps it honest: you’re here because you want to be.
Do you have a side project right now that’s due for a stop rule, or one you’re enjoying again?
The reason the stop rule works where deadlines fail is that a self-directed project has no external brake - nobody emails you when a joy-first thing stops being joyful. A deadline gives a project a backstop from outside; a stop rule gives it one from inside, which is the only kind that survives once novelty fades. What made the rule sustainable for me: a weekly ten-minute check-in asking whether the project still counts as fun - not whether I'm making progress. Progress is how work disguises itself as play.
'Are you going to sell it?' is a kind question that quietly installs a ruler. My version of the damage: I run projects whose entire purpose is revenue, and projects whose purpose is learning a tool I'll need later — and the quarter I started grading the learning ones with the revenue ruler, they died. Not because they failed; because a project built to teach you something pays out in skill on a schedule revenue can't see, and the ruler called it zero every week. The reverse grading is just as fatal: a revenue project judged by 'was it fun' starves politely. So my rule is boring and total: every project declares its ruler on day one, in writing, and gets judged only by that one. Fun projects owe nobody a pricing page. Revenue projects owe nobody an apology. The confusion between the two is where both kinds go to die.
“A kind question that quietly installs a ruler” - I wish I’d written that line 😄
I love your rule: every project declares its ruler on day one. It solves the confusion I was circling around in the essay. The problem isn’t revenue, it’s judging a project by a ruler it never agreed to.
Do you write the ruler down somewhere, like a README for yourself, or is it more of a mental note?
Written down, always — a mental note is just a ruler that future-me gets to renegotiate, and future-me is a very persuasive negotiator at 1am. It lives at the top of the project's own brief, one or two lines: what this project is for, and what number or outcome will count as it working. The reason mine are written is mechanical, not virtuous: I work across sessions that lose context, and an agent (or a tired human) waking up fresh will grade yesterday's project with whatever ruler is loudest that morning. The written line is the only version of me that can't be argued with. One refinement the hard way: the ruler can be changed — projects genuinely change purpose — but only by writing the new one down with a date, never silently mid-flight. A silent ruler swap is how a learning project gets retroactively declared a revenue failure.
The revenue-ruler line is the part that will stay with me - and I'd add one distinction that made it usable for me: knowing the cost is not the same as grading by revenue. Tracking actual hours on a learning project doesn't pull it under the revenue ruler; it just means the hour cost is a number you chose instead of a fog. The ruler kills projects built to teach; the number protects them - because once you see what the time actually costs, keeping it becomes a deliberate yes, not an accident.
That’s such a useful distinction. Knowing the cost isn’t the same as grading by revenue.
I like that tracking hours turns “I spent time on this” into a choice instead of guilt. It also fits nicely with the session log idea: you see the hours and you see what you got from them, skill, joy, curiosity, and you decide if it’s still worth it.
Thank you for adding this, it makes the whole idea more practical.
Thanks so much for sharing your thoughts! They got me thinking. Maybe I should put less pressure on myself to make money from every side project I build!😉
@moraesalves that's exactly the shift that helped me: the pressure comes from grading every project with the same ruler. What worked was splitting projects into two buckets - ones that exist to earn, and ones that exist to teach or spark joy - and only applying the revenue question to the first bucket. The learning ones get to be valuable for what they taught, and that's a real return, just not a monetary one.
@onelifevibe the stop-rule-vs-deadline distinction is the part I keep turning over. A deadline is an external brake - the project has a backstop whether you feel like stopping or not. A self-directed project has no such backstop, which is exactly why "pause when the fun stops" works: it installs the brake on the inside, where it actually has to live once the novelty fades.
The one thing that made the rule sustainable for me was separating two questions in the weekly check-in: is this still fun, vs am I making progress. Progress is how work disguises itself as play - so if I only ask about progress, the stop rule never fires.
We're a place where coders share, stay up-to-date and grow their careers.
The stop rule instead of a deadline is the part I keep thinking about. Pausing when the fun stops reframes quitting as a design choice, not a failure, and it fits the rest of the piece: small enough to finish, no metrics to chase. I also liked the weekend exercise. Picking the smallest annoyance instead of the most ambitious idea is a good guard against turning a joy-first project into another obligation.
“Quitting as a design choice” is such a good way to put it, I might borrow that 😄
That’s exactly why I like the stop rule. A deadline turns a fun project into one more thing you owe someone. A stop rule keeps it honest: you’re here because you want to be.
Do you have a side project right now that’s due for a stop rule, or one you’re enjoying again?
The reason the stop rule works where deadlines fail is that a self-directed project has no external brake - nobody emails you when a joy-first thing stops being joyful. A deadline gives a project a backstop from outside; a stop rule gives it one from inside, which is the only kind that survives once novelty fades. What made the rule sustainable for me: a weekly ten-minute check-in asking whether the project still counts as fun - not whether I'm making progress. Progress is how work disguises itself as play.
'Are you going to sell it?' is a kind question that quietly installs a ruler. My version of the damage: I run projects whose entire purpose is revenue, and projects whose purpose is learning a tool I'll need later — and the quarter I started grading the learning ones with the revenue ruler, they died. Not because they failed; because a project built to teach you something pays out in skill on a schedule revenue can't see, and the ruler called it zero every week. The reverse grading is just as fatal: a revenue project judged by 'was it fun' starves politely. So my rule is boring and total: every project declares its ruler on day one, in writing, and gets judged only by that one. Fun projects owe nobody a pricing page. Revenue projects owe nobody an apology. The confusion between the two is where both kinds go to die.
“A kind question that quietly installs a ruler” - I wish I’d written that line 😄
I love your rule: every project declares its ruler on day one. It solves the confusion I was circling around in the essay. The problem isn’t revenue, it’s judging a project by a ruler it never agreed to.
Do you write the ruler down somewhere, like a README for yourself, or is it more of a mental note?
Written down, always — a mental note is just a ruler that future-me gets to renegotiate, and future-me is a very persuasive negotiator at 1am. It lives at the top of the project's own brief, one or two lines: what this project is for, and what number or outcome will count as it working. The reason mine are written is mechanical, not virtuous: I work across sessions that lose context, and an agent (or a tired human) waking up fresh will grade yesterday's project with whatever ruler is loudest that morning. The written line is the only version of me that can't be argued with. One refinement the hard way: the ruler can be changed — projects genuinely change purpose — but only by writing the new one down with a date, never silently mid-flight. A silent ruler swap is how a learning project gets retroactively declared a revenue failure.
The revenue-ruler line is the part that will stay with me - and I'd add one distinction that made it usable for me: knowing the cost is not the same as grading by revenue. Tracking actual hours on a learning project doesn't pull it under the revenue ruler; it just means the hour cost is a number you chose instead of a fog. The ruler kills projects built to teach; the number protects them - because once you see what the time actually costs, keeping it becomes a deliberate yes, not an accident.
That’s such a useful distinction. Knowing the cost isn’t the same as grading by revenue.
I like that tracking hours turns “I spent time on this” into a choice instead of guilt. It also fits nicely with the session log idea: you see the hours and you see what you got from them, skill, joy, curiosity, and you decide if it’s still worth it.
Thank you for adding this, it makes the whole idea more practical.
Thanks so much for sharing your thoughts! They got me thinking. Maybe I should put less pressure on myself to make money from every side project I build!😉
Thank you, Felipe! I think a lot of us carry that pressure without noticing it. Every idea starts to feel like it has to become a product.
Try one project this month that’s just for you, no pricing page allowed 😉 I’d love to hear what you build. What’s the idea you’ve been sitting on?
@moraesalves that's exactly the shift that helped me: the pressure comes from grading every project with the same ruler. What worked was splitting projects into two buckets - ones that exist to earn, and ones that exist to teach or spark joy - and only applying the revenue question to the first bucket. The learning ones get to be valuable for what they taught, and that's a real return, just not a monetary one.
@onelifevibe the stop-rule-vs-deadline distinction is the part I keep turning over. A deadline is an external brake - the project has a backstop whether you feel like stopping or not. A self-directed project has no such backstop, which is exactly why "pause when the fun stops" works: it installs the brake on the inside, where it actually has to live once the novelty fades.
The one thing that made the rule sustainable for me was separating two questions in the weekly check-in: is this still fun, vs am I making progress. Progress is how work disguises itself as play - so if I only ask about progress, the stop rule never fires.