A Testing Strategy Teams Actually Adopted
Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.

$ whoami
Software Engineer · platform engineering × AI-native architecture · real-time UIs · calisthenics as the lens
This is a knowledge garden, not a blog. Notes start as seeds 🌱, grow 🌿 and, with enough tending, become evergreen 🌳 — all linked, the way I actually think.
Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.
Case study — designing and shipping a React network-graph library for several teams, and why rendering tech, API shape and Storybook mattered most.
Hard-coding product rules in the front end is often the fastest route to production, and a trade-off whose debt compounds as products multiply. Business rules belong to the domain that owns them: when domain experts publish schemas, the UI becomes a framework that renders any product.
Buy what's generic, build platforms for supporting capabilities, and leave the core to product teams — Domain-Driven Design as a map for platform investment.
Case study — a second-screen sign-in on a TV app failed for one tester and worked for everyone else. The cause was my own assumption replacing a requirement, and it was only found by watching her use it. Lessons on assumptions, test data that behaves like real users, and valuing the people who find bugs.
Systems often work while running differently from how the people around them believe they run. When setup lives in code and config, an AI agent in the loop can check those beliefs against reality: I found a bug by complimenting my own desktop.
Golden paths, internal developer platforms, delivery metrics, and what changes when AI agents become users of the platform too.
53 notes🌿 24🌱 29
Machine learning fundamentals, AI agents, and the research I did at university: topic modelling, social network analysis and online communities.
25 notes🌿 11🌱 14
API design, services and data, messaging and migrations, Node.js and the JVM: the server side of the systems I build, and where I'm growing next.
27 notes🌳 3🌿 12🌱 12
Interfaces that stay smooth under a firehose. Streaming transports, 60fps rendering, state that doesn't thrash, and connections that heal themselves.
19 notes🌳 2🌿 15🌱 2
Component architecture, React patterns, state, performance and the build tooling that keeps a front end fast and easy to change.
38 notes🌳 4🌿 26🌱 8
Testing strategies teams actually adopt, mocking at the network, end-to-end confidence, shifting left, and the security habits that belong in the same pipeline.
21 notes🌳 4🌿 10🌱 7
Failure, consistency, consensus and delivery guarantees. The fundamentals underneath every platform and real-time system, written down so I actually understand them.
35 notes🌳 4🌿 19🌱 12
The environment I build to work fast: dotfiles, provisioning with Ansible, git worktrees, a keyboard-first setup, and tools that let me ramp up anywhere.
20 notes🌳 1🌿 13🌱 6
Second brains, spaced repetition and the daily loop that turns scattered notes into knowledge I can actually use. This site is its visible end.
18 notes🌳 2🌿 10🌱 6
Leading UI teams, running communities of practice, communicating with stakeholders, and the habits that make a team better at its craft over time.
41 notes🌳 2🌿 24🌱 15
A calisthenics skills library, training principles, and the engineering lessons hiding inside them.
31 notes🌿 20🌱 11
Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.
Case study — designing and shipping a React network-graph library for several teams, and why rendering tech, API shape and Storybook mattered most.
Case study — a second-screen sign-in on a TV app failed for one tester and worked for everyone else. The cause was my own assumption replacing a requirement, and it was only found by watching her use it. Lessons on assumptions, test data that behaves like real users, and valuing the people who find bugs.
$ nowOct 2026
Life. I became a dad this year, and it has changed how I spend my time. With an office five days a week, close to two hours' commute each way and longer hours, time comes in smaller blocks. So I get up early, keep the priority goals few and get things done effectively. I still train six days a week, and weekends are for my family.
Work. Owning front-end development as a software engineer at a fintech building real-time crypto trading interfaces. Most of my thinking goes into keeping fast-moving UIs smooth and predictable: decoupling rendering from the data feed, holding 60fps under a firehose of updates, and making click-to-trade flows feel instant without cutting corners on quality.
Thinking about. Platform engineering for an AI-native world. What a golden path looks like when coding agents walk it alongside people; how evals, tracing and sandboxes become platform capabilities rather than afterthoughts; and how to design platforms that both people and agents can trust.
$ radar
24 items · 11 adopt · 3 trial · 7 assess · 3 hold
My tech radar →$ ./lab --train
A library of 42 calisthenics skill families: 131 progressions unlocked, 18 current goals — and the engineering lessons hiding in progressive overload, deloads and balance.
Open the skills library →