I stared at the diff for probably twenty minutes.
It was three lines. Three simple lines that would fix a performance issue we'd been dealing with for weeks. The kind of fix that makes you feel stupid for not seeing it sooner.
But I didn't push it.
See, the previous developer who wrote this code? They were senior. Like, really senior. The kind of person whose GitHub profile makes you question your career choices. And here I was, barely a year into this job, about to "fix" their work.
What if I was wrong? What if there was some edge case I wasn't seeing? What if this was actually intentional and I just didn't understand the architecture well enough?
So I sat there. Overthinking. Spiraling.
Finally, I did what I should've done from the start—I asked. Dropped a message in Slack with my findings, explained my proposed fix, asked if I was missing something.
The response came back in minutes: "Oh yeah, that's a known issue. Nice catch. Ship it."
That's it. No judgment. No "how did you not know this." Just acknowledgment and a green light.
Here's what I learned that day: asking questions isn't admitting weakness. It's how good code gets written. That senior developer? They weren't perfect. They were just human, working with the information they had at the time.
The best developers I've worked with since then all share one trait—they ask questions constantly. They challenge assumptions. They're not afraid to say "I don't understand this, can you explain?"
That three-line commit taught me more than any tutorial ever could. Not about code, but about being part of a team.
Sometimes the bravest thing you can do is hit send on that question you're afraid makes you look dumb.
Usually, it just makes you look smart.
Top comments (0)