What Quality Assurance Taught Me About Writing Better Code

When I started working alongside QA engineers, the first thing that changed was how I read my own code. Edge cases stopped feeling like edge cases. They became the cases I had been quietly ignoring.

The biggest lesson was that tests are not a safety net for messy code. They are a forcing function for cleaner code. Once a test had to describe a behaviour clearly, the design started to follow.

Three habits I picked up

• Name the behaviour before you write the code. If the name is hard, the design is hard.
• Keep functions short enough to read in one breath. Long functions are how bugs hide.
• Treat every error path as a happy path. Users find them eventually.

None of this is new. The shift is that QA made these habits reflexive instead of aspirational.

export function formatPrice(cents, currency = 'USD') {
  if (typeof cents !== 'number' || Number.isNaN(cents)) return '-';
  return new Intl.NumberFormat('en-US', { style: 'currency', currency }).format(cents / 100);
}

What changed in my code reviews

I started flagging missing empty states, optimistic updates, and keyboard focus before the change ever reached QA. Reviews got longer, but the QA queue got shorter.

If you have not worked with QA in a while, borrow a tester for an afternoon. Watch them use your work. It is uncomfortable, and it is the fastest feedback loop you will find.