Making the Request

  • I've been stuck on [problem] for [time] — I've tried [approaches]. Do you have 10 minutes?
    Full context before asking, with a time commitment
    "I've been stuck on this serialisation issue for 2 hours — I've tried JSON.stringify and a custom replacer. Do you have 10 minutes to look at it with me?"
  • I'm not sure if this is a gap in my knowledge or a bug — could you help me figure out which?
    Framing uncertainty honestly without self-deprecation
    "I'm not sure if this is a gap in my understanding of async/await or a genuine bug — could you help me figure out which?"
  • Would you be able to point me toward the right docs or codebase area?
    Asking for direction rather than a full explanation
    "I don't want to take too much of your time — would you be able to point me toward the right docs for the auth middleware?"
  • I want to make sure I'm not missing something obvious before I escalate.
    Framing the ask as due diligence
    "I want to make sure I'm not missing something obvious before I escalate this to the team — can I walk you through what I've found?"

Receiving and Following Up

  • That's really helpful — let me apply that and come back if I get stuck again.
    Closing the ask and showing respect for the person's time
    "That makes sense — let me apply that approach and I'll come back if I get stuck again."
  • I think I understand — let me repeat it back to make sure.
    Verifying understanding before acting
    "I think I understand the approach — let me repeat it back to make sure I've got it right."
  • I'll document this for the team in case others hit the same issue.
    Demonstrating that help creates team value, not just personal benefit
    "Thanks — I'll write this up in the wiki so anyone else hitting this issue can find the solution."

Phrases to Avoid

These common phrasings undermine your professionalism. Here are better alternatives.

Avoid "Can you fix this for me?"
Better "I've tried [X] and [Y] — could you help me understand where I'm going wrong?"

Asking someone to solve your problem delegates ownership. Asking for help understanding keeps the ownership with you.

Avoid "Sorry to bother you, but…"
Better "Quick question when you have a moment —"

"Sorry to bother you" is over-apologetic and signals low confidence. "Quick question when you have a moment" is direct and respectful.

Avoid "I have no idea what's happening."
Better "Here's what I've observed, here's what I've tried, and here's my current hypothesis."

Showing your work before asking for help demonstrates initiative and helps the other person jump straight to useful input.

Practice Exercises

Choose the most professional or correct phrase for each scenario.

Frequently Asked Questions

How long should you try to solve a problem alone before asking for help?

A common rule of thumb is 15–30 minutes of genuine effort. Beyond that, the cost to the team of your blocked time outweighs the cost of a brief interruption to a colleague.

What is "rubber duck debugging"?

Rubber duck debugging is explaining your problem step-by-step to an object (or a colleague acting as a silent listener). The act of articulating often reveals the answer before the other person needs to say anything.

What does "spike" mean in engineering?

A spike is a time-boxed investigation task used when you don't know enough to estimate real work. Its output is knowledge, not code.