- Situation
- The chatbot platform's runtime holds conversation state in memory, so under high availability any pod restart dropped live conversations.
- Task
- Survive pod churn without rewriting the conversational runtime the product was built on.
- Action
- I checked alternative frameworks, found the same limit, and kept the runtime: sticky sessions, state persisted to Mongo, and Redis pub/sub to close duplicates.
- Result
- The platform ran multi-container with state surviving restarts, and the design documented its failure modes, including those the fix introduced.
◈ View in the world- Situation
- The bot platform needed web push notifications, and my instinct was to build it in house for future flexibility.
- Task
- Decide between building and buying, separating engineering reasons from personal preference.
- Action
- I wrote down what I wanted from in-house, weighed it against what the release needed, and recorded the preference and the decision against it.
- Result
- We shipped on the vendor, and the recorded trade-off made later customisation questions easy to answer.
◈ View in the world- Situation
- A messaging product ran Keycloak for identity, yet users, roles and organisations already lived in Dgraph, so every write landed twice.
- Task
- Remove the dual write and its compensating code, and get to one store of record.
- Action
- I checked which Keycloak features were used, found none beyond authentication, which NestJS covers, and wrote a decision record proposing its removal.
- Result
- The dependency and its rollback logic came out, leaving the backend with a single store of record.
◈ View in the world- Situation
- A document assistant for a fleet operator needed an architecture, and one model trained on every vessel's documents was the assumed default.
- Task
- Lay out the real trade-offs of cost, latency and access control instead of just picking one.
- Action
- I wrote both options out for client and team: one shared model versus one model per vessel, with pros, cons and the replica arithmetic.
- Result
- The partitioned design went forward, with the loss of cross-fleet questions accepted openly.
◈ View in the world- Situation
- On a regulatory document platform, generated documents came out wrong in ways that did not reproduce, and retries repeated the bad output.
- Task
- Find the true cause in a pipeline whose output reaches a client in a regulated industry.
- Action
- I traced it to a global result cache that also stored partial failed runs, then re-architected generation around per-step isolation with failure-aware cleanup.
- Result
- Failed runs stopped affecting later ones, a retry became a real retry, and the written root cause let the team review it.
◈ View in the world- Situation
- Medical writing deliverables showed misplaced tables, detached titles, and sometimes raw markup visible as text in the client's document.
- Task
- Produce one root cause analysis for three separately reported bugs before anyone wrote a fix.
- Action
- I found three causes: raw XML mutation, incomplete model-emitted HTML, and context-blind placeholders. I moved tables to a structured contract with neighbour context.
- Result
- The whole class of defect went away, not just the three reported instances.
◈ View in the world- Situation
- Reviewing repositories before a host move, I found OAuth client secrets in git history, which ships to anyone who clones.
- Task
- Make the secrets unreachable, not merely invalid, before the repositories were pushed to their new home.
- Action
- I cloned bare mirrors, mapped each leaked value to a placeholder, rewrote history with filter-repo, pushed to the new remotes, and documented the exact procedure.
- Result
- The repositories moved with secrets removed from every commit, and another file with hardcoded credentials was flagged for cleanup.
◈ View in the world- Situation
- A large reported jump in search accuracy was circulating and was about to become a go-to-market claim.
- Task
- Check whether the gain was real, since repeated passing results seemed to be counted again across runs.
- Action
- I raised it plainly, then set a general standard: proposed improvements need a frequency table of failing cases and expected fix share.
- Result
- The inflated figure never reached a customer-facing claim, and benchmark results are now reviewed against a sheet before approval.
◈ View in the world- Situation
- Leadership wanted a cross-product integration delivered sooner because it strengthened the story with channel partners, which I agreed with.
- Task
- Show that the date was set by available engineering time, not technical complexity.
- Action
- I agreed with the goal, offered to make time visible through tracked tasks, and named three ways to buy time: delegation, clear ownership, hiring.
- Result
- The conversation moved from when it can be done to which trade-offs we accept, with the task breakdown as shared evidence.
◈ View in the world- Situation
- Search training was to be ported from an older e-commerce AI codebase, and the files looked like a simple lift and shift.
- Task
- Scope the port properly before committing a sequence of stories others would plan around.
- Action
- I read the code itself: the crawler was tied to one storefront, so I called for a fresh generic crawl-and-chunk pipeline and resequenced.
- Result
- The order of work changed without changing the plan, and client-specific code stayed out of the generic package.
◈ View in the world- Situation
- Two engineers were joining a document platform module covering audit logs, automatic mapping and server management.
- Task
- Give onboarding an intended outcome rather than just an activity.
- Action
- I asked the lead for the target outcome, how we would judge pace, and when production value was expected, and offered a reference checklist.
- Result
- Onboarding ran against a stated target and a first-value date, and the checklist was reused.
◈ View in the world