A metal walking frame
PR review? I'll be there in a minute...

Occasionally on those warm summer evenings, before the sun has set behind the garden fence, the bees visiting one last flower in a long day’s work, the clouds casting a faint memory of white across an increasingly purple sky.. I will sit on the patio and wonder to myself:

Oh dear, I’m old.

I’ve been adding “Senior iOS Developer” as my job title for six years now, and since my initial promotion to the role, I’ve never been that sure of what it actually means. Seniority means different things to different people. And here is what it means to this person. Me.

Know Everything Something

I’ll start with the easy one first. I do not think seniority means that the person needs to know everything about everything. Developers who work for a long time will, unless they jump sector like they’re playing a real-life game of Frogger, spend a large amount of their time working in a particular sector. People will become familiar and comfortable with working in AVKit or CoreData or CoreBluetooth and build out a career that plays to those strengths. But it is rare to find someone who knows all of these areas in-depth. There are so many frameworks and facets to developing for any platform, let alone iOS, that it’s not feasible to devote your entire mental capacity to everything on offer.

Unless you are Paul Hudson, of course. He is genuinely a wizard.

But over time, what becomes easier is identifying similarities and patterns in frameworks that are applicable in other contexts. Whereby the experience built up is less about the specifics of the areas of iOS you spend most of your day working with, but how to work.

So no, seniority doesn’t mean you know everything. You can’t.

It Isn’t a Sheriff’s Badge

Certain jobs have a “binary” condition. If I’m not a sheriff, I can’t put you in jail. If I am a sheriff, I can!

Seniority in development terms isn’t a badge that suddenly gives you the powers to work, act or treat others in a certain way. I’ve seen many developers without the job title who represent a “senior” role more than others who are further up the career ladder.

I think that the key to seniority is how you act. These are behaviours that you can adopt early in your career that will help you to progress, because you will be able to demonstrate them early.
If you are able to reach out to other teams to resolve an issue without asking, that’s what I would consider a “senior” behavioural trait.
If you see a bug or crash in your application and spend time to find the root cause, instead of the quick fix, that’s a senior behavioural trait.
If you can approach a solution with the right balance of completing a feature but also having one eye on potential future scope change, that’s a senior behavioural trait.

Exhibiting these traits can also make it easier when it comes to putting yourself forward for promotion. If I have to choose between two mid-level candidates and one is being supportive to others, able to independently resolve issues and architect work in a sustainable way..then it makes it much easier to make that decision.
And these traits don’t depend on completing a course or working for a certain number of years. They depend on experiences. And putting yourself in a position to increase the amount of experience you get, early in your career, will always be beneficial in the long run.

The inverse of this, is once you have that senior position - you shouldn’t use it as a weapon. I believe that one of the aims of the senior role is to encourage everyone else on your team to be at your level. It’s not right to stunt progress or overrule the team because of personal opinions, but to encourage discussion and provide clarity over why certain decisions are made.


With great power comes great responsibility

This is equally true for developers. The things you know should be a resource available to everyone else in your team. By helping others to grow, you can develop your own skills - through approaching problems from other points of view, pairing on tasks to experiment with new techniques and even just to be able to reinforce to yourself the things that you know.

From my experience, we get so caught up in the day-to-day of work that we lose sight of what our skillset is today. By working with others and leveraging your domain knowledge with others, it becomes an opportunity to reflect and gauge your abilities, not against everyone else, but against where you were. And you will find that taking these moments gives a better indication of your development into a senior position than arbitrarily being given a job title.


As a senior developer, you don’t get to sit on your laurels. There are always new developers coming in who will be eager to either learn or introduce new technologies, and if you take your position for granted then you might not keep it for long.
I don’t think that necessarily means to always jump on the latest trend or tool and become an expert, but to me it means you should be humble enough to be open to learning from others and encouraging of others to learn new things.
This way, you are able to stay on top of the progress in your field in a symbiotic way - juniors/mid-level engineers bring enthusiasm to try new things and your position identifies the optimal approach to integrate those ideas.


As a footnote, I need to clarify - these are my views. But having done this job for a while and been involved in recruitment into teams, these are things that I would look for in a candidate for a senior role.

My advice if you’re a junior or mid-level engineer would be to see how the senior’s in your team are working, what their thought processes are and how they approach problems. Use initiative and be confident to solve issues independently.

If you’re a senior, look around you. The people on your team can improve you just as much as you improve them. Encourage collaboration and discussion. Defer ownership to them in some instances and explain why. Be a point of reference rather than a point of obstruction.