Your Coach Is Not Your Debugger

The call was already off the rails before I said a word.

A developer I was coaching - he'd just landed in Bangalore, three days in, excited about the tech scene - had his co-developer on the call with him. They were building a chatbot product on Bubble, integrating with a voice AI platform. Something wasn't working right. The chatbot would run fine on some tests and throw errors on others. Five tests total: two worked, two showed errors, one was unclear. Not consistent. Not reproducible on demand. Just broken in a way neither of them could pin down.

They'd been stuck on this for over a week.

So instead of showing up to our coaching session with a documented problem and one specific question, they showed up with an open laptop and started debugging live. On the call. In front of me.

I watched. I waited. I listened to them go back and forth: was it an input sanitization issue? A Bubble front-end problem? Something in the backend? Was the database returning null? The conversation circled. One developer would suggest something, the other would say he wasn't sure, they'd try something, wait for results, circle again.

At one point, the guy doing the backend work said it himself: "I'm not sure this is the right time to do this on the call."

Smart observation. Too late.

Twenty minutes in, I said it out loud: "We're wasting my time. We've been stuck on the same bug for over a week and we're going nowhere on this call."

That's the moment I want to talk about - because the real problem wasn't the bug.

The Bug Was Simple. The Process Was the Problem.

The bug turned out to be a getJSON function throwing a null error. When the database returned no data on a specific query type, the code tried to run getJSON on top of nothing, got a NoneType error, and broke. The fix, once they isolated it, was straightforward: check whether the data exists before calling the function. Add a null check. Done.

That's a fifteen-minute conversation at most. Write up what you're passing in, where the error occurs, what you've tried, and ask: "Is there a better pattern for handling null returns from this type of query?" You get an answer. You implement it. You move on.

Instead, we spent most of the session watching one developer type while the other speculated. I turned off my video at some point. There was nothing for me to contribute because I didn't have enough structured information to diagnose anything - and neither did they.

This is the live debugging trap. And it kills more coaching value than almost anything else I see in technical sessions.

Why Developers Default to This

Developers default to showing rather than telling. It's an instinct baked in by years of "can you take a look at this?" culture. Someone hops on your screen share, you walk them through what's happening, they spot something you missed. Works fine when you're two engineers on the same team with equal context and no clock running.

It does not work in a coaching context.

In a coaching session, one person has deep context on the problem and one person doesn't. The person without context - me - needs structured information before I can add any value. If you sit me down in front of a live debugging session without briefing me on the architecture, the data flow, what you've already tried, and what your hypothesis is, I'm not a coach. I'm a spectator.

Paying for a coaching session to have someone watch you debug is an expensive way to feel like you're making progress when you're not.

The other thing that happens is that the debugging session itself becomes the procrastination. The bug has been there for a week. Nobody has forced themselves to sit down and write out exactly what's happening, step by step. That documentation would probably surface the answer on its own - or at minimum, reveal what the actual question is. But that requires focused work. Getting on a call feels like doing something. It's not.

How to Come to a Technical Coaching Call

If you're the one being coached, here's the protocol that makes these sessions worth what you're paying for them.

Document the problem before you get on the call. Not "the chatbot sometimes throws errors." That's not a problem statement - that's a complaint. A real problem statement looks like: "When the database returns a null value on a specific query type, the getJSON function throws a NoneType error. This happens intermittently - occurred twice in five test runs. The error only appears on the Bubble front end, not in the backend logs. This suggests the issue is in how the front end handles the API response."

Write that out. The act of writing it will frequently show you where the problem is. If it doesn't, it gives your coach enough context to ask the right questions.

Document what you've tried. List every attempted fix with its result. "Tried input sanitization - did not resolve the error. Tried checking the database entry before the query - was unable to replicate the error in that test." This tells the coach what paths are already closed, which saves you from burning fifteen minutes on suggestions you've ruled out.

Form a hypothesis. Don't just document the problem - take a position on what you think is causing it. Even if you're wrong, having a hypothesis structures the conversation. Your coach can confirm your thinking, redirect it, or give you a faster path to ruling it out. In the session I described, the developers were circling between "is it Bubble?" and "is it the backend?" without committing to either. Pick one. Make a case for it. Let your coach poke holes in it.

Write one specific question. Not "can you help us figure out what's wrong?" That's open-ended enough to burn an entire session. A specific question sounds like: "Given that getJSON is throwing a NoneType error only on intermittent database returns, is there a better pattern for handling this in a Bubble and API integration than what we're using?" Now your coach can answer that. Now the session has a destination.

If you do all four of these things before you get on the call, I'd estimate you solve 40% of your problems before the session even starts. The rest you solve faster because you're not building context from scratch in front of someone whose time you're paying for.

The Coach's Responsibility

This isn't only on the client. Coaches enable this dynamic when they don't set the agenda upfront.

I've run enough of these sessions to know the tells. Someone shows up and says "so let me just show you what's happening" - that's the moment you have to interrupt and say: before we look at anything, tell me the problem in one sentence. Tell me what you've already tried. Tell me what your hypothesis is. Tell me what you specifically need from me today.

