I'm by all possible measures a "Senior Developer" - at 46 years and 20+ in tech, I guess I've been one for a while.

To be honest, in an industry that "seniorize" people after 5 years, I probably deserve something more akin to "Ancient Developer".

When I left my C-level position 2 years ago, I had one certainty - that I needed to get off a pure management role, at least for a while, and a lot of uncertainties - notably about my capacity to make a difference and to convince a company to go with someone like me versus a 28-year old senior.

I guess I did got some answers that lead me to review a bit what seniority means for me those days - both from my point of view and those of my customers/employers.

Seniority as in Fitting In

Maybe the first thing is that I expect to "fit in" in the environment, not the other way around. I'll probably have opinions about how the company, team, code is organized, but my first approach is always to fit in, assuming that things I find weird or outright bad probably have some reasons to be that way - they usually do.

That means among other using the technology that's there (even if I would prefer/recommend another), taking tasks in spaces that are mostly unoccupied, following the current process (if there is one).

Time for challenging things always come, but there are good reasons to not start with that:

• I need time to learn how and why things works the way they do. Most companies are there since a while - that means whatever way they work allowed them to survive until now.
• I need to earn credit (with the team and the management) to be in a position to be listened to when I'll propose something. Going to fast (even being right) means a good chance of burning both the opportunity for improvement and the relation.

This is I think a reasonable expectation to have for a Senior Developer - having seen multiple companies & teams, you know things can work in many different ways.

Seniority as in Product Engineer

Working in small companies or teams means that my role is often not purely technical. Most "technical" problems aren't, so a significant part of the work is about talking & understanding stakeholders need - generally customers or management or both.

(non technical) Management is often used to have trouble communicating with the technical team - in both directions:

• They struggle to convey their priorities and needs
• They struggle to send proper and actionable feedback

This generate frustrations on both sides - I've often heard "Management does not understand this".

I see development as a support (if often strategic) function as it generally takes its marching orders and information from somewhere else (sales, management, subject matter experts). We generally don't define the "what" - we manage the "how".

A bit part of my job is often to help management & development to align - first on my own work, then often more generally in the company. Being someone that "speaks both languages" is generally of tremendous help.

Most inefficiencies I've seen in development are about building the wrong thing - not the thing wrong.

Something that baffle me to this days is how many developers seems reluctant to engage on this topic - including those that will in the end complain about "having to do things again".

Seniority as Finding where my value is

As I'm generally hired by the management (sometime technical, often not or not anymore) a key point is generally to find where I can provide the most value. Sometime it's getting a huge refactor done, sometime it's about getting some features out or stabilize the platform or improve the team or anything else.

The key point is that more often than not the reason invoked for getting me in is not going to be where most value can be generated - which means it's up to me to find that spot, do the job then report. It does not means not doing something I am specifically asked to do, but a recognition that I may be in a better spot to judge where I can produce value than the person paying my bills.

Seniority as Managing your Manager

I've been a team lead (I'm one again, I guess) and a C-level. Having "fled" the position does not means I forgot about what it is about. This is generally very helpful in my interactions with my own management. Being able to tell your boss "I understand" (truthfully, of course) goes often a long way.

This do not means "I agree" - just that I generally understand their positions, trade offs and others. I know why they're getting nervous, I often understand why things start to become "urgent" from their point of view - so I can generally anticipate them or ask for information sometime before they think to provide it.

This falls under "Managing your Manager" - something that starts with remembering that they are a human being too. Being senior, often a freelance in a good market tends to put a less asymmetric relationship - while I do work for them, I can generally speak my mind, devoid of most games.

Seniority as Helping other Developers

Part of the "I'll create my work where there are the most obvious empty spaces" is to tell but mostly show to colleagues that I'm here to help - and that starts with them. This is something that has more benefits that I can count:

• It helps me build the credit I'll need to propose changes
• It improves my own understanding of the system (the software, but also the team)
• If the team is larger than three people and more junior than me, it's probably the biggest value producing activity I can do.

It's "working on the team working on the software" vs "working on the software" - or generally "and" more than "vs" as to work efficiently with the people you need an understanding of the software.

It's also a way to start a culture of helping each other in company missing one - quite often it just needs someone to start it.

Seniority as "We're going to regret that"

This is about facing relatively big decisions - choice of framework, big refactoring or stuff like that. It's about trying to project how much we are going to like or hate that choice in a year or two. Not in an abstract way like "this code is so beautiful" but in a nitty gritty way like "this make it difficult to debug" (or to test, or to change).

Some things looks very smart in the moment, and are disatrous long term. Part of the job is to be able to differentiate them with more than 50% success.

Seniority as YAGNI (You Are not Going to Need it)

Linked but not the same is tha capacity to say "YAGNI" to some proposals, generally starting with "what if" or some hypothetical. The problem with the future is that it tends to be different from the idea we had of it. That's especially true of startup's code as you are sitting on top of two hypothesis: that the code needs are going to stay the same and that the business is going to.

There is the usual: keep it as simple as possible, assume you can't know the future. I'm an economist by training - our motto is "Predictions are complicated, especially when they are about the future".

But what about the technology?

I guess you can be very senior in technology too.

As far as I'm concerned, I've seen 28 years old developers I would not beat in a hackathon/tech competition settings.

Thing is - that's generally not what work looks like. Work is full of those gray areas, human aspects, incomplete information settings and so on. Seniority for me has always been about having seen a good amount of different environments and managing those areas more than being the most knowledgeable person on a specific technical subject.

Again - software is not about technology - it's about the value it generates.

Opinions? Let me know on LinkedIn!