An 857-Line Honesty Machine
Probe with a script before you productize
While I was mapping a launch in Planning, staff meetings still debated throughput with no shared definition of "merged." Sprint reviews ran on anecdotes. I needed one honest answer: who shipped what, when - without buying a platform or surveilling individuals.
On 2026-04-10, commit d52975b added github_pr_timeline_report.py - 857 lines in one file. That script became github-analysis. This is the origin story, not the June refactor.
Here's what this piece covers: the staffing question, what the script measured, what it got wrong (foreshadowing the metrics marathon), and three lead habits.
Part of Field Notes: agentic delivery.
1. The leadership problem
Managers ask "who's blocked?" and "are we shipping?" GitHub holds lagging truth - but exporting it into a staff-meeting spreadsheet without column definitions is how trust dies.
The anti-pattern is the mystery spreadsheet - everyone runs different flags; Excel becomes truth without a catalog.
Wrong: "We built analytics."
Right: "An 857-line script on Apr 10 (d52975b) let me answer one question: per-person PR activity in a date window - before we knew which columns were wrong."
2. What the git history shows
Commit d52975b - Add PR timeline report tool; ignore analysis-results; remove handoff doc - landed 2026-04-10 19:45 Eastern:
github_pr_timeline_report.py 857 lines
README.md operational doc from day one
.gitignore analysis-results/ never committedBuilt with Cursor - early agent-assisted tooling on my machine, not a platform mandate. Output went to TSV for Excel because managers already lived in spreadsheets.
The probe question, in spirit:
from datetime import datetime
def merged_in_window(prs, start: datetime, end: datetime):
"""Keep PRs whose merge timestamp falls in [start, end)."""
return [
pr for pr in prs
if pr.get("merged_at")
and start <= datetime.fromisoformat(pr["merged_at"]) < end
]Half-open windows matter. Vague "in April" does not.
3. What I built
The script answered a probe question, not a product vision:
| Input | Output |
|---|---|
| Repo, date window, author filters | Per-PR rows with open/merge/review timestamps |
| Same window | Person-level rollups for staffing conversations |
README documented flags and output paths from commit zero. That mattered later when three managers ran incompatible copies from Slack.
Limitations I knew on day one - and fixed in June:
- Column semantics loosely defined (article 09 - three wrong metrics same morning)
- Monolith structure - hard to test, hard to extend
- No version pin - "works on my laptop" is not team infrastructure
The named pattern:
Probe with a script - cheap instrument before you productize metrics; one question answered honestly.
4. What broke / what I would not repeat
Monolith scripts rot - but shipping a script beat waiting for perfect architecture. The failure mode is waiting so long that Slack forks multiply.
When the second team asked for the report, I should have named an owner and a version pin immediately. I waited until 2026-06-01 and commit 9d47215 - your Slack script just shipped.
Bad numbers erode trust faster than no numbers. Even this probe needed definitional discipline before any staff meeting.
5. What I'd do as a lead
- Start with one honest report before buying a metrics platform. Name the single question it answers.
- Never present numbers you cannot define in one sentence per column. If you cannot, you are not ready for the meeting.
- Plan for refactor when two teams depend on the same script. The product threshold arrives faster than you think.
Further reading
- Your Slack script just shipped -
9d47215· 2026-06-01 - Field notes: agentic delivery - github-analysis in the three-repo thesis
- github-analysis anchor: commit
d52975b· 2026-04-10
