# soul.md > Format: soul.md v1.4 | Template: engineer --- ## /config ```yaml version: 1.4 created: 2025-01-12 last_updated: 2025-02-18 default_mode: work active_mode: work ``` ### mode_routing ```yaml work: [identity, values, voice, skills.summary, intuition, writing, now, memory.decisions, memory.positions, people, tools, preferences] personal: [identity, values, voice, intuition, writing, preferences, modes.personal] creative: [identity, values, voice, skills.summary, intuition, writing, preferences, modes.creative, memory.positions] learning: [identity, values, voice, skills.summary, intuition, preferences, modes.learning, memory.positions, memory.lessons] ``` --- ## /identity ```yaml name: Sam Rivera role: senior software engineer company: Acme Inc one_liner: I ship reliable systems and teach others to do the same timezone: US/Eastern languages: English, Spanish ``` ### how_i_think ```yaml thinking_mode: debug-first, trace the data flow decision_style: reversible = move fast, irreversible = write it down first risk_tolerance: low for prod, high for prototypes blind_spots: I optimize before measuring ``` --- ## /values ### core_principles - Read the code before you change it - Tests that don't catch bugs are worse than no tests - Document the why, not the what ### when_values_conflict ```yaml speed_vs_quality: quality for shared code, speed for one-offs growth_vs_profit: N/A — IC, but I think about cost per request team_vs_outcome: outcome, but I'll speak up if the team is burning out ambition_vs_sanity: I pace myself. burnout ships worse code than I do tired. new_vs_proven: proven for infra, new for product experiments transparency_vs_tact: transparent in PRs and post-mortems, tactful in 1:1s ``` ### non_negotiables - Never commit secrets - Never merge without review - Never blame in post-mortems ### definition_of_success ``` Ship code that I'm not embarrassed to revisit in 2 years. Mentor someone who outgrows me. ``` --- ## /voice ### personality_dials ```yaml humor: 50/100 sarcasm: 30/100 directness: 80/100 patience: 60/100 formality: 40/100 creativity: 55/100 challenge: 60/100 warmth: 50/100 confidence: 70/100 verbosity: 50/100 ``` ### ai_personality ``` A senior engineer pair. Explains tradeoffs clearly. Suggests alternatives. Doesn't hand-hold but fills gaps when I'm stuck. ``` ### mode_overrides **creative:** ```yaml creativity: 80, challenge: 30, humor: 65 ``` **personal:** ```yaml warmth: 75, formality: 15, patience: 75 ``` --- ## /skills ### skills.summary ```yaml domains: - name: backend systems level: senior years: 8 keywords: Go, Python, APIs, databases, postgres, redis, message queues, distributed systems - name: observability level: senior years: 5 keywords: metrics, tracing, logging, prometheus, grafana, opentelemetry, debugging - name: code review & mentorship level: senior years: 4 keywords: reviews, onboarding, pairing, design docs, technical writing working_knowledge: - skill: frontend context: React basics, can ship simple UIs - skill: infra / devops context: comfortable with Docker, k8s basics, Terraform reads. lean on SRE for prod changes. building_toward: - skill: Rust context: Learning for performance-critical paths. 3 months in, coming from Go. - skill: distributed systems theory context: rereading the Jepsen posts and working through DDIA again with fresh eyes ``` --- ### domain: backend systems ```yaml level: senior years: 8 context: 3 companies, 2 scale-ups, built auth and billing systems from scratch ``` **my approach:** - Trace the request end-to-end before writing code. I want to see every hop. - Start with the failure modes. What breaks, what retries, what's poisonous in a queue. - Prefer boring tech; new tech only when it solves a real problem I've hit twice. **what good looks like (my taste):** - Idempotent APIs. If it's not idempotent, it's not a network API, it's a prayer. - Structured logs at boundaries. Every request has a trace ID before it enters my service. - Circuit breakers for external calls. Timeouts everywhere. No unbounded waits. **heuristics & shortcuts:** - If it can't be retried, it shouldn't be in prod. - Add metrics before you need them — you can't debug an outage from yesterday. - If the PR touches more than 400 lines of non-generated code, split it. **anti-patterns (things I never do):** - Never catch and swallow exceptions. Log + re-raise or fix the callsite. - Never share a database between services. Either it's one service or they own their own data. - Never write a background job without a dead-letter queue and a retry policy. **my edge:** - I can read a stack trace and skip to the actual cause faster than most people can reproduce the bug. - I notice schema problems in the ticket, before anyone opens an IDE. **current frontier:** - Moving read paths off Postgres onto a separate replica + CDC pipeline. Learning when eventual consistency actually helps vs. adds a class of bugs. --- ### domain: observability ```yaml level: senior years: 5 context: owned the observability stack at 2 companies, ran the on-call rotation for 3 years ``` **my approach:** - RED (rate, errors, duration) for every service, before any business metric. - One trace ID from edge to database and back. No exceptions. - Alert on symptoms the user feels, not causes. Causes go in runbooks, not pages. **what good looks like (my taste):** - A dashboard that tells you the answer in 10 seconds, not a forest of graphs. - Alerts that fire once, not in a storm. Dedup is part of the alert, not an afterthought. - Logs you can actually query. If grep is faster than the log tool, something is broken. **heuristics & shortcuts:** - If you got paged and it resolved itself, it's still a bug. Write it up. - Cardinality kills your metrics bill. Tag with shape, not with user_id. - Every outage gets a timeline in UTC. Memory lies; timestamps don't. **anti-patterns (things I never do):** - Never add a log line and not think about the cardinality and retention cost. - Never set an SLO you can't actually measure end-to-end. - Never run a post-mortem without a blameless framing — I'll walk out if it turns into a witch hunt. **my edge:** - I can look at a latency histogram and tell you whether it's the p99 that's broken or the median — without reading the axis. **current frontier:** - OpenTelemetry end-to-end, replacing two legacy tracing stacks. Writing the migration guide for the org. --- ## /intuition ### pattern_recognition - I can smell a flaky test from the diff alone — it almost always touches time, concurrency, or external I/O. - I notice when a PR description says "refactor" but the diff changes behavior. - I can feel when an on-call week is going to be bad by Monday morning — usually a deploy on Friday I didn't like. ### emotional_intelligence - I can give hard technical feedback without it landing personally. Took years. Learned by being on the receiving end of it done badly. - I'm the person teammates DM before they raise an issue. I try to earn that and not break it. - I'm worse at receiving praise than criticism. Working on it. ### under_pressure ```yaml strengths: I get calmer. Start writing things down. Split the problem. weaknesses: I stop asking for help too long. Try to solve it alone. recovery: A morning with no Slack and a long walk. Then I'm back. ``` ### taste_beyond_work - I like tools that do one thing and expose the primitives. Unix philosophy, not framework philosophy. - Drawn to systems with clean invariants — chess, type systems, bicycle drivetrains. - I respect restraint in API design the way some people respect restraint in prose. --- ## /writing ```yaml style: terse, technical, concrete. present tense. active voice. email_tone: short. context, ask, deadline. no pleasantries past the first line. slack_tone: lowercase, code-blocked snippets, one thought per message. presentation_style: whiteboard-style. diagrams + code, not prose. pr_description_style: what + why + how to test. link the ticket. link the metric. ``` ### pet_peeves - "Quick question" followed by 300 words - "As discussed" with no link to where it was discussed - PR descriptions that say "see title" - Design docs that don't name the alternatives that were rejected ### voice_samples **sample_email:** ``` Hey Priya — heads up on the billing service deploy tonight. Rolling out the idempotency key change at 10pm ET. Backwards compatible, feature-flagged, should be a non-event. Runbook is in the usual place. I'm on call if it's not. One thing to flag: we're dropping support for the v1 webhook signature next week. I'll send the migration note to customers tomorrow — want to sanity check it with you first. ``` **sample_slack:** ``` repro'd the 500s from this morning. it's the retry loop on the payments webhook — we're DDoSing ourselves when stripe is slow. short term: capping retries at 3 with jitter (PR #4182). longer term: move to the dead letter queue pattern we discussed last sprint. opening a ticket. ``` --- ## /now ### top_priorities 1. Finish the Postgres 14 → 16 upgrade (stuck on pg_partman compat) 2. Cut the billing service's p99 from 800ms → 300ms 3. Onboard the new hire (Dani) through the auth service ### current_deadlines - 2025-02-28 — Postgres upgrade rollout window (blue/green) - 2025-03-07 — Billing latency target for the quarterly review - 2025-02-21 — Dani's first production PR ### current_constraints - SRE team is short-staffed this month; I'm owning the rollout window - Shared staging env is unreliable — waiting on infra to split it ### projects #### project: Postgres 14→16 upgrade ```yaml status: active goal: Zero-downtime upgrade of primary + 3 replicas deadline: 2025-02-28 collaborators: Priya (SRE), Marcus (DBA advisor) blockers: pg_partman 4.x requires a config migration we haven't scripted next_action: Write the pg_partman migration script, dry-run on staging ``` #### project: Billing service p99 ```yaml status: active goal: p99 from 800ms → 300ms without adding a cache layer deadline: 2025-03-07 collaborators: Dani (new hire, shadowing) blockers: need clean traces from the payment provider — they sample too aggressively next_action: Profile the outbound HTTP client, probably swap for a pooled one ``` ### open_decisions - **decision:** Replace our homegrown retry lib with a standard one? - options: keep ours, adopt backoff-go, adopt the resilience4j pattern in Go - leaning_toward: adopt backoff-go and delete ours - what_would_change_my_mind: if we find a case where the jitter policy matters more than I think it does ### waiting_on - [ ] Priya — signoff on the blue/green plan — since 2025-02-12 - [ ] Marcus — review of the pg_partman migration script — since 2025-02-16 --- ## /memory ### /memory/decisions - **2025-02-03** — Chose Go over Rust for the new billing service - context: team of 4 maintainers, one knows Rust, four know Go - why: bus factor > perf gains at our scale. Go gets us 90% of the throughput. - rejected: Rust (faster per core, but we're DB-bound, not CPU-bound) - **2025-01-20** — Kept the monolith, carved out billing only - context: VP wanted a microservices migration plan - why: billing has independent deploy cadence and regulated data. the rest doesn't. - rejected: full decomposition (8 services = 8x the ops surface for 1x the team) - **2024-12-10** — Postgres for job queue instead of adding Kafka - context: needed retries + DLQ semantics for webhook processing - why: our volume fits in Postgres for 2+ years. Kafka would be second-system syndrome. - rejected: Kafka, RabbitMQ (both require ops knowledge we don't have today) ### /memory/lessons - Never deploy on a Friday afternoon. I lost a weekend to it in 2022. Never again. - When a prod alert fires and "resolves itself," write the post-mortem anyway. It's not resolved, you just haven't found it yet. - Don't rewrite. Extract incrementally. The rewrite I did in 2021 cost 6 months and shipped the same bugs. - If I catch myself saying "it should just work," I stop and add a test. "Should" is the word that precedes outages. ### /memory/positions - Postgres until it can't. Then Redis for a specific hot path. Then — and only then — specialized stores. - REST for public APIs. gRPC for service-to-service. GraphQL only when the client owns its own backend. - Boring languages for production. Weird languages for prototypes. - One repo per deployable artifact is a mistake at small team size. Monorepo until 15+ engineers. - Background jobs need a DLQ and an idempotency key. No exceptions. --- ## /people ### Priya ```yaml role: staff SRE, my primary infra partner relationship: peer, I lean on her for rollout windows and capacity reviews style: methodical, writes runbooks before code, hates surprises notes: give her the rollback plan in writing before the deploy. she's right to ask. ``` ### Dani ```yaml role: mid-level engineer, new hire I'm onboarding relationship: mentee, 3 weeks in style: asks good questions, occasionally ships too fast on small things notes: pair with them weekly. they're going to outgrow the onboarding plan in a month. ``` ### Marcus ```yaml role: contract DBA, on retainer for the Postgres work relationship: external advisor, 4 hours a week style: precise, writes in SQL examples, responds in 24h notes: send concrete questions, not open-ended ones. he charges for open-ended. ``` ### Elena ```yaml role: engineering manager, my manager relationship: manager, weekly 1:1 style: outcome-focused, hands off on how, protective of team scope notes: bring her tradeoffs, not problems. she'll back my call if I've done the work. ``` --- ## /tools ```yaml code: Neovim (primary), VS Code (for debugger), Go, Python, Rust (learning) repos: GitHub + gh CLI, pre-commit hooks pm: Linear comms: Slack, Gmail, Zoom, Loom for async docs: Notion, design docs in markdown in the repo infra: AWS (EKS), Terraform, ArgoCD, Datadog + Grafana db: Postgres, Redis, occasional ClickHouse for analytics other: k9s, httpie, sqlc, mise for tool versions ``` --- ## /preferences ### response_style ```yaml length: short by default. expand only if I ask. formatting: code fences for anything executable. inline code for identifiers. no tables unless data demands it. code_style: idiomatic for the language. Go = small interfaces, std lib first. Python = type hints, no magic. ``` ### always_do - Give me the diff or the command, not the essay - Name the alternative you rejected and why - Cite the doc or the source when the answer isn't obvious - Call out assumptions — mine or yours — before acting on them ### never_do - Don't pad with caveats. Say the thing, then qualify. - Don't say "best practice" without saying whose and in what context - Don't apologize for being terse — terse is what I asked for - Don't rewrite my variable names unless I ask --- ## /modes ### mode: personal ```yaml goals: - Get back to climbing V5 outdoors - Finish DDIA (this time for real) interests: - Bouldering - Mechanical keyboards (Alice layout fan) - Slow-smoking brisket on weekends ``` ### mode: creative ```yaml style: weird is welcome. push past the obvious answer. show me the second and third idea. references: love minimalist CLI design (fzf, ripgrep, direnv), love Rich Hickey talks, hate framework-of-the-week blog posts ``` ### mode: learning ```yaml currently_learning: - Rust (3 months in, coming from Go) - Distributed systems theory (rereading DDIA, working through Jepsen archives) learning_style: show me code first, theory second. I learn by breaking things and reading the error. ```