If they can't answer those questions, the call isn't ready to happen. Send them away with a simple template to fill out and reschedule. That's not harsh - that's respecting both your time and theirs. Letting a session drift into unstructured debugging helps nobody.

When the context is in place, the coach's job is diagnosis, not execution. I'm not there to type code. I'm there to ask the question that unsticks the thinking. "Is that a database query generating the error?" "Are you calling create assistant before generate chatbot, or after?" Those are diagnostic questions. They take thirty seconds to ask and can save two hours of wrong-direction debugging.

But you can only ask the right diagnostic question if you know enough about the problem to know which questions matter. That requires the upfront documentation. Without it, you're guessing - and watching someone else debug in real time gives you almost none of the information you need to guess well.

The other thing coaches need to be willing to do is say it directly when a call has gone off track. I said it at the twenty-minute mark: we're wasting time. I should have said it at the five-minute mark when it became clear we were heading into a live debugging session. Don't let politeness run down the clock on a session that isn't working. The client isn't well-served by you staying quiet while their time burns.

The Real Cost of an Unstructured Technical Session

Let's do the time math on what happened in this call.

They'd been stuck on the same bug for over a week. Two developers, multiple hours each, running in circles on something with a conceptually simple fix - add a null check before calling a function that can't handle null input. The actual solution is maybe ten lines of code once you know what you're solving for.

Then they get on a coaching session, arrive without a clear question, and debug live for the better part of the session. Now you've got two developers' time plus my time, all burning on something that didn't require any of it to be unstructured.

This is the real cost of the live debugging trap. It's not just the session. It's the week of spinning before the session - all that time without a framework - multiplied by the missed opportunity of what a well-run coaching session would have unlocked.

A well-run version of that call would have looked like this: five minutes of context on the problem, five minutes of diagnostic questions from me, ten minutes arriving at the solution or a clear path to it, and the remaining time focused on something higher-leverage - architecture decisions, what to build next, how to structure the technical team. The stuff that moves the product forward instead of just keeping the lights on.

Instead, we spent the session watching a debugger run.

What Unlocked the Problem

Once they stopped showing me the live environment and started talking me through the data flow - what they were passing into the function, where the error appeared, what the function expected to receive - it took about ninety seconds to get to the answer.

They were calling a function that parses structured data from an API response. When the database had no entry to return, the API sent back nothing. The function didn't have a null check. So when it got nothing, it broke. The fix: verify the data exists before passing it to the function.

That's the entirety of a week's worth of confusion. Two sentences.

This is almost always how it goes with technical bugs that feel intractable after a week of poking at them. They're rarely conceptually complex. They're hard because you've been too close to them. A fresh set of eyes with the right information cuts through in minutes. But "fresh set of eyes" requires that you've organized the information first. You can't hand someone a mess and ask them to see what you can't see.

Your coach or advisor's most valuable contribution isn't knowing more than you - it's having enough distance from the problem to ask the obvious question you've stopped seeing. But they can only do that if you've given them a clean picture before the session starts.

The Protocol

Here's what I'd install in any technical coaching engagement, whether you're the coach or the person being coached.

Before the call - client's job:

• Write a one-paragraph problem statement: what's happening, when it happens, where in the stack it appears
• List the last three things you tried and what each one produced
• State your current hypothesis about root cause, even if you're not confident in it
• Write one specific question that, if answered, would unblock you
• Send this to your coach at least an hour before the session

Opening the call - coach's job:

• Confirm you've read the brief
• Restate the specific question to align on what you're solving
• Ask two or three diagnostic questions to fill any gaps
• Don't let anyone share their screen until you have a clear picture of the problem

Running the call - both sides:

• The coach directs the diagnostic: asks questions, proposes hypotheses, challenges assumptions
• The client answers and executes: they're the one with context and access
• If you hit something that requires actual debugging time, schedule a follow-up rather than burning the rest of the session on it
• End with a clear next action and a clear question to verify whether it worked

This isn't complicated. It's a discipline most technical teams never install because nobody's ever called out the cost of not having it.

The One Question That Changes Every Session

If you take nothing else from this, take this question. Ask it before every technical coaching session, whether you're giving or receiving the coaching:

What is the one specific question we're trying to answer today?

If you can't answer that in one sentence, the call isn't ready. Reschedule, do the prep, come back with the answer. A session without a specific question will drift - into a tour of the current state of the product, into a venting session, into a live debugging session where your coach sits there watching you type and neither of you walks away with anything useful.

The question takes ten minutes to write. The writing forces you to think. The thinking frequently solves the problem before you ever get on the call. And when it doesn't, it turns a two-hour ramble into a thirty-minute answer.

That's the trade. It's not a hard one to make.

For more on how to run high-value conversations without letting them drift - whether you're coaching someone, running a discovery call, or advising a client - the Discovery Call Framework covers a lot of the underlying principles that apply across all of these contexts. The same discipline that makes a sales call productive is the same discipline that makes a technical advisory session worth the time.

And if you're the coach side of this equation: be honest with yourself about how often your sessions drift into unstructured problem-solving when they should be focused diagnostic conversations. The protocol above isn't just for the clients. It's for you too.

Your time is either spent on high-leverage diagnosis and direction, or it's spent watching someone else type. Only one of those is why people hire you.