Say the nice thing

You notice things.

You notice that someone took a slightly more difficult path because it left the codebase cleaner for whoever came along next. You notice the person who renamed the confusing variable while they were fixing something completely unrelated. The developer who added the test for the weird edge case nobody had thought about yet. The person who stopped halfway through implementing something and said, “Hang on, I think there’s a simpler way to do this.”

You notice the PR that is unusually easy to review because someone bothered to explain why, not just what they changed.

You notice when somebody cares.

And then, weirdly, you often say absolutely nothing.

I’ve been thinking about this lately because software development has an enormous amount of feedback built into it, but surprisingly little of it is praise.

Our tools are basically designed to tell us what’s wrong.

The build failed. The test failed. The dependency is vulnerable. The linter is unhappy. The accessibility check found something. The code review has seven comments. Production is throwing errors. Copilot thinks you've introduced a security problem. Someone has found an edge case.

Red everywhere.

When everything works?

Green tick.

Move on.

Humans aren't much better.

Code review naturally draws our attention to the things we think should change. We leave comments on the questionable implementation and scroll straight past the thoughtful one. We point out the missing error handling but say nothing about the really nice abstraction three lines above it.

That makes sense. The job is partly to find problems.

But it creates a fairly distorted picture of what people are contributing.

I know there have been plenty of times when I’ve looked through somebody’s code and thought, that’s clever. Or that's much cleaner than what was here before. Or I wouldn't have thought to do it that way.

And then I've kept scrolling.

Which is ridiculous when you think about it.

Because typing:

“Nice solution.”

takes approximately four seconds.

Saying:

“I really like how you've done this. It's much easier to understand.”

might take eight.

And yet the person on the other side of that PR might remember it for years.

Especially the people who are still finding their feet.

Software has a peculiar way of making perfectly competent people feel incompetent. There is always another framework you don't know, another person who understands the infrastructure better than you do, another acronym everyone else apparently learned while you were out getting coffee.

Even very experienced developers can spend an afternoon staring at something thinking, I have absolutely no idea what I'm doing.

Then someone whose opinion they respect says, “This is really good work.”

And suddenly the internal calibration shifts a little.

Oh.

Maybe I do know what I'm doing.

I've realised, too, that compliments don't have to come from the most experienced person in the room to matter.

You don't need to be the world's authority on React to recognise beautifully structured React code. You don't need twenty years of security experience to appreciate that somebody has carefully thought through permissions. You don't need to be someone's manager to notice that they patiently helped another developer understand something without making them feel stupid.

In fact, some of the nicest things worth acknowledging aren't particularly technical.

“I noticed how much time you spent helping them with that.”

“You explained that really well.”

“Thanks for challenging that assumption.”

“That PR description made this incredibly easy to review.”

“You always leave things a little better than you found them.”

“I trust your judgement on this.”

That last one can mean a lot.

There are people I've worked with whose habits have quietly changed the way I work.

People who made me more careful.

People who made me question assumptions instead of blindly accepting them.

People who showed me that accessibility isn't something you check at the end.

People who taught me that boring code can be excellent code.

People whose documentation saved me hours.

People whose patience made it safe to ask a stupid question.

People whose standards made mine higher simply because I worked alongside them.

I'm not sure I've told all of them.

That's the bit that bothers me.

We tend to assume people know when they're good at something. Or that they know we respect them. Or that somebody else has probably told them.

Maybe they do.

Maybe nobody has.

And there’s another reason I think this matters in software.

The things we praise become part of the culture.

If the only thing we celebrate is shipping quickly, people learn to ship quickly.

But if we notice the person who removed unnecessary complexity, we're saying simplicity matters.

If we praise someone for raising an uncomfortable concern before release, we're saying speaking up matters.

If we thank the developer who wrote excellent documentation, we're saying the work after the code matters.

If we recognise someone for helping a junior developer instead of finishing their own ticket ten minutes earlier, we're saying people matter.

Tiny comments quietly describe the kind of team we want to be.

So I've been trying to get better at not letting the nice thought disappear.

When I'm reviewing a PR and something makes me think that's good, I try to actually write it.

When somebody handles a difficult problem thoughtfully, tell them.

When someone teaches you something, tell them.

When you steal one of their techniques six months later because it was genuinely better than yours, definitely tell them.

It doesn't need to become a ceremony. Nobody needs a Teams meeting called Developer Appreciation Alignment Session. Please, God, no.

Just say the nice thing when you notice it.

Because we're already very good at telling each other when something could be better.

We should probably get equally good at telling each other when something already is.