▸~/how-i-think
Debug my brain.
SCENARIO 01
The gallery that never loads
A 3D gallery works perfectly on your laptop. On some phones it never finishes loading — no error, it just sits there.
WHAT WOULD YOU DO?
WHAT ACTUALLY HAPPENED
- Devices without native WebXR load a polyfill. When Unity finished booting before the WebXR manager attached, its Ready event was fired into the void.
- The fix parks the event and replays it when the manager arrives — so the order no longer matters.
- Applied with a guarded script across seven builds: exact-match checks, a syntax gate, backups and a read-back comparison.
SCENARIO 02
The blog Google can’t see
The blog looks great in every browser. Months later, none of the posts show up in search.
WHAT WOULD YOU DO?
WHAT ACTUALLY HAPPENED
- Crawled every route’s pre-JavaScript HTML and sorted pages into three buckets: rendered, fallback and empty.
- Found every content page declaring the homepage as its canonical URL — explicitly telling Google the blog was duplicate content.
- Traced four of six findings to one cause — no per-route rendering — so the fix is one architectural change, not four patches.
SCENARIO 03
The app that gets slower every week
A production application becomes slow. Users are noticing. What do you do first?
WHAT WOULD YOU DO?
WHAT ACTUALLY HAPPENED
- At Henceforth Solutions, performance came from SQL optimisation, Redis caching and CloudWatch monitoring — maintaining approximately 99.5% uptime.
- Order matters: instrument, find the slowest path, fix the query or add the cache, then measure again.VERIFY — Unverified — only in: Drafted copy — confirm voice
SCENARIO 04
“Submitted ✓” — but it wasn’t
Your browser automation reports that a job application was submitted. It wasn’t. Half the fields are empty.
WHAT WOULD YOU DO?
WHAT ACTUALLY HAPPENED
- Every interaction goes through one engine that fills, reads back and retries with a different strategy if the read-back disagrees.
- A submission is only recorded with positive evidence — a confirmation sentence or number.
- The e2e suite fails any run that returns 200 without filling anything.
SCENARIO 05
The chatbot that makes things up
You put an AI assistant on your portfolio. A recruiter asks it something your portfolio doesn’t cover.
WHAT WOULD YOU DO?
WHAT ACTUALLY HAPPENED
- Ask Prince retrieves from a knowledge base built only from verified facts; unverified claims are excluded by type, and a test enforces it.
- If the best match is too weak, the API returns “I don’t have enough information in Prince’s portfolio to answer that.” without calling the LLM.
- Every answer carries links to the evidence it came from.
02THE BUILD PIPELINE
Input → ship.
How an idea becomes a system — each step tied to the place it actually happened.
INPUT
A request, a bug report, a half-formed idea. Before any code: write down what “done” looks like.
UNDERSTAND
Look at what the system actually does, not what it’s supposed to. For the SEO audit that meant reading the HTML a crawler receives, not the page a person sees.
BREAK DOWN
Split the problem until each part can fail on its own. The Job Agent is an observer, an interaction engine and a navigator — each testable alone.
EVIDENCE
DESIGN
Pick the simplest architecture that survives the known failure modes — and decide where a human stays in the loop.
EXPERIMENT
Build the smallest thing that answers the riskiest question. Sometimes that’s a prototype; sometimes it’s the adversary.
ENGINEER
Make the code prove itself: exact-match guards, syntax gates, idempotency, backups.
TEST
Test each stage, not just the status code. A run that returns 200 without doing the work is a failure.
ITERATE
Measure, fix the biggest bottleneck, measure again. Repeat until the numbers stop moving.
SHIP
Ship with a way back: backups, re-runnable scripts, state that survives a restart.