When something does not work, the easiest thing to blame is the code.

  • The button does not respond.
  • The page shows the wrong information.
  • The API returns an error.
  • The database contains something unexpected.

So you open the editor and start changing things. Sometimes that works. But professional problem-solving requires a different first question:

What problem are we actually trying to solve?

A symptom is not always the problem

Imagine a customer says:

"The report is broken."

You could immediately start looking at the report code.

  • But what does "broken" mean?
  • Is the report failing to load?
  • Is the data incorrect?
  • Is the data correct but displayed in the wrong format?
  • Did the customer's expectations change?
  • Did the underlying data change?
  • Is the report actually working but showing information that the customer does not understand?

Each possibility leads somewhere different.

The code may not be the problem at all.

Investigation comes before implementation

Professional developers spend time investigating.

That might mean:

  • Reading existing code
  • Checking logs
  • Reproducing an issue
  • Examining data
  • Reviewing recent changes
  • Checking requirements
  • Asking the person who reported the problem for more detail
  • Comparing expected behaviour with actual behaviour

None of this looks as exciting as writing new code.

But it is often where the real work happens.

Good questions save time

Asking questions is not a sign that you do not know enough.

Asking the right question is part of being good at the job.

Instead of asking:

"What should I do?"

you might ask:

"I can reproduce the issue when the customer has no active subscription. Should the report show an empty state in that situation, or should those customers be excluded?"

That question demonstrates investigation.

You have already looked at the problem.

You have identified a specific condition.

Now you are asking for a decision that actually matters.

Do not change what you do not understand

One of the easiest mistakes to make in an existing codebase is changing something because it looks wrong.

You see an unfamiliar function.

You do not understand why it exists.

You rewrite it.

Then something else breaks.

Existing systems contain history.

There may be reasons for decisions that are not immediately obvious.

Before changing something, try to understand:

  • What it does
  • Who uses it
  • What depends on it
  • Why it exists
  • What could be affected by changing it

You do not need to understand the entire system before making a change.

But you should understand enough to make the change responsibly.

This is where debugging becomes a professional skill

Debugging is not randomly changing lines until the error disappears.

It is a process of narrowing down uncertainty.

  • You form a hypothesis.
  • You test it.
  • You gather evidence.
  • You reject it or strengthen it.
  • Then you investigate the next possibility.

That mindset is useful far beyond software.

It teaches you how to work when you do not have the answer immediately.

The lighthouse is useful here too

A lighthouse does not tell you exactly how to navigate every wave.

  • It gives you a reference point.

Professional processes do something similar.

  • Requirements give you a reference point.
  • Tests give you a reference point.
  • Logs give you a reference point.
  • Code reviews give you a reference point.
  • Feedback from users gives you a reference point.

The goal is not to eliminate uncertainty. The goal is to learn how to navigate uncertainty without guessing blindly.

The better you become at understanding the problem, the less often you need to guess at the solution.

Tags: #lighthouse-series#debugging#problem-solving#requirements#software-development