How I Use a Weekly Timetable to Balance My Dev Job and Side Projects

Last year I had a problem that I think most developers share: I wanted to work on side projects, but after 8 hours of coding at my day job, I never had the energy or structure to make it happen.

I tried blocking "side project time" on my calendar. That lasted about a week. I tried waking up early. That lasted three days. I tried the "just do 30 minutes a day" advice, but without knowing which 30 minutes or what to work on, those sessions rarely materialized.

What finally worked was building a visible weekly timetable. Not a to-do list, not a vague calendar block, but a 7-day grid that mapped specific routines to specific time slots. Here is the system, and why it works when other approaches did not.

The Problem with "Find Time for Side Projects"

The advice you usually hear is some version of "schedule it" or "make it a priority." This is technically correct and practically useless.

Here is what actually happens when a developer tries to fit side projects into their week:

• Monday evening: "I'll code after dinner." You eat, check your phone, and suddenly it is 10pm.
• Tuesday evening: "Tonight for real." You open your laptop, stare at the code for 5 minutes, cannot remember where you left off, close the laptop.
• Wednesday: You skip entirely. No guilt yet.
• Thursday: You feel guilty. You open the project. Spend 20 minutes just getting back into context. Write 10 lines of code. Feel unsatisfied.
• Friday: "I'll catch up this weekend."
• Weekend: You do a burst of 4 hours on Saturday, feel productive, then do nothing Sunday.

Sound familiar? The pattern repeats because there is no structure holding it together. You are relying on motivation and willpower, which are both exhausted after a full day of knowledge work.

Why a Visual Timetable Works

A timetable is different from a calendar or a to-do list in one important way: it maps routines to time slots across the entire week at a glance.

When you look at a 7-day-by-24-hour grid, you can immediately see:

• Where your committed time is (work, sleep, commute)
• Where your available blocks actually are
• Whether your side project time is realistic or wishful thinking

This visibility is the key. Most developers overestimate their available time because they think in terms of "evenings and weekends" without subtracting meals, exercise, family time, and the recovery period after focused work.

A timetable forces honesty. When you see that Tuesday evening has exactly one 90-minute block between dinner and sleep, you stop pretending you will "code for 3 hours" and start planning for what you can realistically do in 90 minutes.

My Weekly Timetable System

Here is the system I have been using for 6 months:

Step 1: Map Your Fixed Commitments

Fill in the non-negotiables first:

• Work hours (e.g., 9am-6pm weekdays)
• Sleep (e.g., 11pm-7am)
• Meals, commute, exercise
• Family or social commitments

This usually eliminates 70-80% of your week immediately.

Step 2: Identify Your Real Available Blocks

Look at what is left. For most employed developers, it comes down to:

• Weekday mornings (30-60 min before work, if you are a morning person)
• Weekday evenings (1-2 hours after dinner, energy permitting)
• Weekend blocks (2-4 hour chunks)

Be honest about energy levels. A 7pm Tuesday slot after a day of debugging production issues is not the same as a 9am Saturday slot with fresh coffee.

Step 3: Assign Routines, Not Tasks

This is the critical difference. Do not put "fix authentication bug" in your Tuesday 7pm slot. Instead, assign a routine:

• Tuesday 7pm-8:30pm: Side project coding
• Thursday 7pm-8pm: Code review + planning for weekend session
• Saturday 9am-12pm: Deep work on main side project
• Sunday 10am-11am: Weekly review + milestone check

Routines repeat every week. Tasks change. When you assign a routine to a slot, you remove the daily decision of "should I work on my side project tonight?" The answer is already decided.

Step 4: Start with 3-4 Slots Per Week

The biggest mistake is scheduling side project time every single evening. You will burn out in two weeks.

Start with 3-4 slots per week. That is 4-8 hours of focused side project time. More than enough to make real progress if the sessions are structured.

Here is what a realistic developer timetable looks like:

         Mon    Tue    Wed    Thu    Fri    Sat       Sun
7:00am   --     --     Jog    --     --     --        --
9:00am   Work   Work   Work   Work   Work   PROJECT   --
12:00pm  Work   Work   Work   Work   Work   Lunch     --
2:00pm   Work   Work   Work   Work   Work   Free      --
6:00pm   Dinner Dinner Dinner Dinner Dinner Dinner    --
7:00pm   Free   CODE   Free   Plan   Free   Free      --
8:30pm   --     --     --     --     --     --        Review
10:00pm  Read   Read   Read   Read   Read   Read      Read

Four side-project slots: Tuesday evening coding, Thursday evening planning, Saturday morning deep work, Sunday evening review. That is roughly 7 hours per week, enough to ship meaningful features on a monthly cadence.

Step 5: Make the Timetable Visible

A timetable that lives in a spreadsheet you never open is useless. The whole point is that you see your weekly rhythm at a glance.

I keep mine in a place I see every day. Every time I open a new browser tab, there is my timetable. The visual cue is the difference between "oh right, it is Tuesday, that is my coding evening" and "I wonder what I should do tonight."

What Changed After 6 Months

Before the timetable, I shipped maybe one side project feature per quarter. Random, inconsistent progress.

After 6 months of the weekly timetable:

• Shipped 3 features on my main side project
• Reduced guilt about not working on side projects (if it is not a scheduled slot, I am allowed to rest)
• Better work-life separation (side project time is defined, not infinite)
• Weekend sessions became 2-3x more productive because Thursday evening planning meant I always knew what to work on Saturday morning

The counter-intuitive part: having less scheduled time made me more productive. Constraints force focus. When you know you only have 90 minutes on Tuesday evening, you do not waste 20 minutes deciding what to work on. You open your plan from Thursday and start coding.

Pitfalls to Avoid

Do not fill every evening. Recovery time is not wasted time. If you code all day at work and then code every evening, you will burn out.

Do not skip the planning slot. The Thursday evening (or whenever you schedule it) planning session is not optional. Without it, your coding sessions become aimless and you lose the momentum advantage.

Do not treat weekends as unlimited. Schedule a specific block (like Saturday 9am-12pm) and stop when it ends. "I'll just code all weekend" leads to skipping entire weekends.

Do not beat yourself up for missing a slot. You will miss sessions. Illness, social events, bad days. The timetable survives because it repeats every week. One missed Tuesday does not break the system.

Getting Started This Week

1. Draw a 7-day grid (paper, spreadsheet, or a timetable tool)
2. Fill in your fixed commitments first
3. Pick 3-4 realistic slots for side project work
4. Assign one slot specifically for planning/review
5. Put the timetable somewhere you see it daily

I built this system into STACKFOLO, which has a 7-day timetable grid where you drag routines into time slots and see your week at a glance on every new tab. But the approach works with any tool that lets you visualize a weekly schedule. The key is not the tool. It is the visibility.

Stop trying to "find time" for side projects. Build a timetable that shows you where the time already is.