My calendar is a mess. Back-to-back meetings on Tuesdays. Kid's soccer practice three evenings a week. By the time I sit down to actually write code, I've got maybe 45 minutes before the next thing.

For years I told myself this wasn't enough time to do "real work." I'd scroll Twitter, check email, tell myself I'd code properly on the weekend when I had a clear block of time. The weekend would come and something else would fill it.

Eventually I realized I was waiting for conditions that weren't coming. The 4-hour uninterrupted block is a fantasy for most people with jobs and lives. So I learned to work with what I have.

The Problem Is Task Size

You can't tackle "Implement user authentication" in 30 minutes. The cognitive load of even remembering where you left off takes half that time. By the time you've loaded the context into your brain, your next meeting starts.

The trick is making tasks small enough that you can complete them between interruptions. Really small. Uncomfortably small.

"Implement auth" becomes a bunch of tiny pieces: create the users table migration, write a function to hash passwords, add the login route (without the actual logic), write the login template, add form validation, connect the pieces. Each one takes 10-20 minutes. Each one is a complete thought.

When I have 25 minutes, I pick a piece that fits. I finish it. I feel progress. If I get interrupted halfway through a piece, at least it's a small piece - easy to pick back up.

Write Everything Down

The biggest cost of fragmented time isn't the switching itself. It's the "where was I?" tax you pay every time you come back.

I keep a scratchpad file open in every project. Before I walk away from the keyboard, I dump whatever's in my head: 

# scratch.md - June 22 2:30pm

Working on the CORS issue. It's not the headers - I checked those.
Pretty sure it's the preflight request failing.
Next: check if nginx is stripping the OPTIONS response.
Relevant config is in /etc/nginx/sites-enabled/api

Takes 30 seconds to write. Saves 15 minutes of "what was I doing?" when I come back. Past me is doing future me a huge favor.

If I'm in the middle of code, I leave a comment: 

// NEXT: I just fetched the user data. Need to filter inactive 
// users and map to the component format. See User.formatForUI()

When I return, I don't have to figure out what to do. The code tells me.

Speed Up the Start

If you only have 30 minutes, you can't afford to spend 5 of them starting the dev environment. My project setup is one command: 

// package.json
{
  "scripts": {
    "dev": "concurrently \"docker-compose up\" \"npm run server\" \"npm run client\""
  }
}

Database, backend, frontend, all running. No manual steps. I type `npm run dev`, wait 20 seconds, and I'm coding.

If your setup requires 7 terminal tabs and a specific sequence of commands, script it. Every minute of setup is a minute not coding, and when time is scarce, those minutes matter.

Time-boxing Rabbit Holes

Here's how I used to lose entire afternoons: I'd start fixing a bug. I'd notice the code around it was messy. I'd start refactoring. I'd notice an outdated dependency. I'd start updating. Suddenly it's 6pm and I haven't actually fixed the original bug.

This is called yak shaving and it's the enemy of limited time.

Now I set explicit timers. "I will spend 20 minutes on this bug. If I haven't found the root cause by then, I'll either ask someone or move on." When the timer goes off, I actually stop. Whatever cleanup I noticed goes in a TODO comment for later. 

// TODO: This whole function should be refactored, but
// leaving it for now to fix the immediate issue
function handlePayment(data) {
  // ... messy but working code
}

Perfect is the enemy of done, especially when you've got 25 minutes.

Using Dead Time

Not all thinking requires a keyboard. Some of my best problem-solving happens in the shower or during my commute. I'll be stuck on something, step away, and the solution shows up while I'm loading the dishwasher.

I've started treating this as legitimate work time. When I know I have a tricky problem coming up, I'll read through the code in the morning and let it stew. By the time I sit down to actually code, I often already know what to do.

This only works if you're intentional about it. "Think about the caching issue during lunch" is different from "stare at phone during lunch." Same time, different outcomes.

Knowing What to Skip

When time is tight, you have to be ruthless about what matters. Not every code style violation needs fixing. Not every edge case needs handling right now. Not every test needs to be written this session.

I ask myself: "What's the one thing that, if I do it, makes the rest easier?" Usually there's a clear answer. Do that thing. Leave the rest for later.

This feels wrong if you're a perfectionist. It felt wrong to me for years. But shipping something imperfect that works beats shipping nothing while waiting for perfect conditions.

The Compound Effect

20 minutes isn't much. But 20 minutes, five times a week, for a year? That's about 85 hours of coding. That's a substantial side project. That's learning a new framework well. That's meaningful progress.

Most of my open source contributions happened in fragments like this. Most of my learning happens this way too. It doesn't feel like much in the moment, but it stacks up.

The developers who seem impossibly productive usually aren't working more hours. They're just better at using the hours they have.

Start with the time you've got. It's more than you think.

Back to Developer Productivity

Back to Home