DEV Community: Jacques Roux

How to Ask for Help at Work (Without Sounding Like You Don't Know Anything)

Jacques Roux — Wed, 18 Feb 2026 07:18:24 +0000

Every developer gets stuck. Juniors, seniors, staff engineers - everyone.

But asking for help? That feels risky. Especially in a second language.

You don't want to look incompetent. You don't want to waste someone's time. You don't want to be the person who "always asks questions."

So you stay quiet. You spend three hours on something a teammate could've explained in five minutes.

I see this pattern all the time. And it's a language problem more than a knowledge problem.

Let's talk about how to ask for help in a way that shows you're capable - not clueless.

Why the Way You Ask Matters

Compare these two messages:

❌ "I don't understand this. Can you help?"

✅ "I've been looking into the auth middleware and I'm stuck on how the token refresh works. I've checked the docs and traced through the code, but I can't figure out where the refresh token gets stored. Could you point me in the right direction?"

The first one sounds helpless. The second sounds like a professional who did their homework and hit a wall.

Same person. Same problem. Completely different impression.

The Formula

Good help requests in English follow a simple pattern:

1. Show what you've tried
2. Explain where you're stuck
3. Ask a specific question

That's it. This formula works in Slack messages, emails, meetings, and Stack Overflow posts. Everywhere.

Let's see it in action.

5 Situations Where You Need to Ask for Help

1. You're stuck on a bug and running out of ideas

You've been debugging for an hour. Nothing works. You need fresh eyes.

❌ "This doesn't work. Can someone help?"

❌ "I have a bug. Not sure what's wrong."

✅ "I've got a weird issue with the payment endpoint. It returns 200 in Postman but 403 from the frontend. I've checked CORS and the auth headers look correct. Anyone seen this before?"

✅ "I've been debugging the user sync job for about an hour. The job runs but the database doesn't update. I've verified the query works in isolation. I think it might be a transaction issue but I'm not sure where to look next."

What's happening: You proved you tried. You narrowed the problem down. Now your teammate can jump straight to helping instead of asking "well, what have you tried?"

2. You don't understand something in the codebase

The code is confusing. Maybe there's no documentation. Maybe the person who wrote it left the company.

❌ "I don't understand this code."

❌ "What does this do?"

✅ "I'm working on the notification feature and I came across the EventBus class. I can see it dispatches events, but I'm not clear on how listeners get registered. Is there a pattern I should follow?"

✅ "I'm reading through the caching layer and I'm not sure why we're using a decorator pattern here instead of middleware. Is there a technical reason, or is it just how it evolved?"

What's happening: You're not saying "I'm confused." You're saying "I understand this part, but not that part." It shows you're thinking, not just lost.

3. You need someone to review your approach before you build it

You have an idea. You think it's good. But you want a sanity check before you spend two days on it.

❌ "Is this a good idea?"

❌ "Can you tell me if I'm doing this right?"

✅ "I'm planning to handle the file upload with a presigned S3 URL instead of streaming through our API. My reasoning is it reduces server load and we don't need to process the files. Does that sound reasonable, or am I missing something?"

✅ "Before I go too far - I'm thinking of splitting the user service into two controllers. One for profile data, one for account settings. Wanted to get your take before I restructure things."

What's happening: You presented your thinking. You gave your reasoning. You're not asking someone to think for you - you're asking them to check your thinking.

4. You're new and need context that isn't documented

First week. New codebase. Nothing makes sense and the wiki was last updated in 2019.

❌ "Can someone explain how this project works?"

❌ "I'm lost. Where do I start?"

✅ "I'm getting up to speed on the billing module. I've gone through the README and the API docs. I'm still unclear on how the webhook flow connects to the subscription model. Is there someone who could walk me through that part?"

✅ "Hey, quick question about the deploy process. I followed the runbook but I'm not sure about the staging step - do we need manual approval, or does it auto-promote after tests pass?"

What's happening: You showed you did the self-service work first. You read the docs. You tried. Now you have a specific gap - and that's completely reasonable.

5. You need help but the person is busy or senior

You need help from someone important. The tech lead. The architect. Someone whose time feels precious.

❌ "Hey, do you have a minute?" (then dumping a huge problem on them)

❌ "Can I pick your brain about something?"

✅ "Hey, I have a question about the database migration strategy. It should take about 5 minutes. Is now a good time, or should I catch you later?"

✅ "Quick one when you have a moment - I want to confirm my understanding of the retry logic before I write the tests. No rush, happy to async over Slack if that's easier."

What's happening: You set expectations. You told them how much time you need. You gave them an easy way to say "not now" without feeling guilty. That's respect.

Phrases Worth Memorizing

These are starters you can use right away.

What you want to say	How to say it
"I don't get it"	"I'm not sure I follow the logic here"
"Help me"	"Could you point me in the right direction?"
"I have no idea"	"I've narrowed it down but I'm stuck on this part"
"Explain this to me"	"Could you walk me through how this works?"
"Am I doing it wrong?"	"Does this approach make sense to you?"
"I'm confused"	"I want to make sure I understand this correctly"
"I need help now"	"I'm blocked on this - could use a second pair of eyes"

The Three Magic Starters

When you're not sure how to begin, start with one of these:

"I've been looking into X and..." - Shows you already started working on it
"My understanding is... is that correct?" - Shows you have a theory, you just need confirmation
"I want to make sure I'm on the right track with..." - Shows you're being careful, not lazy

All three do the same thing: they prove you're bringing something to the conversation, not just showing up empty-handed.

When You Really Don't Know Anything (And That's OK)

