About

I'm a test engineer who kept wandering into the infrastructure.

Flying robots first

I studied Telecommunication Engineering at Telkom University, but the part I actually remember is Kontes Robot Terbang Indonesia — Indonesia's flying-robot contest. I ran the systems division: the flight control system, and the PID tuning that decided whether our aircraft held its line or wobbled itself out of the sky. We took first place in 2014 and again in 2015.

2016 is the one that stuck with me. We should have won it. Another team found a gap in how the scoring worked and played it, and we came away with Best Idea and a runner-up placing instead. That was the first time I understood that something can be technically right and still lose to the rules it's measured by — which, it turns out, is a large part of what quality engineering is about.

Then testing, mostly by accident

I didn't set out to do QA. An opportunity came up, it fit, and I kept going. Eight years later I'm still here — because the part I enjoy turned out to be the part that isn't in the job title: problem solving. I want to know why a bug happened, not just that it did, and then how we could have caught it earlier. Following that question is what moved me from writing tests, to building the automation, to building the pipelines the automation runs in.

A wall of televisions

Somewhere in there I ended up responsible for a room with 25 TVs on custom brackets, spanning six different TV operating systems. Two problems came out of that room, and they turned into the two longest stories on this site. First, nobody could reach the televisions once the office emptied — so we builta control plane for them: ESP8266 boards, infrared LEDs taped under each set's sensor, and a web page that lets anyone drive any TV from anywhere. Then, on top of that,automated testing across all six platforms — Maestro where it fitted, and an in-house driver where nothing could attach at all.

The homelab is not a hobby, exactly

I run Docker, Kubernetes, Ansible and a VPN server at home. It started because I like taking things apart. But that home infrastructure is the reason I could step into Developer Productivity Engineering under DevOps — I had already broken most of it once at home, where breaking it cost nothing.

Where this is going

Vidio opened a path into DPE and DevOps and I took the shot. What pulls me is breadth: the more infrastructure I genuinely understand, the more I can do for test engineers — faster CI/CD, a tighter test lifecycle, less waiting on someone else. That's the work I want more of. Making the people around me faster.

Outside work

Counter-Strike. I drift to other games and always come back to it.