Table of contents
Open Table of contents
The all-week hustle that burned me out
A few years ago, my side projects had no boundaries. I’d squeeze in an hour before work, chip away during lunch, and then open the laptop again at 10pm after dinner. The line between work code and my own code didn’t exist — it was all just code, flowing through whatever hours I could find.
The result? Neither side got my best. Work code suffered because I was mentally fragmented. Side project code suffered because I was tired. And I was tired all the time.
The breaking point came when I realized I hadn’t taken a full weekend off in three months. Not a single Saturday where I didn’t open an editor. My side projects had stopped being fun and started being a second job I wasn’t getting paid for.
Why weekends became the container
The fix wasn’t quitting side projects. The fix was giving them a container — a defined space where they could exist without bleeding into everything else.
Weekends turned out to be the perfect container. Here’s why:
Context switching is the real killer. Going from work code to side project code and back within the same day destroys focus. Your brain doesn’t switch that fast. By Saturday morning, work context has fully drained. You show up fresh.
The stakes are different on a Saturday. During the week, every hour of coding carries a faint guilt — should I be doing this for work instead? On a weekend, that guilt disappears. The time is yours. The code is yours. The only person you’re letting down by not shipping is future-you.
Two focused days beat five fragmented hours. A Saturday morning block of four uninterrupted hours produces more than five one-hour evening sessions. The depth you reach after the first hour — the state where you stop thinking about syntax and start thinking about design — is where the real work happens. You can’t reach it in 45-minute lunch-break bursts.
Moving side projects to weekends wasn’t about doing less. It was about doing more with the time I actually had.
What I stopped doing (and why it mattered)
The hardest part wasn’t the scheduling. It was saying no to the midweek itch. You know the one: it’s Tuesday afternoon, you just solved a tricky problem at work, and suddenly you have an idea for your own project. The urge to open a new tab and prototype it is almost physical.
I learned to write it down instead. A note in Apple Notes, a quick voice memo, a sticky on the desktop. Capture the idea, then let it marinate until Saturday. Most ideas don’t survive the marination — and the ones that do are actually worth building.
I also stopped trying to maintain momentum across the week. When a side project is an everyday thing, you feel like you’re always “in it.” That’s exhausting. When it’s a weekend thing, you get four days of distance. You come back with fresh eyes. Bugs that seemed impossible on Sunday night are obvious by Saturday morning.
The unexpected benefit: better work code
Here’s the part I didn’t see coming: when I stopped coding side projects during the week, my work code improved. Not because I was spending more time on it — because I was spending better time on it.
Without the temptation of switching contexts mid-day, I stayed deeper in work problems. I finished features in one session that used to span three. My PR descriptions got clearer because I wasn’t mentally drafting them while also thinking about a side project’s database schema.
The boundary created focus on both sides. Work gets Monday through Friday. Side projects get Saturday and Sunday. Both get my full attention when they have it.
What about the “always shipping” culture?
There’s a narrative in tech that the best engineers are the ones shipping constantly — side projects, open source contributions, blog posts, conference talks, all flowing year-round. It’s a seductive image. It’s also unsustainable for most people.
I tried the always-shipping lifestyle. It worked for about six months, and then it didn’t. The people who sustain it long-term usually have one of three things: a job with low cognitive load, a support system that handles everything outside of code, or a personality wired for constant output. I have none of those.
Weekend side projects aren’t a downgrade from the always-shipping ideal. They’re a sustainable version of it. A pace you can maintain for years instead of months. And in software, where most ambitious projects take years, sustainability is the only thing that matters.
The weekend ritual
Here’s what my side project weekends actually look like:
- Saturday morning, 7-11am: Four hours of deep work. No Slack, no email, no phone. Coffee, music, and one project.
- Saturday afternoon: Life. Errands, friends, the outdoors. The code exists but I don’t touch it.
- Sunday morning, 7-11am: Another four-hour block. This is often where the best work happens — the Saturday session primed the pump, and Sunday delivers.
- Sunday afternoon: Review what I built, write a few notes for next weekend, close the laptop.
That’s eight hours of focused side project work per weekend. Over a month, that’s thirty-two hours — a full work week of deep creative time. Over a year, it’s nearly four hundred hours. That’s enough to build something real.
Is this for everyone?
Probably not the exact schedule. But the principle — give your side projects a container — might be.
Some people thrive on the daily grind across multiple projects. Some people need side projects intertwined with their week to stay creatively satisfied. There’s no single right answer.
But if you’re feeling burned out, if your side projects feel like obligations instead of outlets, if you can’t remember the last weekend you genuinely didn’t code — try the weekend container. Your side projects will still be there on Saturday. And you’ll show up for them with more energy than you would have on a Tuesday night.
I still love building things outside of work. I just love it more now that it has a time and a place — and now that the rest of my week belongs to me.