A bit of insight

Instead of just ticking off boxes of a list, I like to approach my work by thinking in the terms of the whole system.

So first I like to start with these questions:

I'm also keen of the "ship fast & incrementally" approach - we don't need to come up with a perfect solution. A "perfect" solution may not even exist. But a beautifully complex solution to a tricky problem that's months from shipping is, in my eyes, objectively worse than an MVP that's shipped in weeks and gets updated every week based on feedback.

Here are some particularly tricky solutions that I'm rather proud of:

Handling "simple" issues

Problem

"Hey David, can you bring Neo to tech-i?"

How I approached it

I've adapted its ingestion, indexing, and retrieval pipelines. I also integrated chat APIs, configuration, message and feedback storage, prompt and organisation synchronisation, and frontend embedding's infrastructure. Beyond that adaptation, I set up LLM-assisted text and media processing pipelines across YEP News, News Pilot, and tech-i.

Quantify results and iteratively improve

Problem

After bringing Neo to tech-i, I wanted to know whether its retrieval was doing a good enough job.

How I approached it

I built evaluation harnesses for retrieval, query routing, and citation quality, then used the results to improve search relevance and citation correctness. On the worst-performing representative case, relevant articles rose from 3–4 to about 14 of 32, close to the 15-result limit.

Make failures visible

Problem

“Translations are failing, and I don’t know why.” Users had no clear way to see which third-party translation or transcription engines were having trouble.

How I approached it

The underlying issue was that the availability of the third-party translation/transcription services used were not equal (there were also pricing/quality differences). I built an adaptive engine-selection system that detected declining provider availability and automatically disabled degraded engines. I added monitoring, Slack and log alerts, and an admin control interface so the team could see and manage failures.

Own the full stack

Problem

Product work can cross the user interface, backend services, and software that runs as part of a larger ecosystem.

How I approached it

At Deloitte, I built a TypeScript application that brought environmental project data through an API into an interactive map. Much of my work has been in Python backends, search, and indexing. At NNG, I worked on line-fit automotive products across multiple generations and hardware/software platforms.

Make undo possible

Problem

People make mistakes. If your product uses blockchain to track user transactions, that can be an issue.

How I approached it

I designed and built an undo workflow that calculated and executed those reversing operations.

Optimization

Problem

At Theme Analytics, the neural-network market analysis took about two minutes at market open, missing the under-a-minute requirement.

How I approached it

I designed a high-throughput backend and optimized market-open processing to under 20 seconds, raising per-run throughput more than sixfold.

Adapt work to the device

Problem

At Prezi, a frequent issue raised by customers was that their presentations loaded slowly. But oftentimes, there were simply not enough resources available locally to do the image processing.

How I approached it

I reworked the pipeline to choose client-side or cloud processing adaptively, based on the device’s available capacity and bandwidth. This reduced graphics-engine load times by 20–90%.

Improve how we ship

Problem

Customers like it when they get what they paid for, and deadlines are kept.

How I approached it

At NNG, I led the project and optimized the development process. We shipped on time, without overtime or any pending customer issues at launch — a first in the company’s history.

Any hat that’s required

Problem

Headcount is not infinite on a project. A specialist might not be available.

How I approached it

I’ve worked in essentially every role throughout the years; as a test automation engineer and as an individual contributor, and I’ve led projects from a technical perspective. I’m comfortable moving between those modes and staying close to the work.