Sometimes you genuinely have no idea. The technology is new. You've never seen this pattern before. You can't even form a specific question.

That's fine. Just be honest about it:

✅ "I'm completely new to Kubernetes. I've read the getting started guide but I'm struggling to connect the concepts. Could you recommend where I should focus first for our setup?"

✅ "I'll be honest - I haven't worked with WebSockets before. I'm going through the docs now. If I get stuck, would you mind being my go-to person for questions this sprint?"

Honesty isn't weakness. Pretending you understand when you don't - that's what causes real problems.

Quick Practice

Try rewriting these in your head (or in the comments):

"I don't understand the deployment pipeline."
"This API keeps breaking. Help?"
"Can you explain Docker to me?"
"I don't know how to write tests for this."

Vocabulary from This Article

Word	What it means	Example
incompetent	not having the skills to do a job	"Asking questions doesn't make you incompetent."
hit a wall	reach a point where you can't make progress	"I've been debugging all day and hit a wall."
sanity check	a quick review to make sure something is reasonable	"Can I get a sanity check on this approach?"
self-service	doing something yourself instead of asking others	"I did the self-service work first - read the docs, checked the wiki."
async	not happening at the same time (here: not real-time)	"Happy to discuss async over Slack."
blocked	unable to continue because something is in the way	"I'm blocked on the API integration."

Your Turn

What's the hardest part about asking for help at work?

Is it finding the right words? The fear of looking stupid? Not knowing who to ask?

Or maybe you've been on the other side - what makes you want to help someone when they ask?

Drop your thoughts in the comments. I read all of them.

I'm Jacques, an English teacher who works with developers. I help non-native speakers communicate with confidence in technical environments.

How to Disagree in English (Without Burning Bridges)

Jacques Roux — Wed, 11 Feb 2026 14:15:51 +0000

Someone proposes an approach in a meeting. You know it won't work. You've seen it fail before.

What do you say?

If you're a native English speaker, you probably do this without thinking. You soften it. You hedge. You wrap your "no" in something that sounds like a "maybe."

If English isn't your first language, this is a minefield. Say too little and your objection gets ignored. Say it too directly and you're "difficult to work with."

I work with developers on this a lot. It's one of the hardest things to get right.

Why Direct Disagreement Hits Different in English

In many languages and cultures, saying "No, that won't work" is perfectly fine. It's efficient. It's honest. Nobody takes it personally.

In English - particularly in a professional setting - it often lands like a slap.

It's not logical. But it's real. English-speaking work culture has this unwritten rule: disagree with the idea, but make the person feel respected while you do it.

That means your actual words matter less than how you frame them.

The Anatomy of a Good Disagreement

Most effective disagreements in English follow a pattern:

1. Acknowledge first
2. Introduce your concern
3. Offer an alternative

That's it. Three steps. Skip step one and you sound combative. Skip step three and you're just the person who shoots things down.

