Why I Prefer Stable Hours Over 'Get Your Work Done' in Software Dev

I like stable, predictable work hours.

Graph showing a flat green line representing consistent daily work hours - what I prefer

I learned that when you try to hook your self-worth to “commitments” or “getting your work done” in an environment like software development where work is so difficult to estimate your schedule can quickly become chaos.

Graph showing a wavy red line with peaks and valleys representing unpredictable daily work hours - what I want to avoid

How I got stuck…

I started out treating software development like the work I had laid out for me when I worked at Staples (the office supply store). I would tell people how long it would take a thing to get done and then I inevitably ended up overworking when estimates missed, and… they tended to almost always miss.

“Finish” early (rare, but it happens)? I sneak out early or coast because I earned it after all those 60-hour weeks, right? It feels like justified compensation.

We’re All Terrible at Estimating Software

We’re awful at it. I highly recommend reading Software Estimation: Demystifying The Black Art by Steve McConnell where he goes to great lengths to prove to his readers exactly how bad we are. He of course then proceeeds to give you useful techniques on how you can get better… but still… the problem remains.

We tend to either overestimate or underestimate and by a large margin. The more common of the two is unfortunately underestimating the size which means you’ll more commonly (if you’re like the rest of us humans) be working overtime rather than getting out early.

Moving Into Leadership

Moving into a leadership role, my perspective on this was solidified. It made no sense to me if someone got the short end of the stick on something they thought was easy but turned out to be hard to make them work overtime hours. Much better to say “No problem” and let them call it a day. It also made no sense to watch someone run off and have fun for hours just because they lucked out and got an easy one (although… underestimation being way more common… this is super rare).

A Better Approach: Stable Hours, Improving Flow

So what do I do now?

I stick to my hours… sometimes this means I get extra stuff done because I finished earlier than I thought I would… sometimes this means I miss on commitments.

I ask my team to stick to their hours… don’t overwork yourself. Don’t cut out on the rest of your team. Just go stable.

Every time, though, it means my hours are stable and predictable.

The Benefits

  • Stability - Being able to tell my family when I’ll actually be home. Not carrying around guilt that “I didn’t finish the thing I promised, so I must not be good at my job.”
  • Failure - Failure isn’t always bad… it’s an opportunity to learn and improve. When I or my team fail to meet commitments within a reasonable timeframe we can talk about what went wrong and what we can do better next time. Overworking to hit a deadline short-circuited that value for me for a long time.

Side Note: I still work crazy hours sometimes… but… that’s a different problem 😝

Common Questions

  • How many hours? - That’s up to your team… whatever you collectively agree makes the most sense for you guys to be productive.
  • Do you really follow this strictly? - Not really… it’s more of a target than a strict rule. Sometimes you have to pull overtime. Sometimes you should get out early. Those tend to be great team conversations though and shouldn’t be left up to the individual to put on themselves.

Read More

Approvals Are a Security Wet Blanket for AI Agents Reading time ~3 minutes

I was running an AI agent in a remote VM,......

Do Newer Models Hold Up as Context Fills? Reading time ~20 minutes

My experience has always been that AI models get pretty......

Sharing Skills: Claude Marketplace to VS Code Workspaces Reading time ~4 minutes

Part 3 of 3 in the Skills Catalog series (Part......