It’s not enough to just pay attention. Turning knowledge into action is where the journey to senior begins. Noticing the change in risk that biometric login posed didn’t have an impact until I flagged it. This post is about what to do with what you’ve been gathering.
Look Beyond Your Team
Most developers understand their own responsibilities. Senior developers understand everyone else’s too. Not to do their job for them, but to understand how the work connects.
A bug was reported. Investigation revealed that a value in the API response wasn’t what the front end was expecting. A team member picked up the task, added some defensive code, and submitted a pull request. Job done. In this example, the bug was actually a mapping error in the middleware which took less time to fix. A few minutes of conversation with another team could have saved hours of unnecessary work.
Sometimes it isn’t as simple as that. There might be a constraint in a third-party platform, or decisions made earlier in the project that can’t easily be changed. Then the question becomes “what’s the best compromise that minimises work and risk for both teams?” But someone needs to ask the question in the first place.
The habit to develop is simple: when something is unclear or doesn’t look right, raise it. Not every flag will turn into something significant. But the ones that do will save far more time than the ones that don’t.
Make the Invisible Visible
First, we took knowledge from outside our team, now we give back. To other teams, other projects, and your future self.
We had a problem with a feature in a third-party package. The fix in the immediate project was straightforward. But I also reported the issue in another project using the same feature, advised a third project not to use it, and updated our best practice documentation with the issue. The bug was fixed once. The knowledge was fixed permanently.
It’s not just about the code. Share with the backend team how the data is going to be used to help inform their decisions. Inform the project manager if an architecture decision adds technical debt to the project. Flag to the technical lead when a dependency is approaching end of life. Document decisions and why they were made so you’re not doing the work twice, or trying to understand a decision made months ago.
That last part is what many developers skip. Not out of carelessness, but because the ticket is closed and the next one is already waiting. Investing in institutional knowledge is invisible work. It doesn’t show up in a sprint review. But it compounds, and teams that do it consistently are far more effective than teams that don’t.
Pass It On
Many senior developers have huge depths of knowledge, but that knowledge serves no one if it isn’t shared. When you’re the only one who understands a particular system or technology, there’s no one to help you, no one to learn from, and you risk being trapped by your own success. I’ve come back from leave to a mountain of work that no one else could tackle, pigeonholed in roles that I’d become too good at.
You don’t make yourself indispensable by growing your knowledge, you do it by growing the team’s knowledge. You don’t need to be a manager, or have a formal mentoring role, there are things you can do every day. When you research a new technology or tool, document it, run a workshop. Ask questions in code reviews, suggest improvements not just for the code, but for the developer. If you find an interesting article, share it. Loan out your books. Small investments which can lead to incredible growth.
It also benefits you. Teaching something forces you to understand it properly. When I worked through Head First Design Patterns, I made sure I understood each pattern and had built a working example before I shared them with the team.
The developers who invest in the people around them are the ones teams are built around. Their absence would be felt not just because of what they know, but because of what they’ve given away.
What You Don’t Have to Do
Not every senior skill is for every senior developer. The role is broad enough that two people with the same title can have genuinely different strengths, different preferences, and different ways of contributing value.
There will always be parts of the job you don’t enjoy. That’s fine. The goal isn’t to become a developer who does everything. It’s to be excellent at the things that matter most to you and your team, competent enough at the things that affect your work, and honest about the things that belong to someone else.
I can talk to clients. I’ve done it, and when I have to I handle it well enough. But the project manager has far more experience in it, and the work is better for it being theirs. Recognising that isn’t a gap in my seniority. It’s self-awareness. And a team where everyone is playing to their strengths is a more effective team than one where everyone is performing a role they’re not suited to.
Know your strengths. Be honest about your preferences. Don’t fill gaps indefinitely that belong to someone else. Give yourself space to do your best work.
Direction of Travel
If there’s a single thread running through all of this, it’s this: seniority isn’t a level you reach, it’s a direction you travel in. There’s no moment where you arrive and stop. There’s no perfect version of the developer you’re trying to become. There’s just the next step.
The title, when it comes, will be the least interesting part of the story. What matters is that it's already true before you ask for it.
And if I had to distil everything across this series into a single instinct to carry with you, it would be this: pay attention, show up for the people around you, and leave it better than you found it.
That isn’t just advice for your codebase. It’s my philosophy for most things.
What's the one thing you wish someone had told you earlier in your career? Leave it in the comments. Someone earlier in their journey might need to hear it.