Let's look at how this plays out.

5 Situations Where You Need to Disagree

1. Someone suggests a bad technical approach

This happens in every sprint planning and architecture discussion.

❌ "That won't scale."

❌ "No, we should use Redis instead."

✅ "I see the logic there. My concern is how it handles load at scale - what if we looked at Redis as an alternative?"

✅ "That could work for the initial phase. I'm a bit worried about performance down the line though. Could we compare it with a caching layer?"

What's happening: You're not saying they're wrong. You're saying you have a concern. That's a very different thing.

2. A senior or lead says something you think is incorrect

This is the scary one. You don't want to embarrass them. You also don't want to stay quiet and let a bad decision happen.

❌ "Actually, that's not how that API works."

✅ "I might be wrong about this, but my understanding is that the API handles it differently. Want me to double-check?"

✅ "Interesting - I had a slightly different understanding of how that endpoint behaves. Could be worth verifying before we commit to the approach?"

What's happening: "I might be wrong" is doing heavy lifting here. You probably know you're right. But that phrase gives the other person room to correct course without losing face.

3. Someone's idea is over-engineered

We've all sat through a proposal where someone wants to build a rocket ship when you need a bicycle.

❌ "That's way over-engineered."

❌ "We don't need all that."

✅ "I like the direction. I'm wondering if we could get to the same result with something simpler - just to get an MVP out first?"

✅ "Makes sense as a long-term vision. For the current sprint, what's the minimum we could ship?"

What's happening: You're not attacking the idea. You're reframing the scope. "I like the direction" costs you nothing and buys a lot of goodwill.

4. Pushing back on an unrealistic deadline

Your PM says the feature needs to ship Friday. It's Wednesday. The feature isn't built yet.

❌ "That's impossible."

❌ "There's no way we can do that."

✅ "I want to make sure we deliver this properly. With the current scope, Friday is tight. Could we either trim the scope or adjust the timeline?"

✅ "I'm on board with the priority. My concern is quality if we rush it. What if we shipped the core feature Friday and the rest next week?"

What's happening: You're not saying no to the deadline. You're saying yes to the goal and proposing a realistic path. That's way easier for a PM to work with.

5. You disagree in a meeting but someone already moved on

The moment passed. Everybody nodded. But you're not convinced.

❌ (Staying silent and complaining on Slack later)

❌ "Wait, I don't agree with what we just decided."

✅ "Before we move on - can I come back to the caching approach for a second? I want to make sure we've thought through the invalidation side."

✅ "Sorry to circle back, but I had a thought on the earlier point about the database schema. Can I share it quickly?"

What's happening: "Before we move on" and "sorry to circle back" are signals. They tell people you're about to reopen something, which gives them a second to shift gears. Without that signal, it feels abrupt.

Phrases Worth Memorizing

These are the building blocks. Mix and match them.

What you want to say	How to say it
"You're wrong"	"I see it a bit differently"
"That's a bad idea"	"My concern with that approach is..."
"No"	"I'm not sure that's the best path because..."
"That'll never work"	"I think we might run into issues with..."
"I disagree"	"I hear you - and I want to offer a different perspective"
"That's over-engineered"	"Could we simplify this a bit?"
"That deadline is insane"	"I want to set realistic expectations on the timeline"

The Words That Make It Work

A few small words change everything:

"I think..." - Frames your disagreement as a perspective, not a verdict
"My concern is..." - You're raising a risk, not delivering a judgment
"What if we..." - Turns your objection into a suggestion
"I might be wrong, but..." - Gives the other person room to save face
"Could we..." - Collaborative. You're on the same team.

Notice the pattern? First person. Collaborative language. Questions instead of statements.

When to Drop the Softening

Same as with code reviews - there are times to be blunt:

Security risk: "This exposes user data. We need to fix this before it ships."
Legal/compliance issue: "We can't store that data without consent. Full stop."
Production is on fire: "The API is down. Let's skip the discussion and revert."

When something is urgent or dangerous, being direct isn't rude. It's responsible.

The Real Skill

Here's what I've noticed after working with developers for years: the best communicators on a team aren't the ones who avoid disagreement. They're the ones who disagree in a way that makes the other person feel heard.

That's not about being fake. It's about being strategic with your words.

