My Developer Habit Tracking System: How I Use Routine Blocks to Ship Side Projects

#devjournal #productivity #sideprojects #softwaredevelopment

My Developer Habit Tracking System: How I Use Routine Blocks to Ship Side Projects

I have started and abandoned more side projects than I can count. Not because the ideas were bad or because I lost motivation overnight. The pattern was always the same: I would work intensely for a few weeks, skip a couple of days, lose momentum, and never come back.

Last year I decided to figure out why. The answer was not about motivation or discipline. It was about the difference between tasks and routines.

The Task vs Routine Confusion

Most productivity systems treat everything as a task. "Build landing page" goes on the same list as "practice algorithms" and "review pull requests." But these are fundamentally different things:

Tasks are one-time actions with a clear endpoint. Build a landing page. Fix that auth bug. Write the README.
Routines are repeating behaviors that compound over time. Daily algorithm practice. Weekly code reviews. Morning planning sessions.

When I mixed them together, routines always lost. A task like "fix the payment bug" feels urgent. "Practice algorithms for 30 minutes" does not. So the routines got pushed to "later," and "later" became "never."

The moment I started tracking them separately, everything changed.

The Routine Blocks System

I call my approach "Routine Blocks" because it works like Tetris. Instead of a flat to-do list, I visualize my week as a grid of time slots and drop recurring blocks into them.

Here is what my weekly schedule looks like:

Weekly Routine Grid
═══════════════════════════════════════════════════════════
         Mon    Tue    Wed    Thu    Fri    Sat    Sun
Morning  [ALG]  [ALG]  [ALG]  [ALG]  [ALG]  [OSS]  [---]
         [PLAN]                              [BLOG]
Afternoon              [CR]          [CR]
Evening  [PUSH] [PUSH] [PUSH] [PUSH] [PUSH]
         [READ] [READ]               [READ] [READ]
═══════════════════════════════════════════════════════════

ALG  = Algorithm practice (30 min)
PLAN = Weekly planning session (Mon only, 20 min)
CR   = Code review on open source projects (45 min)
PUSH = Git push - commit something, anything (30 min)
READ = Technical reading - docs, articles, RFCs (20 min)
OSS  = Open source contribution (60 min)
BLOG = Write a dev blog post (90 min)

The key insight: these blocks are not tasks. I do not check them off and move on. They repeat every week, automatically. The question is never "should I do algorithm practice today?" but "it is Tuesday morning, algorithm block is up."

Why Visual Scheduling Beats To-Do Lists for Habits

Three reasons this grid format works better than a list:

1. You see the gaps. A to-do list hides the fact that you have nothing scheduled for Wednesday evenings. A visual grid makes empty slots obvious. If there is a gap, you can fill it or keep it intentionally empty for rest.

2. You see the overload. When I first filled in my grid, I realized I had packed every single evening slot. That was clearly unsustainable. The visual format made it obvious before I burned out.

3. You build spatial memory. After a few weeks, I stopped checking the schedule. Tuesday afternoon meant code review. It was automatic. The visual layout helped my brain create those associations faster than a text list ever could.

The ONE Thing Filter

The hardest part of routine blocks is deciding what goes on the grid. You cannot fill every slot, and not every habit matters equally.

I use a filter borrowed from Gary Keller's "The ONE Thing" philosophy. Before adding a routine block, I ask one question:

What is the ONE thing I can do consistently that would make shipping this project easier or unnecessary?

For my current side project (a developer tool), the answer was clear: the single most important routine was a daily Git push. Not because every commit is meaningful, but because maintaining the habit of touching code daily prevents the "I have not opened this project in two weeks" death spiral.

Everything else on my grid supports that core routine:

Algorithm practice keeps my problem-solving sharp so coding sessions are more productive
Code review exposes me to patterns I can apply in my own project
Technical reading prevents me from reinventing solutions that already exist
Weekly planning ensures I know what to work on during my Git push blocks

If a routine does not connect back to shipping the project, it does not earn a slot on the grid.

My Before and After

Here is what my side project output looked like before and after implementing this system:

Before (Q3 2025):

3 side projects started, 0 shipped
Average streak before abandoning: 11 days
No consistent coding schedule
Algorithm practice: "when I feel like it" (roughly twice a month)
Blog posts written: 0

After (Q4 2025 through Q1 2026):

2 side projects started, 1 shipped to production, 1 at 80% completion
Current coding streak: 67 days
Algorithm practice: 5 days/week (missed only 4 days in 3 months)
Blog posts written: 6
Open source PRs: 12

The numbers are not extraordinary. That is kind of the point. I did not become 10x more productive. I just stopped having zero-output weeks. The consistency compounded.

Practical Tips for Building Your Own Routine Blocks

If you want to try this system, here are the patterns that worked for me:

Start with 3 blocks, not 15. My first grid had 4 routines. I added more only after the first 4 felt automatic (about 3 weeks in).

Protect your morning slot. Whatever your highest-priority routine is, put it in the morning before work/meetings can steal the time. For me, that is algorithm practice. For you, it might be writing or reviewing code.

Use frequency tiers. Not everything needs to be daily:

Frequency tiers:
  Daily     → Git push, Algorithm practice
  Weekdays  → Technical reading
  2x/week   → Code review (Tue, Thu)
  Weekly    → Planning (Mon), Blog (Sat), OSS (Sat)
  Monthly   → Side project retrospective

Track streaks, not perfection. Missing one day is fine. Missing two days in a row is where habits die. I track current streak and longest streak for each routine. The goal is not 100% completion. It is avoiding two consecutive misses.

Separate the grid from your task list. This is critical. Your routine grid should live in a different place than your to-do list. If they are in the same view, tasks will crowd out routines again. I keep my task list in one view and my weekly routine heatmap in another.

The Tool I Use

Full disclosure: I ended up building the routine blocks system into STACKFOLO, the developer project dashboard I work on. It started as a spreadsheet, then a Notion template, and eventually became a feature because I wanted the routine grid right in my Chrome new tab where I would see it dozens of times a day.

The built-in version has a weekly heatmap, streak tracking, 50+ habit templates (algorithm practice, code review, pomodoro, and others), and time slot categories (Morning, Afternoon, Evening, Anytime). It also connects to the ONE Thing goal system, so each routine links back to a specific project goal.

But honestly, the system works with a spreadsheet too. The format matters less than the principle: separate your routines from your tasks, make them visual, and filter ruthlessly using the ONE Thing question.

If you have been struggling to maintain consistent habits around your side projects, try building a routine grid this week. Start with just three blocks. See if the consistency compounds the way it did for me.

If you want to try STACKFOLO's built-in Routine Blocks, it is free on the Chrome Web Store.

Try STACKFOLO free on Chrome Web Store →