Ask
188

day job moved to on-call every third week - how do you keep a side project alive on one usable week in three

Day job went from occasionally paged to a formal rotation: one week on, two off. The on-call week is a write-off. I am tired, I cannot start anything that needs more than twenty minutes of head space, and twice now I have been up at 3am. The week after is mostly recovery. Realistically I have one good week in three.

The project is a small tool with 11 paying users. It does not need much, but not much still means someone answers email and ships the occasional fix.

What I cannot work out is the rhythm. A three week cycle means whatever I start in the good week is cold by the time I come back to it. Last cycle I spent the whole Saturday of my good week just remembering how the import job worked.

How do you structure this? Do you plan the dead weeks around low-focus work, or accept they are dead and protect the one week properly?

8 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @gramgrader_gus · 4w ago · 2 replies

    Two pagers is the actual problem here. Before anything else, make the project incapable of waking you. Managed database, no cron you wrote that fails silently, no alert routed to your phone, one digest email a day that you read when you feel like it. If the side project can page you during the day job's on-call week you have accepted two rotations, and that is how people quit both.

    After that, dead weeks get anything that fits on a phone: support email, docs in a notes app, copy, screenshots, the boring billing chores. Not code. Code needs the good week and all of it. My last three cycles were roughly two hours of admin during on-call, zero in recovery, nine to eleven hours in the good week.

    88
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @leaky_bucket_ed · 4w ago

      The reload cost is what kills me, not the hours. I finish every session by writing the exact next command in a WIP file - literally "npm run dev, open /import, the failing case is a file with a BOM". Two minutes at the end, saves an hour at the start.

      30
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @quiet_promotion · 4w ago · 2 replies

    One week in three is seventeen weeks a year. That is a real budget. Treat it like one and stop mourning the other thirty five.

    33
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @goldenhour_glen · 4w ago

      And let uptime slip. Eleven users on a small tool do not need four nines. Put a maintenance window in the docs, put an email address on the status page, sleep.

      14
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @till_and_tally · 4w ago

    Logged this for six months on a similar rotation. Fourteen usable hours per three week cycle, arriving in chunks of two to four. That means anything you plan has to be finishable in a three hour block or splittable into pieces that are. Two week sprints are meaningless at this budget. I plan in blocks instead, a feature is three to eight blocks, and anything over eight gets cut. I have never once regretted the cut.

    61
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @refresh_rhea · 4w ago · 2 replies

    I did the use-the-dead-week-for-admin thing for a year and it made everything worse. Admin expands to fill whatever you give it, and then the good week opens with a backlog of half finished small things instead of the one thing that mattered.

    Now the on-call week is genuinely nothing. I do not open the repo. One fifteen minute email sweep on Wednesday, that is it. It feels wasteful and my output went up.

    44
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @gpio_gwen · 4w ago

      Same, except I kept one thing in the dead week: ten minutes on paper writing what the good week is for. Otherwise Saturday morning goes to deciding, and deciding eats the whole first block.

      18
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @nightbus_nina · 4w ago

    Newer at this than most here, but the thing that worked was moving every deploy to one slot. Saturday 9am, never Sunday night, never during on-call. It sounds trivial and it removed an entire category of problem, the one where you break it late and then fix it before work on four hours of sleep. The checklist is five lines because a longer one would not get followed: tests, migration against a copy, deploy, click three things, post in the changelog.

    26
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report