Scrolls
5 min read
On this page

Not All Hours Are Equal

The idea that an hour of work is an hour of work is a factory-era assumption that does not apply to knowledge work. A developer at 9am after a good night's sleep, working on a hard problem with no interruptions, produces more in one hour than the same developer at 3pm after a contentious meeting, skimming through emails between Slack notifications.

You have maybe 4-5 hours of peak cognitive work per day. That is not a personal failing. It is a biological reality backed by decades of research on sustained attention and cognitive fatigue. The question is not how to get more peak hours (you cannot). The question is how to use the ones you have on the work that matters most.

Peak Hours Are for Hard Problems

Hard problems require deep, sustained attention. Architecture decisions. Complex bug investigations. Algorithm design. Writing technical specifications. These tasks demand your full cognitive capacity, and they suffer disproportionately when attempted with a tired or distracted mind.

Peak-hour work (high cognitive load):
- System design and architecture decisions
- Debugging complex, cross-system issues
- Writing new code for unfamiliar domains
- Performance optimization and profiling
- Reading and understanding new codebases
- Writing RFCs and technical proposals
- Learning new concepts or technologies

Low-energy work (low cognitive load):
- Code reviews (routine ones, not complex)
- Responding to Slack messages and email
- Updating tickets and project management tools
- Attending informational meetings
- Writing status updates
- Routine deployments
- Administrative tasks (expense reports, scheduling)

The distinction is not about importance. Code reviews are important. Status updates are important. But they do not require the same quality of attention as designing a new distributed system. You can do a competent code review at 80% capacity. You cannot design a reliable distributed system at 80% capacity.

The Cost of Misallocating Peak Hours

When you spend your peak hours on email and meetings, the hard work gets pushed to your low-energy hours. But hard work done with low energy is not just slower -- it is worse. Designs have more flaws. Bugs are introduced instead of found. Decisions are made with less rigor.

Scenario A (peak hours on hard work):
9:00 - 12:00   Architecture work (peak energy, deep focus)
12:00 - 1:00   Lunch
1:00 - 2:00    Code reviews and PR feedback
2:00 - 3:00    Team standup + Slack catch-up
3:00 - 4:30    Implementation work (moderate energy)
4:30 - 5:00    Email and admin

Scenario B (peak hours wasted):
9:00 - 9:30    Check email and Slack
9:30 - 10:00   Standup meeting
10:00 - 10:30  Respond to Slack threads
10:30 - 11:30  All-hands meeting
11:30 - 12:00  More Slack
12:00 - 1:00   Lunch
1:00 - 5:00    Try to do architecture work (low energy, fragmented)

Scenario B is more common. And the developer in Scenario B will tell you they "did not have time for deep work" when in reality they had the same 8 hours. They just spent their best hours on their least demanding tasks.

Protecting Peak Hours

Knowing your peak hours is useless if you do not protect them. Protection means saying no to things that would consume those hours. This is not about being difficult -- it is about being intentional.

Strategies for protecting peak hours:

1. Block your calendar.
   Put a recurring "focus time" block on your calendar during your
   peak hours. Decline meetings that conflict. Most people will not
   schedule over a blocked calendar.

2. Batch meetings.
   If you have 3 meetings in a day, do not scatter them across the day.
   Stack them back-to-back in your low-energy afternoon. One 3-hour
   block of meetings is better than 3 meetings that fragment the
   entire day.

3. Delay Slack.
   Do not open Slack until after your peak work block. Set a status:
   "Focused until noon, will respond after." Most messages are not
   urgent enough to warrant interrupting deep work.

4. Handle email twice a day.
   Check email at the start and end of the day. Not during peak hours.
   If something is truly urgent, someone will find a way to reach you
   that is not email.

5. Say no to morning standups (if you peak in the morning).
   A 9:30am standup breaks a potential 3-hour morning focus block into
   two useless fragments. Push it to afternoon or make it async.

The Meeting Fragmentation Problem

A single 30-minute meeting in the middle of your peak hours does not cost you 30 minutes. It costs you the entire surrounding block. A meeting at 10:30 means you cannot start deep work at 9:00 (because you know you will be interrupted in 90 minutes) and you cannot start deep work at 11:00 (because you only have an hour before lunch).

Calendar with one poorly placed meeting:

