You already have the job or the internship. You're on the team. You're in the meetings. You're in the Slack channels.
And the thing that's going to hold you back has nothing to do with your code.
Someone you work with says "hey, could we do X?" and you say "yeah, of course." Feels confident. Feels like you just proved you've got it.
But you gave an answer that contains zero information. No cost. No timeline. No tradeoff. No indication of whether you even understood the question. And now you're either about to disappear for two weeks and come back with something nobody asked for, or pull an all-nighter for something that was just a question, not a request.
Both started with "of course."
Why I'm Writing This
I'm a non-technical founder. I don't write the code. But I build alongside my team every day. I set direction, I think through problems, I get my hands dirty in the product.
The devs who accelerated fastest on my team were never the ones who said yes the fastest. They were the ones who slowed down long enough to make sure we were talking about the same thing. The ones who said "of course" to everything burned out, shipped the wrong thing, and lost trust. Not because they weren't talented, but because they never gave anyone a chance to actually collaborate with them.
A Yell That Sounds Like a Whisper
Not everything a founder or lead says carries the same weight. But it doesn't always feel that way from your side. When the person steering the ship says "hey what if we tried this," it can land like a mandate even when it's just a thought.
So before you go heads-down for 48 hours on something mentioned in a 5-minute conversation, ask:
"Is this urgent or is this something we should plan for?"
"Are you asking me to build this or are you asking if it's possible?"
"Where does this sit relative to what I'm working on right now?"
And yeah, sometimes the answer is going to be "yes, it's urgent, do it right now, and please don't ask me any more questions." That happens. But even that is better than the silence you were working inside of before. That five-second question just saved you from building the wrong thing at the wrong pace.
"Of Course" Erodes Trust Faster Than Bad Code
You say "of course." You go dark. A week passes. Someone checks in. The thing isn't done, or it's half-done, or it's not what was asked for. The people around you start second-guessing every "of course" that comes after it.
That didn't happen because you're a bad developer. It happened because you skipped making sure everyone was on the same page before you started building.
If you're stuck, say so. If it's more complex than expected, flag it. If the original ask doesn't make sense technically, speak up. "That won't work because of X, but here's what would" is one of the most valuable sentences in engineering.
If you can build but you can't communicate what you're building, why you built it that way, and what could go wrong, you are operating at half your potential.
What the Best Devs Actually Sound Like
"I want to make sure I understand what you're looking for before I start."
"That's a cool idea. Here's what it would take and here's what we'd need to deprioritize."
"I can do a rough version by Friday to see if it's even the right direction. Want that instead of the full build?"
"Honestly, I'm not sure yet. Let me look into it and come back to you tomorrow."
None of those sound weak. They sound like someone you'd hand the keys to. Someone who respects the problem enough to not pretend it's already solved.
The Line
The most dangerous dev says "of course."
The most valuable dev says "let me make sure I understand the problem first."
You already got the job. Now show them why they were right.