Software Engineer

Why I joined

After my role at Sky ended in redundancy, I was looking for my next step. This time the title mattered less than the work: I wanted somewhere I could own a lot and ship fast. A fintech building real-time crypto trading UIs stood out quickly. It was very fast-paced, the people were some of the sharpest I’d met, and it was a startup, where a lot of work gets done and you can genuinely own what you build.

It also suited what I’d been growing into. Real-time interfaces are front-end performance at its hardest, and after years leading the UI of a large platform I wanted to go deep on the engineering itself, as a hands-on individual contributor. In the months before I started I spent time learning about markets and crypto, from trading basics to the history of Bitcoin, so I wouldn’t arrive without the vocabulary. The trading books on my shelf come from the same push (Trading for Dummies, Trading in the Zone).

The role

I’m a software engineer on a set of low-latency, real-time trading platforms, working in React on the front end with Java behind it. It’s a flat team where engineers own their work end to end, so the focus is different from my lead roles: less coordinating, more building. I own projects, drive features through, and push on optimisation and process improvement, the same responsibilities I had before, done from the keyboard. The role covers the whole path from conversation to code: talking to clients, understanding feature requirements, producing designs and architecting solutions, then delivering at a very rapid pace without giving up quality or latency. We work together in the office five days a week, which suits work this fast.

What I’ve built and driven

At the level the CV describes:

• Real-time trading execution and click-to-trade, where the interface has to be both instant and unambiguous.
• Request-for-quote (RFQ) trading workflows.
• Trading strategy tools, letting users shape and adjust strategies from the UI.
• Live market visualisations running at 60fps, under a constant stream of updates.
• Modernised quote pricing, so the people using the system don’t miss a second.

The engineering pattern I lean on most is decoupling the render loop from the data feed. Piping every socket message through component state re-renders far more than it should, so the socket gets a single owner and only the leaf components subscribe to the latest values (Zustand Transient Updates, WebSockets). The feed can be as bursty as it likes; the screen only needs the latest frame.

Results

The honest summary is the CV’s: delivering key trading functionality at a very high pace while keeping quality high and latency low, across execution, click-to-trade, RFQ, strategy tools, live visualisations and quote pricing. I don’t publish internal metrics, and the more detailed write-ups will come as case studies once the lessons have settled.

What I’m learning

• Performance is a product feature. In trading, latency and dropped frames aren’t polish; they change outcomes.
• Domain knowledge speeds everything up. Understanding what an order type or a quote really means makes requirement conversations shorter and designs better.
• Show the signal. Dense, live data needs calm, honest visuals more than decoration (The Visual Display of Quantitative Information).
• Pace needs structure. Moving fast works when the guardrails (types, tests, review) are automatic, so speed doesn’t turn into rework.

What comes next

This is my current role, so this section is still being written. When there’s a next step, I’ll add the story here, the same way I have for the roles before it.