Debugging for beginners: what to do before you ask for help or paste the error into AI

The fastest way to look junior is not a wrong answer. It is a Slack message that says “it doesn’t work” and a paste of 400 lines into a model two minutes after the first red text. I have sent both. I have also been the person who received them. The second job taught me why the first one wasted everyone’s time, including mine.

This is not a lecture about struggling alone. Asking is part of the job. Models are part of the job. The skill is what you do in the fifteen minutes before either one, so the human or the model has something they can actually use.

If you want the technical sequence I run on the bug itself — reproduce, read, diff, inputs — that lives in the debugging order I actually use. This piece is the social one: what to gather, what to write, what not to paste, and when to stop grinding.

The 15-minute rule I actually follow

I do not sit on a bug for two hours out of pride. I also do not ping the channel at minute two. I give myself a short, honest window: can I reproduce it, can I name the error in one sentence, can I say what I already tried. If I cannot do those three, I am not ready to ask. If I can, I am allowed to ask even if I feel stupid. Feeling stupid is not a signal. An empty note is a signal.

Fifteen minutes is not magic. On a production page I compress it. On a side project I sometimes give it thirty. The point is a timer, not a vibe. Without a timer I either give up instantly or disappear into the function I like.

What I do in that window is not “try random fixes.” I collect. Reproduction path. Full error. The last thing I changed. One log of the inputs. The sentence. That collection is the ask. If I skip it, I am asking someone else to collect it for me, and they will, and they will remember that I made them.

What to write down before you type @anyone

I keep a note, even a messy one. These are the fields I refuse to leave blank.

• What I expected to happen, in one sentence.
• What happened instead, in one sentence.
• The exact error text, not a paraphrase. Copy it.
• How to reproduce it, numbered, as if I will not be in the room.
• Where I am: branch, environment, URL, user, browser or runtime version.
• What I already tried, and what that did. “Restarted” is allowed. “Looked at it” is not.
• The last change that might be related. A commit hash is better than “I think I touched auth.”

If you cannot fill the reproduction field, say that explicitly. “I cannot reproduce locally; here is the request id and the time.” That is a real ask. “Sometimes it 500s” is a shrug.

I used to skip “what I expected” because it felt obvious. It is not obvious. Half the “bugs” I have been asked about were a misunderstanding of the spec. The other person cannot see the picture in your head. Write the picture down. If you are wrong about the spec, you find that out in one reply instead of a pairing session.

How to ask a human so they can help in five minutes

Lead with the sentence, not the autobiography. “Checkout returns 500 for a deleted Stripe customer on staging, branch fix-billing, started after deploy 14:10. I can reproduce with this curl. I already confirmed env keys and the webhook secret. I think we assume customer.id is always present.” Then the stack. Then the question: “Is this a known gap, or am I missing a Stripe event type?”

That message has a shape. Failure. Place. Time. Reproduction. What you ruled out. A hypothesis. A specific question. The senior can say “yes, we ignore deleted” or “no, look at the mapper” without first doing archaeology.

What I do not send: a screenshot of a terminal with the useful part cropped. A “hey” and then the error three messages later. A zoom invite with no context. A mention of six people. The error from a different environment than the one I am talking about. I have done all of these. They read as “please do my first fifteen minutes.”

If the person is in another timezone, the note has to stand alone. Pretend they will read it tomorrow. Include the request id. Include the link to the logs. Include the commit. Future-you will also read it tomorrow, when you have forgotten the thread.

Pairing is a different ask. “Can we look at this for ten minutes” is fine after the note exists. Pairing before the note is how you get a silent screen-share while they ask you to reproduce. That is not pairing. That is you doing step one with an audience.

What to give a model — and what I stopped giving it

I use models on bugs. I do not open with “why is this broken” and a whole repository. I give the same note I would give a human, plus the one function I suspect, plus the exact error. I say what I already killed. I ask for the next measurement, not a rewrite.

A prompt that has worked for me: “Here is the reproduction. Here is the error. Here is the handler. I already confirmed X and Y. I think Z. What would falsify Z? What one log line should I add?” That keeps the model in the investigation. If it starts proposing a new architecture, I ignore that part. Architectures are cheap. A request id is not.

