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.

Senior means something different depending on who you ask.

For some it's years of experience. For others it's technical breadth - the ability to spin up a full stack project from scratch, own the architecture, make the infrastructure decisions. For others still it's simply a rung on the promotional ladder, assigned when the structure says it's time.

What follows is one perspective. Mine. It's not a framework, and it's not a checklist. It's an honest account of what the shift actually felt like from the inside, and the signals I almost missed because I was too busy looking for something more dramatic.

The Promotion I Almost Didn't Ask For

I didn't wake up one morning and decide I was ready to be a senior developer.

For a while I was feeling a confidence I wasn't showing on the outside. Not out of false modesty, but because I genuinely wasn't sure it was justified. I kept waiting for the moment it would be tested and found wanting.

Then I started noticing something. In code reviews, in technical discussions, there was a pattern. They weren't correcting me. They were highlighting what I'd written as examples of best practice. Pointing at my instincts as the benchmark.

Eventually the practical case made itself. I was already guiding and mentoring the team, but without any official capacity to do so. My opinions carried weight in practice, but not on paper. The title wasn't about validation. It was about utility. A tool to give my input the implicit authority it needed. And yes, it would look better on my CV.

So I asked. They agreed. Nothing really changed, because I already had.

You Were Already Doing It - You Just Didn't Have the Words

At some point I picked up Head First Design Patterns.

I expected to learn something new. Instead I found myself recognising things I was already doing.

Not all of them. But enough to give me pause. I'd been applying patterns without knowing they had names, solving problems in ways that had already been formalised decades earlier. It was one of the most validating moments of my career.

Some developers read the theory first and then spend time learning to recognise it in their own work. Others build up the habits first and discover the vocabulary later. Neither path is objectively better than the other. But both lead to the same place. A moment where something you've been doing instinctively becomes something you understand deliberately.

You Stopped Trying to Know Everything - And Started Knowing What Mattered

There is an impossible standard stalking most developers. The idea that a good developer should know every language, every framework, every paradigm. That being caught without an answer is a failure. That admitting uncertainty is a weakness.

I carried that for longer than I'd like to admit. And it was exhausting.

The shift came in stages. First, the uncomfortable acknowledgement that the industry is simply too big, and too fast-moving for any one person to keep up with all of it. Then the liberating realisation that followed. I didn't have to. I could pick a lane, go deep, and stop apologising for the edges of my knowledge.

I chose frontend. I built enough context around the rest of the stack to have informed conversations, to understand how my work fitted into the bigger picture, but I stopped pretending to be something I wasn't. A specialism isn't a limitation. It's a decision.

The shift was most noticeable in client calls. Early on, being asked something I didn't know felt like a trap. Over time I developed a phrase that changed how those moments landed: "let me take that away". Not a deflection. A commitment to find the answer and come back with something useful.

And that's when I discovered: the client didn't expect me to know about their specific integration that hadn't been mentioned in the agenda. My manager wasn't silently disappointed when I didn't have an immediate answer. Nobody was holding me to the standard I was holding myself.

The only person expecting me to know everything, was me.

There is a particular kind of hiring process that still hasn't figured this out - the kind that tests for encyclopaedic recall over genuine judgment. Or building solutions that you'll never face in practice. That's a frustration for another post.

The Signs Are Quiet

Seniority doesn't announce itself. There's no single moment where everything clicks and you think - right, that's it, I've done it. It's more subtle than that, because all of the changes happen internally.

They're shifts in how you think, not things you did or certificates you earned. And that makes them easy to miss, especially when you're still measuring yourself against an impossible standard that nobody else set for you.

If you're mid-level right now and none of this sounds familiar yet, that's fine. It's not a checklist to work through. But if you're reading this and nodding at things you recognise in yourself - you might be closer than you think.

The title, when I finally asked for it, turned out to be the least interesting part of the story. It was a practical tool. Something to make official what was already true.

In part two, I'll get into what senior thinking actually looks like in practice - in your code, your communication, and your team. But that's the external stuff. This was the part that happened first.

If any of this resonated, share your moment of recognition in the comments. Someone earlier in their journey might need to hear it. Join the discussion here.