What's your secret sauce for maintaining product quality?

Someone on the inside being obsessed with the product. As a user.

There's a night and day difference between products that get used by the people who make it and those who ship it off to the user and wait for the response.

This is primarily aimed at B2C but there's plenty of cases where it applies in B2B as well (if you can somehow use your own product).

Dogfooding is one attempt to mimic this, and it can work. But what I really mean is someone inside the company actually cares enough, is interested enough, to use the product for themselves. Without being told to.

Less. When I write JavaScript I use ECMA modules, primitives, 1 style of loop, arrays, functions, objects, and conditions. That’s it.

I limit my use of dependencies to as few as possible, typically just TypeScript and a compiler like SWC. No frameworks because that’s nonsense I don’t want to be responsible for.

I measure things. When people talk about performance they are almost always full of shit and likely wrong by several orders of magnitude. When I mention that my software is fast it’s because I have numbers for my own software. I also have numbers for the competition, where products or alternate conventions, so I know just how much faster my software is.

My prior application was a peer to peer file sharing application that displayed an OS-like gui in the browser. I need end to end test automation that could work on multiple computers in a peer to peer model. Since that did not exist I wrote my own and was able to run about 300 tests in 8 seconds on a local computer and about 200 tests in 30 seconds across 5 computers interacting with each other using the application.

If you want quality in your software you need to really own it. All of it and obsessively so. If your team pushes back because they need easy or some superficial bullshit like React or Angular then people management is, by far, your biggest problem.

Secret sauce is not a technical one, but rather organizational. Pushing back against product/marketing/management to timely address the tech debt is vital for a product quality. As opposed to always sprinting to implement new features.

1. Know what and why you are building. Some would call it business-domain knowledge. I'd prefer calling it "now why your product is being used, and how it is used exactly". This alone gets rid of the vast majority of bugs and other problems.

2. I used to be a QA for about a decade in a previous life. I know where and how classic (technical) bugs happen, it's easier to avoid then that way.

Among other strategies for better quality: Inspect, record, make a root cause analysis and understand the supply chain.

I do code reviews as part of team meetings - so assign someone to review the code, then walk it thru in the meeting. It allows us to be clear on the expectations and discuss changes

The key is to not make it an ego led session to keep discussion open

QA Automation.