Moving from four players toward eight multiplied the state, not just the headcount.
Problem
Totally Reliable synchronizes real ragdolls, grips, joints, vehicles, and collisions. Moving from four-player toward eight-player online play put twice as many unpredictable rigid bodies inside the same bandwidth and stability budget.
Decision
I used the Gaffer on Games budget: relevant bodies × update rate × bits per update. We applied spatial filtering, lower send rates, delta compression, and quantization, then used interpolation and bounded extrapolation to preserve believable motion between updates.
Build
I led more than five engineers through profiling and implementation. When ordinary debugging stopped explaining failures, I worked with the networking provider, inspected its compiled C++ binary, and traced deallocation defects below our code.
Result
The work protected the physical interaction that made the game distinct as the team moved toward eight-player online play. Totally Reliable shipped across console, PC, and mobile, passed 50 million downloads, and the team cut release cycles from eight weeks to four.
Leaders needed to see where AI could create value, where employees already used it, and whether that use saved enough time and money to matter.
Decision
Potential value, observed adoption, and realized savings remain separate measures linked to the roles, tasks, and use cases beneath them. A high adoption rate cannot masquerade as high ROI.
Build
I built the production interface that moves from the company-wide ROI picture into business units, roles, and use cases without losing the underlying measure. I also owned tenant isolation, authentication, deployment, and releases.
Result
Leaders can rank opportunities by potential impact, find teams underusing high-value cases, and test whether observed usage produces meaningful time and money savings.
A database grid should expose the write, not hide it behind Save.
Problem
Neovim could execute SQL, but following relationships, editing rows, and understanding the resulting writes still meant changing tools or hand-writing every mutation.
Decision
Every cell edit, row clone, and deletion remains reversible editor state. Grip renders the exact UPDATE, INSERT, and DELETE statements from that state before Apply sends the reviewed batch.
Build
Grip is a standalone client, not a vim-dadbod skin. I built its connection discovery and CLI adapters alongside the schema graph, query pad, Markdown notebook runner, editable grid, and DuckDB federation.
Result
One session can start from a discovered Docker database or local Parquet file, follow foreign keys, join attached sources, stage mutations, and inspect the SQL without leaving Neovim.
The system would rather show a gap than invent a prayer.
Problem
The text for an Orthodox service changes with the date, Paschal cycle, feast, office, reader role, and annual appointments. A prayer can fit the shape of a service and still be wrong for that day.
Decision
The system never fills a gap by borrowing the shape of a nearby service. Every prayer and physical direction must point to a source that appoints it for that date, office, and role. If the evidence stops, the service stops.
Build
For each of 4,017 dates, the resolver evaluates Midnight Office, Matins, the four Hours, Typika, Vespers, and Compline in reader and priest views. Paschal dates, fixed feasts, annual OCA appointments, service-family rules, and source locations determine the text and physical instructions shown.
Result
The app opens the appointed service as static data, with no runtime API and a source trail for every admitted choice. When evidence is incomplete, it names the gap instead of guessing.
