Calendars as Source Code

The calendar as codebase

Think of your calendar as a program that runs every week:

• Events are functions. Each one takes time as input and produces outcomes as output.
• Recurring meetings are loops. They run whether or not they're still needed.
• Back-to-back meetings are synchronous blocking calls. No room for error handling.
• Empty space is buffer. It absorbs unexpected load and prevents cascading failures.

Most calendars are legacy codebases: accumulated cruft, cargo-culted patterns, no one quite sure why half the meetings exist. We'd never ship code in this state. Why do we ship weeks like this?

Code review for calendars

Every Sunday evening, I review my calendar for the coming week the way I'd review a pull request:

1. Purpose check: What is this meeting supposed to produce? If I can't answer in one sentence, it probably shouldn't exist.
2. Attendee audit: Does everyone here need to be here? Am I a required reviewer or just CC'd?
3. Duration test: Could this be shorter? Most 60-minute meetings can be 30. Most 30-minute meetings can be 15 or async.
4. Placement review: Is this scheduled at a time that makes sense? Deep work meetings in the morning, administrative meetings in the afternoon.
5. Buffer check: Do I have space between meetings to context-switch, take notes, or handle the unexpected?

I decline or shorten at least two meetings most weeks. Not rudely - just with a note: "I don't think I'm needed for this one" or "Can we try this in 25 minutes instead of 50?"

Design patterns for calendars

The maker/manager split

Paul Graham's classic essay describes two modes: maker time (long uninterrupted blocks for creation) and manager time (hourly slots for coordination). Most calendars mash these together randomly.

I designate specific days as maker days (minimal meetings) and manager days (meetings clustered together). It's not always possible, but even partial separation helps.

Office hours instead of open door

Instead of being available anytime, I publish office hours: two blocks per week when anyone can book time with me. This respects both my time and theirs. Questions that can wait, wait. Urgent issues still come through immediately.

Speedy meetings by default

Google Calendar has a setting for "speedy meetings" - 25 minutes instead of 30, 50 instead of 60. The five minutes back compound. More importantly, it creates a forcing function: you have to actually end on time.

Recurring meeting reviews

Every quarter, I audit recurring meetings. For each one: Is this still necessary? Should the attendee list change? Could the frequency decrease? Recurring meetings are like subscriptions - they quietly accumulate until they consume everything.

Anti-patterns to avoid

The meeting as function

Good functions have clear inputs, outputs, and single responsibilities. Good meetings do too:

interface Meeting {
  purpose: string;        // One sentence max
  inputs: Preparation[];  // What attendees should bring
  outputs: Decision | Action[] | SharedContext;
  duration: Minutes;      // Shortest possible
  attendees: Person[];    // Minimum viable set
}

If you can't fill in this interface for a meeting, the meeting isn't ready to be scheduled. This isn't bureaucracy - it's the same discipline we apply to writing clear code.

Protecting the schedule

The hardest part isn't designing a good calendar. It's defending it. Other people will constantly try to write to your codebase.

• Block deep work time first. If you don't schedule it, it won't happen.
• Set working hours. Make your availability explicit, not infinite.
• Practice declining. "I can't make this work" is a complete sentence.
• Propose alternatives. "I can't attend but here's my input async" is often enough.

You're not being difficult. You're being a responsible maintainer of a critical system.

The meta-lesson

The real insight isn't about calendars. It's about intentionality. Most of us let our weeks happen to us. We accept defaults. We inherit patterns. We wonder why we're exhausted.

Engineers know that good systems don't emerge by accident. They're designed, reviewed, iterated, and maintained. Your week is a system too. Treat it like one.

Try this week

1. Open your calendar for next week
2. For each meeting, write down its purpose in one sentence
3. Identify two meetings you can decline, shorten, or make async
4. Block two hours for deep work before anyone else can claim them
5. At the end of the week, retro: did the changes help?

Small changes compound. A calendar that serves you instead of depleting you is worth the investment.