The idea of a “good developer” used to feel simple. Solid technical skills. Clean code. Good velocity. Maybe a GitHub profile that showed steady contributions. If you asked me five years ago, I might have rattled off a checklist. JavaScript fluency, debugging prowess, familiarity with modern frameworks, and maybe an ability to explain things clearly.

But lately, I’ve found myself rethinking all of that.

Not because those things aren’t valuable, they are. But because they’re not the whole picture. And sometimes, they’re not even the part that matters most.

The Moment That Made Me Stop

It started during a recent promotion review.

We had a developer, let’s call her Tanya, who didn’t speak up much in standups. Her code was rarely flashy. She didn’t volunteer for the big-bang projects or write detailed proposals in Slack. But she quietly picked up broken tickets others had dropped. She chased down edge-case bugs that had been open for months. She mentored a junior dev in DMs, helping them get through their first sprint. And when a tricky production issue hit at 2AM, it was Tanya who found the root cause, not because she was on-call, but because she was already looking into it.

The message she sent was simple: “Already poking at it. Looks like a bad token refresh. I’ll post a patch in a few.” Calm. Clear. No drama. Just action.

On paper? Tanya wasn’t “leading.” She wasn’t driving architecture. She wasn’t the loudest or fastest or most visible.

She also had her rough edges. Sometimes over-apologizing when things went wrong, or underestimating how much others relied on her. She wasn’t gunning for visibility or a title.

Tanya wasn’t even on the initial list for promotion. A louder, flashier dev had been. But when we started asking who people turned to, who fixed what no one else saw, who calmed things down when the thread was unraveling, it kept coming back to her.

That was the moment I realized: we weren’t just overlooking impact. We were incentivizing the wrong things.

What We Measure vs. What Matters

In engineering, it’s easy to overvalue the visible. Green PRs. Initiative. Presentations. Tech talk buzzwords.

But some of the most impactful developers I’ve worked with weren’t loud. They didn’t seek credit. They weren’t writing 10x code. Their impact showed up in three ways:

1. Team Stability

• Pulled others out of confusion without making them feel small
• Quietly updated the internal docs no one else touched
• Followed through on unglamorous tasks without drama

2. Risk Mitigation

• Flagged the subtle bug that would have haunted us for weeks
• Took accountability when things went wrong
• Asked clarifying questions others were afraid to

3. Multiplier Effect

• Mentored junior devs without being asked
• Gave thoughtful PR reviews that helped others grow
• Set a calm tone during incidents that kept others grounded

None of that shows up in Jira velocity.

None of it fits cleanly into a 15-minute standup.

But it holds the team together.

And here’s the uncomfortable part: we don’t just undervalue this work by accident. We’ve designed systems that ignore it. Promotion rubrics prioritize scope and architecture. OKRs reward features, not friction removed. Bonus criteria rarely ask, “Who kept the team from burning out?”

If the only thing we reward is output, we shouldn’t be surprised when glue work disappears.

So What Does a “Good Developer” Look Like?

I don’t think there’s one answer. But I do think we should start asking better questions:

• Are they dependable in ways that aren’t always glamorous?
• Do they make others better?
• Do they reduce risk, even if that means writing fewer lines of code?
• Are they kind? Curious? Safe to learn around?
• Do they take initiative, or wait to be told?
• Do they seek out growth, or avoid discomfort?
• Do they own their mistakes and help fix them?
• Are they a multiplier, someone who makes the people around them more effective?

And yes, visible initiative often does correlate with impact. There are developers who lift whole teams through energy, ideas, and clarity of vision. We should celebrate them too.

But not everyone operates in the spotlight. Some do their best work offstage, making the entire production run smoother.

A good developer doesn’t just write good code. They leave the team better than they found it.

This isn’t about lowering the bar. It’s about recognizing a broader range of excellence, and acknowledging that if we only reward what’s loud, we’ll build teams that shout but don’t necessarily succeed.

Making the Invisible Visible

If we want to reward these kinds of contributions, we need to name them. Track them. Celebrate them.

Here are a few ways:

• Add a “glue work” section to performance reviews: Encourage team leads to call out behind-the-scenes support, internal tools, doc upkeep, and mentoring.
• Use prompts in 1:1s: Ask “What’s something you helped with this week that wasn’t on your task list?” or “Who did you make better this sprint?”
• Include peer feedback in review cycles, often, teammates see the invisible lifts leaders miss.
• Update promotion criteria to include cultural stewardship, mentorship impact, and cross-team collaboration.

What Managers Can Do Today

Here are a few simple ways to start shifting what you see and reward:

• In your next 1:1, ask about the work your report did that no one else saw.
• Track who new team members go to when they’re stuck. That person is carrying more weight than you may realize.
• In sprint retros, name contributions that weren’t about tickets. Like diffusing tension, flagging risks, or mentoring quietly.
• In promotion packets, include a “multiplier impact” section and ask peers to contribute examples.

And if you’re skeptical? Try it once. Pick one developer whose work is easy to miss but consistently stabilizing. Start observing more closely. You might be surprised how much you’ve been overlooking.

If You’re in Charge, Ask Yourself

• Who on your team is over-celebrated, and why?
• Who’s quietly enabling your top performers to shine?
• When was the last time you promoted someone not for what they shipped, but for how they made others better?
• Would Tanya thrive under your leadership? Or would you miss her entirely?

Author’s Note

This reflection came after reviewing bonus allocations and realizing I was using old heuristics to evaluate new dynamics. I started with a checklist. Tanya reminded me to throw it out.

This isn’t just a story. It’s a challenge to re-examine what we reward, and who we’re at risk of missing.