What Senior Developers Actually Do: Leadership Beyond the Code

The Promotion That Changes Everything

Most engineers earn a Senior title by being the best individual contributor on the team. Then they show up the next day expecting the job to feel the same. It doesn't.

Senior engineering is still mostly coding. But the leverage — the thing that separates a good Senior from a great one — is what you do for the people around you.

Code Reviews That Actually Help

Bad code reviews are a list of style complaints. Good code reviews are a teaching moment wrapped in feedback.

When I review a pull request, I'm looking for three things in this order:

Correctness — does it do what it says? Are there edge cases that break it?
Design — is this the right abstraction? Will this be painful to change in six months?
Style — does it read cleanly? (And if you have a linter, most of this is automated anyway.)

The comment that changes how someone thinks is more valuable than ten nit comments that they'll forget by tomorrow.

// ❌ Unhelpful review comment
// This variable name is confusing

// ✅ Useful review comment
// Consider naming this `pendingInvoices` — it makes it clear these
// haven't been paid yet. The distinction matters when we add the
// `completedInvoices` query in the next sprint.

Leave the reasoning. Junior devs don't just want to know what to change — they want to understand why, so they make the right call next time without asking.

Mentorship Is Not Teaching

There's a difference between teaching someone and mentoring them. Teaching is transferring knowledge. Mentoring is helping someone build judgment.

The best thing I can do for a junior developer is not give them the answer — it's ask the right question.

"What have you tried so far?" "What do you think the tradeoff is between these two approaches?" "If this breaks in production at 2am, how would you debug it?"

This takes more time upfront. It pays back with a developer who can handle the next problem independently.

When to Jump In vs When to Let Them Struggle

Not all struggle is productive. There's a difference between a developer who's learning through a hard problem and one who's been stuck for two days and is quietly drowning.

Check in without taking over. "How's that going? Do you want to talk through it?" opens the door without removing the ownership from them.

If they're genuinely blocked: pair program. Don't just fix it and hand it back. Work through it together so they build the mental model, not just the solution.

Technical Communication

The higher you go, the more of your impact comes from writing and talking, not just coding.

Write things down. Decision records, architecture notes, post-mortems, onboarding docs. When you leave a project (and you will), the documentation is what stays.

When something goes wrong in production, the post-mortem isn't about blame — it's about the system. What made this failure possible? What can we change so the next engineer doesn't make the same mistake? A blameless post-mortem is one of the highest-leverage things a team can do.

Slow Down to Go Faster

The trap senior engineers fall into: because you can solve a problem quickly, you do it yourself instead of involving the team. You ship the feature. But nobody else learned anything, and you've made yourself the bottleneck.

The right question is not "what's the fastest way to get this done?" It's "what's the fastest way to get this done and leave the team better than I found it?"

Sometimes that means shipping it yourself. Sometimes it means spending twice as long pairing with someone who'll own this part of the codebase for the next two years.

That investment is the job.