Started tracking my side project time properly this month. Last week: 2h50 fighting a Docker layer cache in GitHub Actions, 1h25 rewriting my logger for no reason anyone could defend, 1h05 reading docs and changelogs, 40 minutes on the actual feature I had planned. Six hours total, which is what I have. This was not an unusual week.
The rule that fixed this for me: infrastructure work only happens after the user-facing thing is deployed. If the feature is live, spend what is left however you like — go and make the build fast, enjoy yourself. The ordering is the whole trick, because the leftover time is the honest budget for it.
The logger rewrite is the tell. That is not engineering, it is avoidance — the comfortable, bounded, obviously-correct work you drift into when the real task is ambiguous. The cure is not discipline, it is removing the ambiguity: finish every session by writing down the exact next action, at the level of "add POST /projects that returns the created row".
"Work on billing" costs me half an hour of reloading context before I can start. A one-line concrete next step costs me none. Same brain, same tiredness, completely different session.
At six hours a week, batch by type. One night is code, one night is support and email, weekend morning is the thing needing actual thought. Switching between them inside a 90 minute session costs you a third of it and you will not notice it happening.
Three hours on CI is not a wasted week if you genuinely never touch it again. It becomes wasted when it reappears monthly, which is what a cache configuration reliably does.
@dockerfile_yuki · 18h ago · 3 replies
Your side project does not need CI.
I ran a product at about $1.4k/mo for fourteen months with a
deploy.shthat ran the tests, built, and pushed. No pipeline, no cache configuration, no matrix, no preview environments. You add CI when a second person can break your main branch or when a customer's weekend depends on you not shipping something broken. Neither is true for you yet.The cache work in particular is a trap because it is measurable and satisfying — the build goes from 4 minutes to 90 seconds and it feels like winning. You run that build eleven times a week.
Reply
Report
@leech_wrangler · 6h ago
Deleted the workflow, wrote nine lines of bash. Sunday I shipped two things instead of zero, which has not happened since February.
Reply
Report
@crypt_cass · 2d ago
Mild counterpoint: one job that runs
test && buildon push is twenty lines and catches the deploy where you forgot to commit a file. The trap is caching, matrices, preview environments and self-hosted runners, not the existence of CI.Reply
Report