Why I Obsess Over "Boring" Unit Tests: Confessions of a Former Onsite Support Engineer

Ever used a piece of powerful software that just felt... wrong? A feature that technically works, but feels clumsy, slow, or just plain counter-intuitive?

I have a theory why: The developers who built it were too far away from the people using it.

I know this because I’ve been on both sides of the fence. I started my career as an Onsite IT Support Engineer, working directly with clients at places like the National Healthcare Security Administration (NHSA) in China. I was the "fix-it" guy.

Today, I’m a Full-Stack Web Developer, the "build-it" guy. My journey from the front lines of support to the back end of development taught me one crucial lesson that I bring to every line of code I write.

Part 1: Life on the Front Lines (The Support Role)

Being onsite support isn't just about closing tickets. It's about absorbing user frustration.

I wasn't just "providing technical support"; I was the face of the company when things went wrong. My daily reality involved:

• The "Manual Grind": I provided hands-on data filtering, export, cleansing, and analysis services for the client. I felt the pain of slow, repetitive manual processes. I knew exactly why users were unhappy.
• The "Root Cause" Hunt: My job was to report software issues back to the company, but more importantly, to identify the root causes. I quickly learned that many "user errors" were actually design flaws.
• The "Training Day" Wince: I trained client users on how to use the system. I watched, in real time, where they paused, where they got confused, and which features they avoided entirely.

You can't get that kind of feedback from a bug report. That's pure, unfiltered reality.

Part 2: Writing Empathy into Code (The Developer Role)

My philosophy as a developer is simple: Every line of code I write today is to prevent a future version of me from getting a frantic support call.

This perspective changes how you build.

1. It's Not About "Features," It's About "Workflows"

When I'm tasked with optimizing inventory management or logistics workflows, I'm not just following a spec sheet. I'm channeling my inner support engineer.

Before: "The spec says to build a button."
Now: "Will this button make sense to the warehouse picker at 5 PM on a Friday? Can we optimize this picking path so it actually saves them steps, not just looks good in a demo?"

When I develop solutions based on business requirements, I'm also thinking about the support requirements.

2. Why I Obsess Over Testing (Answering the Title)

To some, testing is the "boring" part. To me, it's the most critical part. It’s not an academic exercise; it’s risk prevention.

When I was in support, I had to deal with the messy aftermath of code that failed in production. Now, I do everything I can to prevent it.

• I write high-coverage unit tests because I’ve seen how one tiny, broken module can bring down an entire system.
• I design stress tests because I’ve personally witnessed a system crawl to a halt under a high load.
• I develop system tests because I’ve had to manually clean up the data mess left by an end-to-end workflow that wasn't truly end-to-end.
• I insist on gray-release deployments and real-time error log monitoring because I would rather find and fix a problem when it affects 1% of users than be in a war room trying to fix it when it affects 100%.

The Takeaway

The biggest shift from Support to Development wasn't technical. It was moving from reactively fixing problems to proactively preventing them.

My background in support isn't just a line on my resume; it's my secret weapon. It’s what drives me to build software that isn't just functional, but usable, stable, and respectful of the user's time.

The best code is the code you never have to think about. And to write that, you have to have been in the room where people were thinking (and complaining) about it all the time.