You can be honest and diplomatic at the same time. In English, you kind of have to be.

Quick Practice

Try rewriting these in your head (or in the comments):

"No, microservices are the wrong choice here."
"This estimate is way too optimistic."
"Why would we use GraphQL for this?"
"That feature is a waste of time."

Vocabulary from This Article

Word	What it means	Example
minefield	a situation full of hidden dangers	"Salary negotiation is a minefield."
hedge	to avoid committing to a direct statement	"He hedged by saying 'maybe' instead of 'no'."
combative	ready to argue or fight	"His tone in the meeting was combative."
save face	to avoid embarrassment	"The phrasing lets them save face."
goodwill	friendly, positive feelings between people	"'I like the direction' buys goodwill."
blunt	very direct, without softening	"She was blunt about the deadline."

Your Turn

What's your go-to phrase when you disagree with someone at work?

Or - have you ever stayed quiet when you should have spoken up? What happened?

I'd love to hear your stories in the comments.

I'm Jacques, an English teacher who works with developers. I help non-native speakers communicate with confidence in technical environments.

How to Write Code Review Comments That Don't Sound Rude

Jacques Roux — Thu, 05 Feb 2026 07:30:35 +0000

I review a lot of code. And I see a lot of comments that make people defensive.

The person writing them doesn't mean to be rude. They're just being direct. But in English - especially written English - directness can feel harsh.

Here's the problem: you can't hear tone in text. There's no friendly smile. No "I'm just trying to help" body language. Just words on a screen.

Let's fix that.

The Difference One Word Makes

Look at these two comments:

❌ "This is wrong."

✅ "I think this might cause issues because..."

Same message. Completely different feeling.

The first one sounds like a judgment. The second sounds like a conversation.

5 Patterns That Sound Harsh (And What to Say Instead)

1. "You should..."

This sounds like a command. Like you're the boss.

❌ "You should use a constant here."

✅ "What do you think about using a constant here?"

✅ "Have you considered using a constant here?"

Why it works: Questions invite discussion. Commands shut it down.

2. "Why did you...?"

This sounds like an interrogation. Like you're suspicious.

❌ "Why did you use a for loop here?"

✅ "I'm curious about the for loop - was there a specific reason you chose it over map?"

✅ "Just wondering - is there an advantage to the for loop approach here?"

Why it works: "I'm curious" shows genuine interest, not judgment.

3. "This doesn't make sense."

This sounds like you're calling someone confused or stupid.

❌ "This logic doesn't make sense."

✅ "I'm having trouble following this logic - could you walk me through it?"

✅ "I might be missing something, but I'm not sure how this handles the edge case."

Why it works: You take responsibility for not understanding. It's humble.

4. "Just do X."

"Just" makes things sound trivial. Like the person should have known better.

❌ "Just add error handling."

✅ "It would be great to add some error handling here."

✅ "Could we add error handling for the null case?"

Why it works: Removes the dismissive tone. Shows you know it takes effort.

5. "This is inefficient / bad / wrong."

Labels feel personal. Even when you're talking about code.

❌ "This approach is inefficient."

✅ "I wonder if we could improve performance here by..."

✅ "This works, but I'm thinking we might hit performance issues at scale. What if we tried...?"

Why it works: You acknowledge the code works. Then you suggest improvement.

The Magic Phrases

Keep these in your back pocket:

Instead of...	Try...
"You need to..."	"Could we..."
"This is wrong"	"I think there might be an issue with..."
"Why didn't you..."	"I'm curious why..."
"Obviously..."	(Just delete this word)
"Just..."	(Delete this too)
"You forgot to..."	"It looks like we might need..."

When to Be Direct

Not every comment needs softening. Be direct when:

There's a clear bug: "This will throw a null pointer exception on line 42."
There's a security issue: "This exposes the API key. Let's move it to environment variables."
It's a simple fact: "This function is missing a return statement."

Facts don't need cushioning. Opinions do.

Cultural Note

In some cultures, being direct is respectful. It shows honesty.

In English professional culture, being indirect is often more respectful. It shows you value the other person's judgment.

Neither is right or wrong. But if you're writing in English to an international team, a little softness goes a long way.

Quick Practice

Rewrite these in your head (or in the comments):

