My Engineering Operating Manual - Patterns, Rituals, and Receipts

These practices work for me today and will evolve. A lot of this came from seniors who let me shadow their thinking, handed me better questions, and saved me from clever mistakes.

This post isn’t my stack (that’s already written). It’s the stuff I reach for every week: patterns, tiny rituals, and templates you can borrow, and that I’ll keep refining as I grow.

If you want wiring and app lists, read these and come back:

• I Made My Homelab Talk to Me Using Claude and FastMCP

• My Self-Hosting Stack: Everything I Run, and How It All Connects

• The Real Story of Self-Hosting: Why I Love It (and Sometimes Hate It)

---

The line that stuck

“Tony Stark built this in a cave with a box of scraps.”

It’s the person, not the tools. That’s been my lens since school, not top-3 in marks, but the kid teachers called for the weird projects. My first end-to-end build was an Arduino ambient light for my monitor (first GitHub repo a bit over 5 years since then, still runs unchanged). Make it once; make it last.

---

Operating manual (vows, not vibes)

• Receipt-driven automation. Every action leaves a trail (timestamp, actor, inputs, outcome). If it ran, I can prove it.

• Reversible by design. Feature flags, dry runs, versioned configs, parametric parts. No one-way doors.

• Observability before cleverness. A plain counter with a timestamp beats a fancy graph I don’t trust.

• Guardrails over heroics. Checklists and preflight beat “ninja fixes” in prod. Learned the hard way.

• Dynamic by default. Parameters > literals. Today’s edge case is tomorrow’s requirement.

• Backups that restore. Untested backups are fiction.

• Future-me is a teammate. If I can’t finish now, I leave a clean path for him.

Note: I’m documenting what’s working now. If a senior shows me a safer/faster path, I’ll adopt it and update my practice.

---

The 45-minute debug ritual

Goal: get from symptom → measured cause or a clean rollback.

1. Reproduce (≤10 min). Smallest input that fails. Write it down.

2. Instrument (≤10 min). Add a counter/log near the suspected seam. If I can’t measure it, I’m guessing.

3. Isolate (≤10 min). Toggle one variable at a time (flag, env, route).

4. Decide (≤5 min). Fix now if <10 min; else rollback with a note.

5. Receipt (≤10 min). Post a short “what/why/where” with the log line.

Paste-in template:

Issue: <one sentence>
Smallest repro: <command/url/config>
Suspected seam: <component or part>
Evidence: <log line or metric delta>
Decision: <fix/rollback/defer> (why)
Receipt: <paste link or id>
Follow-ups: <one or two>

Friction log (tiny habit, big payoff)

Every time something feels slower than it should, I jot one line. Review weekly; fix two items.

Why it works: this turns annoyance into a queue, not a mood.

Receipts: the smallest useful webhook

Boring JSON I can grep later:

{
  "event": "container.restart",
  "host": "friday",
  "service": "immich",
  "requested_by": "cli/sanskar",
  "correlation_id": "2025-09-05T12:04:33Z-immich-restart",
  "status": "ok",
  "duration_ms": 1432
}

That correlation_id shows up in logs, the chat message, and (if needed) Grafana. No arguments later.

---

Build vs Buy vs Self-host (decide in 5 minutes)

Score 1-5 and multiply, pick the highest total (not the loudest single number).

Rule of thumb: if learning × control doesn’t beat time-to-value × effort, don’t build.

---

Parametric parts that actually fit (Hello! 3D Printer)

• Datum first. Pick the surface that must align, reference everything from it.

• Clearance defaults. Start with +0.3–0.5 mm on FDM fits; adjust after one print.

• Stress lines. Add fillets at inside corners; avoid layer-line shear on clamp tabs.

• Swap-cost low. One variable per critical dimension; no magic numbers.

• Test as a draft. First print is a measurement tool, not a masterpiece.

This is how the door-frame projector mount happened (rented apartment, no drilling). Sketch → parametric → print → tweak → done.
Pro tip I still haven’t taken: buy a digital vernier caliper.

Boring checks I value (calm > clever)

• “Is the server reachable remotely?” with a timestamp. If that isn’t green, nothing else matters.

• “Last backup restore validated?” yes/no + date.

• “What changed?” 24-hour diff of container images and configs.

Tools I don’t want to give up: Jellyfin (no rental brain for media) and Immich (memories stay near me).

What I’m building toward (no hype, just direction)

• Lightweight local LLMs that act with receipts (grounded tools, auditable logs).

• More additive manufacturing, fewer zip-ties, publish the parametric files when they’re solid.

• Work upskilling with the same honesty I use at home: observability first, automation second.

• Restore-day in a box: clean hardware → one command → verified services.

Acknowledgments

Thanks to the seniors and teammates who reviewed my checklists, asked the annoying-but-right questions, and taught me to prefer guardrails over heroics. Any good ideas here are borrowed generously, the mistakes are mine.