A customer wrote in this week. A list in our product wasn’t sorting in a predictable way. Every refresh produced a different order which is really annoying and confusing. Definitely a bug.
I looked into it, found the cause, and opened a pull request to fix it.
That last sentence is the part I love about my job.
I work at Workbrew as a Support Engineer. The role sits at the intersection of support and engineering, which means I get to help customers and push fixes into the product when it makes sense.
The normal route, if I wasn’t allowed or able to write code, would look like this. Open a product discovery issue. Discuss it with the team. Decide on the best approach. Wait for engineering to prioritize the work. Of course, that is the right process for most things. Especially for changes that touch product design.
But for a clear bug with a clean fix? I can just do it. I open the PR, the team reviews it, and it ships. The customer who reported the issue stops hitting it. So does every other customer who would have run into it next week.
That is what I love most about this role. I get to treat support requests as opportunities to eliminate future ones—a practice I think about often. Not every request, of course. Some pieces of feedback are larger product design questions, and patching them as bugs would only make the product worse and more complicated. But the rest? Most of them, especially the bugs, can travel from inbox to deploy in a single afternoon.
I had a version of this at GitHub, years ago. In the early days, support engineers could open pull requests. We’d see a bug, write a fix, get it reviewed. It felt great. Then the company grew. The product got more complicated. The bar for changes got higher, and at some point support was no longer allowed to open PRs. I think that was the right call. The risk had outgrown the benefit. But I still remember the thrill of being able to bring a fix or an improvement for a customer to see on the spot.
But that was ages ago. Today’s tools blur the lines again. It’s easier—riskier, sure—for people outside engineering to suggest fixes. The rules and best practices still matter.
I don’t know how long this window will stay open. Companies grow. Products get more complex. The economics may shift again. But for as long as I get to wear both hats, I will enjoy it tremendously.
Here’s what I am doing
At Workbrew, I help our customers succeed, while working on docs, fixing bugs, and developing internal tools. At Amignosis, I pour my heart and skill into crafting slowly brewed software, one thoughtful line at a time. I am craftsman in a world of complexity and low-quality solutions. I am a shoemaker. I take the time to create simple, timeless software built to last. Check what I am doing now and talk to me.
Leave a Reply