What I Learned from Working 32 Hours a Week

In early November, I helped run the Weekend For Good event as part of the Code For Good West Michigan admin team. The event brought together 120+ volunteers and 14 local nonprofits to help build, rebrand, or update websites. It was scheduled for three straight days, and I was there for all of it.

It’s safe to say I needed a break after working my normal weekly schedule along with the extra hours I put in over the weekend. This made November 5 an important day—and not because it was Guy Fawkes Day, but because it was the first time I had used any of my allotted vacation time.

I had spent the rest of the year working ~43 hours/week—often arriving at the office at seven in the morning. With so many vacation days left, I needed to figure out how to use that time. Instead of taking an entire month off at once, I decided to spread out my time off to see what a four-day work week would feel like.

I knew it was going to be different than what I was used to, but I wanted to understand the benefits/trade-offs of this type of schedule. These are some of the things I observed during my 32-hour-work-week journey.

More Personal Time

This might be an obvious benefit, but the less time you spend at work, the more you have for personal matters. Maintaining a good work/life balance is important, and this new schedule was exactly what I needed to help achieve that balance.

I understand that other people might not have as much of an issue juggling a full-time job, volunteering, and a personal life. This was not the case for me—at least for the long-term.

I found that my new schedule allowed me to spend more time with friends/family, complete some much-needed errands, and catch up on housework. The four-day work week schedule reminded me of the importance of my personal time, and I’m grateful for that.

Improved Focus at Work

As I mentioned before, I kept a pretty consistent work schedule—arriving at seven a.m. and leaving by five p.m. each day. During this block of time, I would concern myself with work-related matters, and then I would go home.

I fell into the trap of trying to stick to a strict schedule instead of focusing on the tasks that I needed to complete. As Cal Newport says in his book Deep Work:

Your goal is not to stick to a given schedule at all costs; it’s instead to maintain, at all times, a thoughtful say in what you’re doing with your time going forward.

With a four-day work week schedule, I felt the need to develop a plan for each day that I was going to be in the office. My time at work had a new purpose that centered around improving the value I was delivering to my project and my team. Being aware of the value you deliver with your time is important, especially at a consultancy where we invoice clients based on our time.

Increased Awareness of Team Needs

We do a lot of pair-programming here at Atomic, which means we are not working on tasks in isolation. Working with others can be difficult. It requires communication from all sides to make sure everyone can make meaningful contributions.

As software developers, we have many techniques to help us communicate with our team, even when we’re not in the same room as the person we’re pairing with. These include:

  • Writing clear, focused commit messages
  • Writing explicit test cases
  • Breaking stories into small tasks

With a shorter schedule than the rest of my team, I realized the importance of these communication techniques. If someone needed to pick up where I left off, I wanted to make it easy for them to know where to begin. Creating smaller, incremental commits was a great first step and something I intend to practice more often.

More Time to Reflect

My traditional schedule hadn’t offered much time to reflect on the status of a project. The types of questions that needed more than an afternoon of thought never got answered unless they were prioritized in the backlog. The high-level vision of the project, the major architectural refactors, and the opportunities for team members to grow tend to get lost when you’re always busy completing one task at a time.

I’m not the type of person who can stop thinking about something just because I’m on vacation that day. My days off were some of the best times to reflect on the project as a whole and figure out where to achieve the most value—for the client, for my team, and for myself.

I often tend to think about the improvements that could be made to the project infrastructure and developer ergonomics.

  • How could we improve the continuous deployment pipeline?
  • How could we improve build times so the test runs are faster?
  • What settings could we adjust in our editors to catch these common errors faster?

These questions have led to some interesting learning opportunities about the projects I work on and the tools we use for those projects. This is information that I can pass on to my team and take to other teams when I leave this one.


I enjoyed my four-day work week experience, and I wish that it could continue in the future. This experiment was valuable, teaching me a lot about myself and how I work with others.

Have you ever had the chance to try a four-day work week? I’m curious to know other people’s experiences with this type of schedule and whether or not you thought it was beneficial.