Hello, world

I am Jason Yang, an engineering manager at Frontify in Switzerland. My team owns the media delivery path end to end: the engine that processes and serves every image and video for our customers, and the Kubernetes infrastructure and CDN caching it runs on. The mission we set ourselves is media processing and delivery that absorbs any customer’s spike without ever slowing another customer, at a cost we are proud of. I still design, review and ship code. That is a choice, not an accident.

Before Frontify I was co-founder and CTO of ImpactNexus in Berlin, a sustainability-reporting SaaS. I took over an existing team, built the company’s first structured hiring process and grew the team through it, and owned the engineering cost base. On the technical side I built the delivery machinery from zero: keyless CI on GitHub Actions, zero-traffic deploys with gated promotion, and a preview environment for every pull request on a private network. The build went from forty minutes to two, test coverage quadrupled, and the hotfix churn that had defined the repo before I arrived stopped. I added end-to-end tracing with OpenTelemetry, took the GraphQL API from multi-second responses to under a hundred milliseconds, and shipped the audit trail and admin tooling the regulated domain demanded. The parts I am proudest of are the ones that outlasted me: the team I left kept building on that foundation rather than replacing it, and my direct reports’ feedback on how I led them was the best I have received. Before that I was the third engineer at Leapsome through its Series A, and a backend engineer on the Growth team at Grab in Singapore, writing Go microservices and the deploy tooling used by a thousand engineers. I started out at two large internet companies in China, where a hundred million users on one product is normal and a few milliseconds of latency is a lot of money. Upgrading PHP across a thousand servers with zero downtime taught me what scale actually feels like. Porting XHProf, Facebook’s PHP profiler written in C, to PHP 7 taught me how PHP actually works underneath: the Zend engine’s execution hooks and opcode handlers, and the memory leaks and segfaults you meet when you hook into them. Other people still use that port today. I have always been drawn to the low-level side, the runtime, the kernel, a core dump in gdb, and it keeps paying off: a surprising number of the bugs worth writing about are the ones that only make sense once you look one layer down.

The thread through all of it is the same. I like building high-performing teams that build high-performing systems: teams where the path from a merged pull request to production is short, safe and boring, where the four DORA metrics are numbers people actually look at, and where knowledge lives in documents and paved paths rather than in one person’s head. Developer experience is not a nice-to-have in that picture. It is the mechanism. A good part of my job is explaining complex systems to founders, customers and people who do not build systems for a living, and I think being able to do that is part of what makes a good engineer.

Most of my working days end with a small pile of things I figured out: a flaky rollout that turned out to be a config default, a caching layer we decided not to build, an autoscaler that scaled at the wrong moment, a migration that went sideways for a reason nobody had written down. Almost all of that knowledge evaporates within a month. This blog is my attempt to stop the evaporation.

Writing a problem down forces me to state what I actually knew at the time, what I tried, and why the final decision looked reasonable. If it also helps someone who searches for the same error message at two in the morning, even better.

The topics will follow what I am working on, which right now means:

• Kubernetes platform work. GitOps, Helm, autoscaling, and progressive rollouts.
• Delivery discipline and developer experience. CI gates, preview environments for unmerged code, staged rollouts, DORA metrics, and what it takes to build a paved path a team trusts.
• Media and CDN infrastructure. Caching, media processing pipelines, and the cost and latency tradeoffs of serving a lot of traffic.
• Observability. OpenTelemetry, and getting to SLOs that a team actually looks at.
• Engineering management. Growing engineers, running a team through change, working with platform and infrastructure partners, and deciding what not to build.
• AI-assisted engineering. Where it speeds us up, where it does not, and what changes about code review when the diff was not typed by a person.

Expect mostly short posts, each about a concrete problem: the context, what I tried, what worked, and what I would do differently. Occasionally I will write something longer when a topic deserves it. Everything here is my own opinion, not my employer’s.

Posts are tagged and there is an RSS feed. If you spot a mistake or want to argue about a tradeoff, please get in touch. That is half the point.