Working While Living: Three Days of Travel and Planning
November 6–8
On Thursday afternoon, with two P2 issues ready to close, I deployed two agents in parallel. 18 minutes later they were both done. Later that evening, flying to Burbank for my nephew’s play at Occidental College.
Friday, the plan was to work from a Pasadena hotel room, publish Weekly Ship #016, updatee my Chief of Staff on all our work streams. Then go see Neil Simon’s play Rumors that night.
Saturday, I fly home after a nice long breakfast with my brother, my sister-in-law, and his sister-in-law (my sister-in-law-in-law?).
Three days. Family obligations. Travel up and down California. The work happens in the margins: fast execution, administrative tidying, and investigation that saves days of effort.
The verification gate
I’m now fixing bugs I’m finding in my own end-to-end alpha testing:
- Issue #286: Move CONVERSATION handler to canonical section. Architectural cleanup.
- Issue #287: Fix timezone display (PT vs Los Angeles), contradictory messages, calendar validation.
1:51 PM — Code Agent starts #286
1:54 PM — Cursor Agent starts #287
2:00 PM — Cursor completes (6 minutes)
2:03 PM — Code completes (12 minutes)
3:15 PM — Verification gate: Check both changes present
3:37 PM — Verified: No conflicts, both changes correct
3:42 PM — Push: 55/55 tests passing
The verification gate caught a risk. Both agents had edited canonical_handlers.py (a potential conflict). Without checking, we might have pushed conflicts. With the gate: clean merge, zero issues.
Total time: 18 minutes of agent work. Estimated: 4 hours. 12x faster than expected.
Why so fast? Issues were simpler than estimated. Good architecture made changes straightforward. Comprehensive tests validated immediately.
If it’s Thursday this must be Burbank
Flight to Burbank. Nephew’s play at Occidental College the next night. Family time.
Development work doesn’t stop for life. But it adapts. Morning: Fast execution on P2 issues. Evening: On a plane. Different rhythms for different contexts.
The work that happened Thursday morning took 18 minutes because it could. Quick architectural fix. UX polish. Both agents knowing exactly what to do. Then done. Then life.
Back to my old road warrior days
Friday I work out of my Pasadena, looking forward to my Nephew’s play that evening. The work that fits in this hotel time is mostly administrative, not technical. I am excited to see family and can’t concentrate on supervising software development.
Morning work:
- Weekly Ship #016 published (covering Oct 31 — Nov 6)
- Work streams formalized (v2.0: seven categories that were due for updating as the project has entered a new stage)
- Issues #286, #287 documented and closed
- P2 dependency identified: #291 blocked by #262
Work streams evolution: Back in July, the categories focused on foundation-building. Now in November, they track operational status. The shift from “building the system” to “running the system.” Time to formalize that evolution.
Seven streams defined:
- User Testing (alpha expansion)
- System Health (infrastructure, costs)
- Methodology Evolution (patterns, processes)
- Operational Efficiency (performance, automation)
- Documentation (maintenance, onboarding)
- Communications (newsletter, speaking, building in public)
- Strategic Planning (future exploration)
The work streams now reflect reality: Not “what are we building?” but “how is everything running?”
Communications momentum: 699 subscribers. Conference talk accepted for next March. “Finding Our Way” podcast well-received. Building in public creating unexpected opportunities.
Funny moment: Discovered fabricated GitHub username “Codewarrior1988” in Weekly Ship footer. Agents sometimes invent facts confidently. Corrected to actual repo: github.com/mediajunkie/piper-morgan-product/ (all the code is open source, as you probably know already).
The play’s the thing
Friday evening at Occidental College. My nephew’s performance is a tour de force, but the truth is it’s just wonderful to see him, meet his charming friends, and enjoy the company of east-coast family I rarely get to see.
Time away from code.
This is what sustainable development looks like: Morning administrative work. Evening with family. Not coding mania. Not pushing through exhaustion. Just work that fits the day’s shape.
Investigation while traveling
Flying home from LA on Sartuday. Light work only — no implementation. But investigation pays dividends.
Issue #262 (UUID Migration) has been sitting in backlog marked “March 2026” — pre-MVP work. But Issue #291 (Token Blacklist FK) can’t complete without it. The dependency forces #262 earlier.
What’s the actual scope? Let’s investigate.
Database audit:
- users table: VARCHAR primary key
- alpha_users table: UUID primary key
- Seven FK dependencies
- Type inconsistency blocks #291
The question: How hard is this migration really?
Options considered:
- Option A: Quick fix with technical debt (fast but creates future problems)
- Option B: Do it properly (migrate to UUID, consolidate tables)
I choose Option B. But how long will it take?
Investigation begins: Code Agent does comprehensive database audit. Table structures. Foreign keys. Application code. Risks. Rollback procedures.
45 minutes later — Critical discovery: The users table is empty. Zero records.
Wait. Of course it is. We didn’t have a user table for the first five months of this project. There was only ever one user. The main users table we made a week or so ago? Zero records. Never used.
This corrects the false assumptions of the draft plan. Original estimate: 2–3 days. Complex dual-column migration. Data transformation. High risk. With empty table: 10–16 hours. Direct ALTER. No data migration. Low risk.
The archaeological approach again: Investigate before planning. Don’t assume complexity. Check actual state.
The planning work
Saturday evening: Creating the gameplan.
With an empty table, the migration becomes straightforward:
- Phase −1: Verify state (confirm table empty)
- Phase 0: Backups (safety first)
- Phase 1: ALTER table (users.id VARCHAR→UUID, add is_alpha flag)
- Phase 2: Update models (7 models to UUID types)
- Phase 3: Update code (152 type hint files affected)
- Phase 4: Update tests (104 test files affected)
- Phase 5: Integration testing
- Phase Z: Commit and celebrate
Automation identified: Type hints can be scripted. Tests follow patterns. Create tools for batch work.
Issue #291 integration: The Token Blacklist FK naturally resolves as part of #262. Two issues, one implementation. Efficient.
Agent coordination planned: Code Agent implements. Cursor Agent verifies. Both create handoff documents at phase boundaries.
Gameplan complete: 680 lines. Seven phases. Clear acceptance criteria. Ready for execution.
But not tonight. It’s Saturday. I’m traveling home. The work can wait until tomorrow.
The migration ready
Saturday evening: Gameplan complete. Investigation done. Discovery validated.
Empty table means straightforward migration. 16 hours estimated. Two issues resolved together. Automation tools identified.
Sunday: Agent deployment. But that’s another story.
For now: Three days of travel. Family time. Administrative work. Investigation that saved days. Planning that enables execution.
Not coding mania. Just sustainable development. Work that respects both project needs and human life.
