Balancing Work, School, and Projects: A Simple Schedule

Balancing work, school, and projects is often presented as a scheduling problem. For me, it has never worked that way. I do not follow written schedules, fixed study plans, or rigid weekly routines. Projects are a hobby first. I work on them when I feel like working on them. That has been the most accurate description of how I’ve actually built things over the past few years.

Because of that, this is not a guide about calendars or time blocking. It is a description of a different pattern: working in sprints instead of steady daily routines, and using interest as the primary driver instead of strict structure.

The sprint pattern

My project work has almost always happened in bursts. I’ll code every day for a week. Then I might not touch a project for another week or two. Sometimes it’s three days of heavy work, then nothing for several days. The length of these bursts is not consistent. It usually falls somewhere between a couple of days and two weeks.

There is no written plan behind this. When an idea is interesting, I work on it. When it stops being interesting for a moment, I step away. When I come back, I either continue or start something new. Over time, this has still resulted in finished projects, deployed sites, and working systems. The rhythm is irregular, but the output still accumulates.

This is important because it removes the assumption that progress must happen in equal daily slices. For some people, that works. For me, momentum comes in waves, not in evenly spaced hours.

How free time is actually split

Outside of work and obligations, my free time usually lands in one of two places: gaming or coding. If I feel like gaming, I game. If I feel like building something, I open a project instead. I haven’t noticed a meaningful difference in how much I code overall. The activity just shifts based on interest at the moment.

When I do want to ship something, I’ve consistently been able to commit weekends, nights, or both until the feature or project is finished. That has been true for portfolio sites, demos, and full-stack projects. There is no hidden system behind it. Just making time when a project matters enough to push it across the finish line.

How school and work fit into this

While I was in school, project work usually happened in the gaps between assignments. Since graduating and starting full-time work, the pattern has stayed mostly the same. Projects still happen when interest is high and time opens up. The difference now is simply being more aware that work takes a fixed portion of the week.

There was no moment where I switched to a strict balancing system. The same sprint-based pattern continues. The only adjustment has been recognizing that some weeks are heavier on work and some weeks have more room for projects.

What this means in practice

This approach has a few practical characteristics.

This is not a recommendation. It is simply the pattern that has produced real finished work for me.

Why this works for some people

Sprint-based work can be effective when projects are driven by curiosity and personal interest. Instead of forcing daily progress, it allows momentum to build naturally. When interest is high, output is high. When interest is low, stepping away prevents burnout.

The tradeoff is that progress does not look uniform week to week. But over months, projects still move from idea to completion.

Closing

Not everyone needs a written schedule to balance work, school, and projects. Some people operate better in steady routines. Others operate in bursts.

This post describes the second pattern. No rigid planning. No calendar systems. Just building when interest is present, committing extra time when something needs to be finished, and letting progress accumulate over time.