menu
Good debugging starts with better questions

Good debugging starts with better questions

●7 ●18 ●41
calendar_today • schedule1 min read

When production breaks, the first question should not be: Who broke it?

A better starting point is:

"What changed in the system?"

That shifts the discussion toward evidence:

  • recent deployments
  • configuration changes
  • dependency behavior
  • traffic patterns
  • logs, metrics, and traces

For me, evidence-first debugging usually leads to faster diagnosis and better team behavior.

What question do you ask first when a production issue starts?

16 Comments

•

I like this point because sometimes the hardest part of debugging isn’t fixing the code, but asking the right questions to figure out what’s actually going wrong. It can save a lot of time chasing the wrong issue.

3 votes
•

@[Mehadi Hasan] yes, true, reducing the bug surface area to reduce chaos is also a best way to debug fast in pressure oriented environment

3
•

@[Mehadi Hasan] Exactly. The quality of the question often determines how quickly we reach the right evidence and avoid chasing symptoms.

1
•

@[Muhammad Talha Atif] Narrowing the failure surface quickly is especially important during high-pressure incidents because it gives the team a smaller, testable problem.

0
•

Good debugging really starts with asking the right questions instead of randomly changing code. I’ve wasted time chasing symptoms before, so taking a step back and understanding the actual problem makes a big difference.

2 votes
•

@[YurkoFlisk] Well said. Understanding the failure boundary first usually saves more time than making several speculative code changes.

0
•

I would first pin down the failing user operation, the first known bad time, and a nearby example that still works. For a network issue, “login fails on mobile data but works on Wi-Fi on the same device” gives “what changed?” a testable boundary. Then compare those paths and preserve the original error before altering settings. That also separates a system-wide incident from one device or network. AI-assisted reply; I work on Lisar Connect.

2 votes
•

@[lisarconnect] Great example. Establishing a failing case and a nearby working case creates a clear boundary and gives us evidence to test before changing the system.

0
•

“What changed between when everything was working and the latest release?”
That’s often my first question when something breaks. 😸

2 votes
•

@[nyaomaru] That is one of my first questions, too. Comparing the last known good state with the current state often points directly to the strongest leads.

1
•

Well, nowadays most of the time agents help us debug fast, they read traces faster than human, even their reasoning is good if they have really good context of codebase so what do you say traditional debugging skills are getting eradicated|?

3 votes
•

@[Muhammad Talha Atif] I see debugging skills evolving rather than disappearing. Agents can analyze traces and code very quickly, while engineers still need to provide context, validate hypotheses, and decide what actions are safe in production.

0
•

My first question is usually what changed in the last deploy window, and I check traces before logs because a trace shows which dependency call got slower. Under configuration changes I'd call out prompt and model version changes for teams running LLM features, since they often ship outside the deploy pipeline and get missed when people check recent releases first.

2 votes
•

@[nik-13] In AI-enabled systems, those changes should be part of the incident timeline just like code, configuration, and dependency changes. Thank you for your reply!

0
•

Oh I want to share my grievance on debugging from the perspective of a visual programmer. I am a game developer and my debugging as a solo dev covers everything from visual to backstage and doing them all alone sometimes is overwhelming! Some issues of the visual sit in backstage and i would have never known it if other issues would not have intertwined! In game development artificial intelligence has no place in the debugging topic! Man made games need man made solving skills! Sometimes issues have no solving even though we try all solutions under the sky! Sometimes you just have to start over!

3 votes
•

@[MTIndieDev] That is a great perspective from game development. Complex visual and backend interactions can make debugging very different, and sometimes rebuilding a component is the most practical engineering decision.

2
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

3.5 best practices on how to prevent debugging

Codeac.io - Dec 18, 2025

How to save time while debugging

Codeac.io - Dec 11, 2025

What part of debugging does AI still struggle with most?

sibasispadhi - Oct 18

Your Backup Data Knows More Than You Think. HYCU aiR Is Finally Asking It the Right Questions.

Tom Smithverified - May 14

Three Design-to-Code Rules Most Developers Ignore (That Will Make You a Better Engineer)

Joemetry - Sep 26
chevron_left
Sibasis Padhi
2.9k Points • 66 Badges
Arkansas, USA • sibasispadhi.com
6Posts
77Comments
12Connections
I work in Applied AI Enterprise Systems Architecture — building agentic AI-enabled, cloud-native sys... Show more

More From sibasispadhi

What part of debugging does AI still struggle with most?

AI can write code faster. Who protects production?

What usually breaks first in production: code, data, or dependencies?

Related Jobs

View all jobs →

Commenters (This Week)

1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!