The Scientific Method Made Me Better at Debugging Than I Expected

James Mateer — Fri, 08 May 2026 13:21:00 +0000

One of the first major bugs I hit as a junior developer looked simple at first.

My React frontend refused to talk to my Express backend. The terminal kept throwing errors, the browser showed failed requests, and after a few hours I was convinced I had fundamentally misunderstood how APIs worked.

At first, I did what I think a lot of beginners do: randomly changed things until something worked.

Bad idea.

Eventually I stopped, took a breath, and approached it the same way I used to approach problems in scientific environments: isolate variables and identify root causes.

I started using a simple “5 Whys” approach.

Problem: Frontend couldn’t connect to backend.

Why?
→ The request was failing.

Why?
→ The API endpoint returned a CORS error.

Why?
→ Express wasn’t configured to allow requests from the Vite frontend.

Why?
→ I never added CORS middleware.

Why?
→ I didn’t fully understand how frontend/backend communication actually worked yet.

That single debugging session changed how I think about development.

Instead of treating bugs like random disasters, I started treating them like experiments.

import express from "express";
import cors from "cors";

const app = express();

app.use(cors());

app.listen(3000, () => {
console.log("Server connected on port 3000");
});

The fix itself was tiny.

The lesson was not.

What surprised me most about software development is that professional developers don’t seem to know everything either. Before I started coding, I honestly thought experienced engineers just remembered entire frameworks and instantly knew solutions.

What I’ve discovered instead is that good developers:

Read documentation constantly
Break problems into smaller problems
Search intelligently
Debug methodically
Document what they learn

That last one surprised me most.

I used to think documentation was just corporate busywork. Now I understand it’s one of the most practical skills in development. Half the battle of solving future problems is leaving breadcrumbs for yourself.

I’ve started keeping notes on:

recurring errors
useful terminal commands
ESLint fixes
Git commands I always forget
project setup issues
debugging patterns

Something as simple as this has saved me hours:

git status
git add .
git commit -m "fix: resolved auth middleware issue"
git push origin main

Another thing that surprised me was how emotionally challenging development can be.

There were days where I felt genuinely underqualified. I’d spend hours on something that turned out to be a missing bracket or incorrect import path.

But I’m starting to realise that debugging is not proof that you’re failing.

Debugging is the work.

Every bug forces you to understand the system better than you did before.

One of the most encouraging moments I’ve had so far was seeing this message after hours of troubleshooting:

Server connected on port 3000

Tiny win. Massive confidence boost.

I’m still early in my journey, but I already think my previous experience outside tech gave me an advantage: learning how to think systematically under pressure.

Turns out that skill transfers surprisingly well into software development.

If you're career changing into dev, what's the biggest thing your old career taught you?

DEV Community: James Mateer

The Scientific Method Made Me Better at Debugging Than I Expected