9:00 |              | Too short for deep work (90 min, but you'll
     |  "Available" | spend 15 min warming up and 15 min winding
10:00|              | down, leaving only 60 min of actual focus)
     |              |
10:30|-- Meeting ---|  30 minutes
11:00|              |
     |  "Available" | Too short for deep work (60 min)
12:00|-- Lunch -----|

That "available" time is technically free but practically unusable for anything requiring sustained thought. The meeting cost is not 30 minutes -- it is the entire morning.

The fix: batch meetings together, and batch them outside peak hours.

Better calendar:

9:00 |              |
     |  Deep work   | Full 3-hour block, no interruptions
10:00|              |
     |              |
11:00|              |
     |              |
12:00|-- Lunch -----|
1:00 |-- Meeting 1--| Meetings batched in afternoon
1:30 |-- Meeting 2--|
2:00 |-- Meeting 3--|
2:30 |              |
     | Low-energy   | Reviews, Slack, admin
4:00 |   work       |

Low-Energy Hours Are Still Productive

This is not about slacking off in the afternoon. Low-energy hours are productive hours -- they are just productive for different things. Code reviews, responding to messages, updating documentation, reviewing pull requests, attending informational meetings, and doing administrative work are all valuable. They just do not require the same intensity as hard problem-solving.

Matching energy to task type:

High energy:     Create (new code, designs, proposals)
Medium energy:   Edit (code reviews, refactoring, bug fixes)
Low energy:      Process (email, admin, routine tasks)

The developer who does code reviews in the afternoon is not being lazy. They are being strategic. The review will be just as thorough at 3pm as at 9am -- it is a structured, reactive task that follows a known pattern. The architecture decision will not be as thorough at 3pm. It requires creative thinking, which is a peak-energy activity.

Tracking Your Energy

Most developers have an intuitive sense of when they work best, but intuition is often wrong. Track your energy for one week to get actual data.

Simple energy tracking:

Every 2 hours, rate your energy and focus from 1-5:

  Mon  9am: 4  11am: 5  1pm: 3  3pm: 2  5pm: 2
  Tue  9am: 3  11am: 5  1pm: 4  3pm: 2  5pm: 1
  Wed  9am: 5  11am: 4  1pm: 3  3pm: 3  5pm: 2
  Thu  9am: 4  11am: 5  1pm: 3  3pm: 2  5pm: 1
  Fri  9am: 3  11am: 4  1pm: 3  3pm: 2  5pm: 1

Pattern: peak is 9am-noon. Significant drop after 2pm.
Plan: deep work 9-12, meetings 1-3, admin 3-5.

One week of tracking is enough to see the pattern. You do not need to track forever. You need to track once, identify your pattern, and design your schedule around it.

Common Pitfalls

  • Treating all hours as equal. Scheduling a brainstorming session at 4pm because "that is when the room was available" is wasting everyone's peak hours elsewhere and using everyone's worst hours for creative work.
  • Filling peak hours with "quick" tasks. "I'll just answer a few Slacks before starting the design doc" is how peak hours disappear. Quick tasks expand to fill the time you give them.
  • Guilt about low-energy work. Doing email and reviews in the afternoon is not slacking. It is strategic allocation. The guilt comes from a culture that values visible busyness over actual output.
  • Ignoring energy for scheduling. Most calendar tools treat all time slots as equal. You need to manually protect your peak hours because the calendar will not do it for you.
  • Assuming your energy pattern matches others. Your peak might be 9am. Your teammate's peak might be 10pm. Do not project your rhythm onto others or judge their schedules.
  • Skipping breaks. Working through lunch or skipping a walk to "push through" depletes your afternoon energy even further. Short breaks maintain energy levels.

Key Takeaways

  • You have 4-5 hours of peak cognitive work per day. Use them for hard problems: architecture, complex debugging, design decisions, new code.
  • Low-energy hours are still productive -- use them for code reviews, email, meetings, and admin. These tasks do not require peak focus.
  • A single meeting in the middle of a focus block destroys the entire block, not just the 30 minutes it occupies. Batch meetings together, outside peak hours.
  • Block your calendar during peak hours. Delay Slack and email until afterward. Most things are not urgent.
  • Track your energy for one week to identify your actual pattern. Then design your schedule around it.
  • The goal is not more hours of work. It is the right work in the right hours.