Why I build Chrome extensions on the side
By day I build data platforms and pipelines. By night I keep shipping Chrome extensions. People sometimes ask why a data engineer bothers with browser tools, and the honest answer is that they scratch a completely different itch. Pipelines are about scale and trust. Extensions are about one person, one annoyance, and a tool small enough to finish.
Small enough to actually finish
A pipeline can run for months and still feel unfinished. An extension has a clear edge. You spot a friction in your own browsing, you build the smallest thing that removes it, and you ship. That short loop from idea to something installable is rare in big data work, and it keeps the joy of building alive.
They put me back in front of the user
In data engineering the user is often three teams away. With an extension, the user is me, and then it is whoever installs it. Reviews and install numbers are blunt but honest feedback. There is nowhere to hide behind a clean architecture. Either the tool is useful or it gets uninstalled.
The constraints make me a better engineer
Extensions force discipline. You work inside a tight permission model, a small bundle, and a review process that does not tolerate sloppiness. Respecting a user's data, asking for the least access you need, and keeping things fast are not optional. Those same instincts carry straight back into how I think about data platforms.
It connects the two halves of what I do
The thread running through all of it is the same. Take something messy or tedious, and turn it into something people reach for without thinking. Sometimes that is a pipeline feeding a dashboard. Sometimes it is a button in a context menu. The medium changes, the instinct does not.
If you want to see where this goes, the extensions live on the work page, and each has its own writeup.