"You should rename this variable."
"This function is too long."
"Why are you using callbacks instead of async/await?"

Vocabulary from This Article

Word	What it means	Example
harsh	too strong, unkind	"The feedback felt harsh."
defensive	protecting yourself from criticism	"He got defensive when I mentioned the bug."
dismissive	treating something as unimportant	"'Just fix it' sounds dismissive."
humble	not thinking you're better than others	"Starting with 'I might be wrong' is humble."
cushioning	making something softer or less direct	"Facts don't need cushioning."

Your Turn

What's the worst code review comment you've ever received?

Or the best one - the one that taught you something without making you feel bad?

Drop it in the comments. Let's learn from each other.

I'm Jacques, an English teacher who works with developers. I help non-native speakers communicate with confidence in technical environments.

10 Tech Terms You're Probably Mispronouncing

Jacques Roux — Wed, 28 Jan 2026 12:41:50 +0000

I teach English to developers.

One thing I see all the time: developers read technical words every day. But they never hear them spoken. Then the interview comes. You say a word out loud. And you think... "Wait, did I say that right?"

I said "koo-BER-nets" for two years before a colleague corrected me. It happens to everyone.

Here are 10 tech words that cause confusion. Let's fix them together.

1. Cache

People often say: "cash-ay" or "catch"
Correct: "cash" /kæʃ/

Yes, like money. It looks French, but in English we say "cash".

"Clear the cache" = "Clear the CASH"

2. SQL

Two ways - both are correct:

"S-Q-L" (say each letter)
"sequel" /ˈsiːkwəl/

Listen to your team. Use what they use. Stay consistent.

3. Nginx

People often say: "en-jinx" or spelling it out
Correct: "engine-X" /ˌendʒɪnˈeks/

Think: "engine" + "X". That's it.

4. Linux

People often say: "LINE-ux" (long 'i')
Correct: "LIN-ux" /ˈlɪnʊks/ (short 'i', like "in")

Linus Torvalds made it. He says "LIN-ux". So we say "LIN-ux".

5. GUI

Two ways - both are correct:

"G-U-I" (say each letter)
"gooey" /ˈɡuːi/

"Gooey" is common in everyday conversation.

6. Kubernetes

People often say: "koo-BER-nets"
Correct: "koo-ber-NET-eez" /ˌkuːbərˈnetiːz/

Four parts: KOO - ber - NET - eez
The stress is on NET.

Say it slowly at first. Then speed up.

7. OAuth

People often say: "ow-th" (one sound)
Correct: "OH-auth" /oʊˈɔːθ/

Two parts: "OH" + "auth" (like in "authentic")

Keep them separate. OH... auth.

8. Sudo

People often say: "soo-DOO"
Correct: "SOO-doh" /ˈsuːdoʊ/

From "superuser do". Sounds like "pseudo".

9. Char

People often say: "char" (like burned food)
Correct: "kar" /kɑːr/

Short for "character". The "ch" sounds like "k". Like "car".

10. Width

People often say: "wid-TH" (strong 'th' sound)
Correct: soft 'th', almost silent

Don't push the 'th'. Say it fast: "width". Smooth.

Same for height - the 'gh' is silent. Just say "hite".

Why Does This Matter?

Here's the truth: native speakers will usually understand you anyway.

But when YOU feel confident about how you say words, something changes. You stop hesitating. You speak more clearly. You focus on your ideas, not on your pronunciation.

This is not about being perfect. It's about feeling confident.

Quick Practice

Say these out loud, right now:

"I cleared the cache." (cash)
"We use Kubernetes in production." (koo-ber-NET-eez)
"Check the width." (soft 'th')

Vocabulary from This Article

Word	What it means	Example
pronounce	to say a word out loud	"How do you pronounce this?"
syllable	one sound-unit in a word	"'Water' has two syllables: wa-ter."
stress	saying one part louder	"The stress is on the second syllable."
hesitate	to stop or pause (not sure what to do)	"He hesitated before answering."
consistent	always the same way	"Be consistent - use the same pronunciation."

Your Turn

What word did you say wrong for years?

I'll go first: "Kubernetes" - I only learned the right way last year!

Drop yours in the comments. No judgment here.

I'm Jacques, an English teacher who works with developers. I help non-native speakers communicate with confidence.