Search for a command to run...
The signals that something has genuinely changed in how you think - and why the title was the least interesting part of the story.
No comments yet. Be the first to comment.
The shift to senior isn't something you engineer - it's something you notice. This series covers what that shift actually looks like, from the inside out.
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
My first job title was Graduate Developer. I held onto it longer than I should have. It was useful to begin with. When I made mistakes, well - I was only a graduate. When I didn’t know something, that
When I started learning React, I thought it would be easy. It was, mostly. I've worked across enough languages and frameworks over the years that I don't dread the switch. The engineering fundamentals
My husband wanted to clone me. Not literally. He's a hobbyist coder with a talent for AI, and was curious whether he could distil my engineering knowledge into skills and agents to code like me. The w
Always On Call I could never fully relax when I took leave. Even after a thorough handover, there was always the chance that something might come up that only I could solve. I don’t mean that as a boa
My feed was full of articles about the potential of generative AI. I felt a vague sense that I should be using it, but I had no idea where to start. I didn’t want to create code with it - I like writi
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.
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.
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.
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.
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.