What I stopped pasting: secrets, obviously, and also “almost secrets.” Session cookies. Internal hostnames that are not public. Customer emails. Dump files with production payloads. A .env because “it might be relevant.” If the model is a cloud box, treat the paste like a ticket the whole internet might see later. If it is a local model, still treat customer data like customer data. Local is not a legal theory.

I also stopped pasting generated lockfiles and 2,000-line components “for context.” Context is not volume. Context is the boundary: the incoming payload, the outgoing status, the one stack that is yours. Volume makes the model latch onto a style issue and miss the empty field.

The pastes that make the model sound sure and be wrong

A stack that starts in node_modules with no frame from your app. The model will invent a framework bug. Walk the stack until you own a line, then paste from there.

An error without the reproduction. The model will assume the happy path you described in prose. Prose is where we lie to ourselves. A curl or a test is harder to lie with.

A type error from TypeScript and a runtime error from last week, mixed in one prompt. The model will merge them into a single story. I have watched it do this and then watched a junior ship the story. One failure per prompt. If you have two, say they are two.

A “simplified” version of the code. Simplifying is how you delete the bug. If you must shorten, say what you cut. Prefer the real function and a fixture.

The model’s first explanation matching a blog post you have already read. That is a prior, not a diagnosis. Ask it what would be true in the logs if it were right. Then go look at the logs. If you skip that, you have used a search engine with extra confidence.

When asking is the correct first move

There are times I do not take the fifteen minutes. Access. I cannot see production logs. Permissions. I cannot reproduce because I do not have the role. Safety. I might delete data if I poke. A page that is already a rollback decision. In those cases the ask is: “I am blocked on X. Here is what I would do if I had Y.” That is a grown-up message. It is not laziness.

There is also “I have never seen this class of bug.” A memory corruption, a Kafka offset mystery, a TLS failure that only happens through one proxy. Say you are new to the class. Ask for the map, not the fix. “What does a healthy one look like?” is a better question than “can you fix it.” You will need the map next time.

If you have already taken the fifteen minutes twice and the world still will not shrink, ask. Repeating the same log line is not diligence. It is a loop. I have been that loop. The way out is another pair of eyes on the note, not a seventh console.log with a new name.

How I handle the reply so I do not waste the second favor

When someone answers, I try the thing they said before I argue. I report back with the result, not a new theory. “I added that log. The payload is empty on retry. Next I will check the queue serializer.” Close the loop. People help people who close the loop. People stop helping people who vanish and then show up with a different bug.

If the model answers, I do not merge its patch unread. I treat it like a junior who types fast. I run the reproduction. I ask whether the change matches the sentence. I revert if I cannot explain it. A fix I cannot explain is a bug I scheduled for next week.

I write down the actual cause in the ticket or the PR, in my words. Not the model’s paragraph. Not “fixed.” The sentence. That is how I get faster: the next similar failure has a note. Asking does not replace that. Asking is how you get the sentence when you cannot see it yet.

A template I still copy

When I am flustered I paste this into the note and fill the blanks.

Expected: …
Actual: …
Error: (paste)
Repro: 1. … 2. … 3. …
Where: env / branch / URL / request id
Last change: commit or config
Tried: A (result), B (result)
Hypothesis: …
Ask: one question

If I am talking to a model, I add: “Do not rewrite the module. Tell me what would falsify the hypothesis and what to measure.” If I am talking to a human, I add: “I can pair for ten minutes after 16:00” or “async is fine.” Constraints help. Open-ended “whenever” does not.

What I wish I had been told

Help is a resource with a face. Models are a resource with a privacy policy. Neither one owes you a skip of the first fifteen minutes. The people who look like they “just know” usually sent a better note, or they wrote the note for themselves and never needed to send it.

You will still ask too early sometimes. You will still paste too much. I still do. The correction is the same: stop, fill the template, send again. Nobody is keeping a scoreboard of your first draft. They are keeping a memory of whether working with you is cheap.

Do the order on the bug. Do the note before the ask. Keep secrets out of the paste. Close the loop when someone answers. That is the whole beginner skill that is not in the stack trace. The stack trace is necessary. It is not sufficient. The note is what turns a stack trace into a conversation someone can finish.