The Signs That Someone Is Already Thinking Like a Senior Developer

The internal shift is the part nobody can see. This post is about the part they can.

I noticed most of these signals in myself first. But it wasn't until I watched for them in someone else that I was certain of the change. Seeing senior thinking in another person teaches you more than you'd learn alone.

This is what it looks like. In the code, in the decisions, in the conversations. Whether you're wondering if it's happening to you or watching for it in someone else.

Thinking Beyond the Ticket

There's nothing wrong with picking up a ticket, building the thing, and moving on. In a lot of organisations that's exactly what's needed, and a lot of developers are happy there.

I was working through designs and noticed a widget that looked identical to something I knew my colleague was building. I flagged it. We created a shared component instead of two separate ones. It saved time, ensured visual consistency, and meant any future changes only needed to happen in one place.

I've also been on the other side of that moment. Watching a developer that I was mentoring catch the same kind of overlap before anyone else did.

It starts with the habit of asking: who else is affected by the decisions we're making right now?

Choosing Standards Over Complexity

It's easy to mistake complexity for competence. The deeper you go into your stack, the more exciting tools you discover. The temptation to use them everywhere is hard to resist. I'm guilty of it. Nested ternary operators, chained function calls, complex logic squeezed into a single line. I thought I was being clever, until my poor colleague had to review my code.

Standards-compliant code isn't a compromise. It's a form of empathy. When you stay close to established conventions, you're making a promise to everyone who comes after you: this will behave the way you expect. You won't need to reverse engineer my thinking. You can just read it, change it, and trust it won't fall apart.

Not Every Problem Has a Technical Solution

Sometimes the most impactful thing you can do is write a document.

We had a problem with branch management. The instinct might be to reach for a technical enforcement mechanism. Commit hooks. Automated checks. Rules baked into the pipeline. Those things enforce behaviour. They don't change it. A developer who understands why a process exists will handle the situation the process didn't anticipate.

We created documentation explaining the what and the why of the new process, ran a training session, and asked for feedback as it bedded in. Before long, it was as though we'd always been doing it.

Documentation that seeks to guide rather than dictate is far more valuable than any technical solution.

Opening Dialogues

I almost never say no to a client.

With a flat no you halt the conversation. You position yourself as an obstacle, that may get overridden anyway. And you miss the point, because what the client needs isn't always what they've asked for. Understanding that gap, and finding a way to meet the underlying need, is where the real value is.

So instead of no, I prefer "yes, but."

"Yes, we can do that, but it will push the release date back. Do you want me to flag that with the project manager?"

"Yes, we can do that, but it uses non-standard functionality which may not be maintainable long term. How about this alternative?"

"Yes, we can include that, but it may have a performance impact. Here's another alternative worth considering."

Each of those responses does the same thing: it keeps the relationship intact, it's honest about the constraints, and it offers a path forward. The client feels heard rather than blocked. And you've protected the work without ever having to say no.

It's a form of technical diplomacy. And it does take practice. Early on, the instinct is either to say yes to everything to avoid conflict, or no to anything that feels out of scope. The middle ground, where you meet the client's real need while being honest about the cost, is where senior judgment lives.

Ideally this conversation belongs to your project manager. But senior developers know how to handle it when it doesn't.

Letting Go

You could build a whole product from start to finish. But should you?

There are a lot of things I can do outside my core specialisation with a reasonable degree of competence, but competence doesn't build great projects. I can write acceptance criteria if needed, but I will never do it as well as the person with the deep knowledge of who and what the product is for. I would take so much longer to build a robust and scalable backend than the developer who has specialised in it for years.

Knowing who is best for the job, and stepping back to let them do it, is one of the least visible and most valuable things a senior developer does.

Leave It Better Than You Found It

Leave it better than you found it. The codebase, the process, the team. Not dramatically better. Not perfect. Just a little better, consistently, over time.

It's an underrated form of seniority. It doesn't show up on a CV particularly well. It doesn't always get noticed in a performance review. But the developers who operate this way are the ones teams are built around.

It doesn't happen overnight. It accumulates, the same way the recognition does. Small decisions, repeated consistently, that have a lasting impact on the code and the people in it.

If you recognise this in yourself, or in someone you're working with - share it. Someone earlier in their journey might need to hear it.