Designs by Duhart← All work
Rank
27 of 28
Tier
Tier C 39 of 120

12 — Technical Documentation Corpus

Rank 27 of 28 · Tier C · docs/ Format: Markdown with mermaid diagrams, typeset to PDF/DOCX

Why this ranks here. On its own it does not get you hired. Attached to the systems above, it is what converts "I worked on that" into "I can defend that." Google's promotion process and every bank's change-control process run on documents like these. Do not lead with it — but bring it.

Three book-length manuals

docs/webrtc-chat/ — 20 chapters

Executive summary → architecture → protocol spec → Go backend → call lifecycle → media plane → ICE/STUN/TURN → iOS → web → edge → Cassandra → Kafka/Redis → security → observability → deployment/runbook → gap register → remediation roadmap → onboarding → appendices → task list. Also typeset: TheOne-WebRTC-Chat-Engineering-Manual.pdf / .docx, plus a diagram bundle.

docs/billboard/ — 17 chapters

The same spine applied to the music mode, and it contains the artifact worth showing: 14-SPOTIFY-PARITY.md, a feature-by-feature comparison scoring the system at 14 of 52 against Spotify. A candidate applying to Spotify who has already written an honest parity gap analysis of their own product against Spotify's is having a different conversation than everyone else in the pipeline.

Plus 10-API-CONTRACT-DIFF.md (client expectation vs server reality, line by line), 13-GAP-REGISTER.md, and a session-record directory tracking decisions, blockers, inferences, and a deploy queue.

docs/dating/ — audit + remediation

Technical report, WebRTC report, remediation plan, performance analysis, and integration plans. Headline findings: dual match backends, a three-way identity split, three chat table families, dead iOS swipe paths, and credentials committed to a repository — each named rather than smoothed over.

The recurring structure

Every manual follows the same discipline:

  1. State the scope and the date. ("as of 2026-08-25")
  2. One diagram of the whole system, with dead components marked dead.
  3. Component inventory — path, runtime, status.
  4. Every hostname the client dials, traced to the line that dials it.
  5. Gap register — numbered, severity-ranked.
  6. Remediation roadmap — what to fix, in what order.
  7. Task list — the roadmap made executable.

Why this matters for the target role

The rarest thing in a systems interview is a candidate who says "here is what is broken in the thing I built, ranked, with the cost of each fix." These documents are that, three times over, written before anyone asked for them.

Files like docs/billboard/session/BLOCKED.md and INFERRED.md — separating what was verified from what was assumed — are the same instinct that makes a good incident report.