I remember, as a younger man, asking my on-prem guru of the day, “when will I be a senior developer?”. I had no idea what answer I expected in response. Perhaps it would be on “time served”? After 2 years? Maybe 5 years? 10? Perhaps when I had more hair sprouting from my nose and ears than on my head?

What if years of experience was a useless metric? 50 years of packing bags doesn’t qualify me to be a store manager after all. Maybe it was once I had learned how certain classes in .Net worked? Or when I had a good grasp of how the CLR works?

There are various other metrics I suppose you could look at:

• Stackoverflow score?
• Number of people that have used my software?
• Amount of money made / costs reduced as a result of my work?
• etc.

I hadn’t expected his answer to simply be “you will know”.

Experience

I’ve been a Senior Developer for several years now, and often as a Lead/Principal Developer on small teams, so I’ve had plenty of opportunity to interview and vet potential candidates for my expanding teams.

Regularly a candidate’s CV has expressed many years of development, often 10 or more as a senior developer within a 25 year career. Unfortunately, in almost every case I’ve come across so far, that time seems to have been ill-served. These candidates have brought years of ingrained bad habits and since defunct patterns and practices. They’re not always directly to blame, it could simply be a case of project availability, only having the opportunity to work on simple, repetitive requirements.

I’ve been in these situations myself. You just need the motivation to further your personal development in your own time! If you are not able or willing to change your role, your job, your responsibilities, your workflow, then you have to put in the extra effort to stay current!

I’m not saying that all developers with a large number of years are antiquated or sans value. Simply, to date, I have met only one.

Knowledge

This, in my opinion, is a much better measure of seniority. I can honestly say that I have worked with Juniors that within a couple of months of tuition, have far surpassed the skill and value of so-called senior developers despite vastly superior years in the field. Years of writing bad code makes a developer considerably worse than an inexperienced junior because that is years of “knowledge” a developer needs to unlearn.

But that only leads to the next issue. How do you measure knowledge?

Metrics

There is no measure. Or at least, no single metric that I’ve come across over the years would accurately represent a developer’s knowledge, their skill, nor their value to the team. That’s totally reasonable of course; obviously we are going to interview candidates to find the people that offer the best fit for our teams, projects, and company. Even if there were such a metric that deterministically stated that an individual would provide ample value to our team, we would still interview them! They have to fit with our culture, it has to be someone we can see ourselves working with, they have to be able to learn from our teachings, be able to express themselves and their opinions, be able to contribute to discussions, and so forth.

So how do we get a grasp for whether someone claiming to be senior, is actually worth their weight, or even the 10 minutes it takes to vet someone?

Professionals

Software Development is a professional trade, and as software developers, we are expected to be professionals. Now I don’t anticipate “senior developers” to finish reading this article, suddenly realise the error of their ways, and immediately turn to their superiors requesting a demotion in title - though wouldn’t that be nice!?

Though, if I was lead of a team and someone on my team turned to me to say that although they believe they’re worth their value in salary, they’re not sure they’re sufficiently qualified to be a “senior” developer, I’m pretty sure I would completely respect and admire the courage of such an individual. Fortunately, my current employ allows me to follow my desire of a non-managerial role in senior development, and we’ve built a thus far fantastic team.

Interviews

When I am interviewing is the most obvious point at which a developer claiming to be senior, though is anything but, actually affects me. Time is money. If I, or my company, is hiring for a senior development role, I want the applicants to be to a given standard. It genuinely appals me to see the quality of some of the candidates that roll through the doors. Quite often we’re talking about graduates with years in the field and accredited with Microsoft certifications, that can’t tell their ass from their elbow when it comes to .Net, OOP, Principals, Patterns, Practices.

That’s 10-20 minutes on the phone, or over an hour face to face, of my life, that I can’t get back.

Reputation

You will often read books and articles from well known individuals within the software arena, such as Uncle Bob, talk about software development as being a craftsmanship, and developers as craftsmen. Like lawyers, surgeons, rocket scientists, we should portray ourselves in a professional manner; you’re a professional, right?

So when I see individuals with leading roles post a ridiculously simple question online, a blog stating alarming awful code or practices, and just generally being a liability to the industry, teaching juniors and other equally poor non-junior-by-title developers, I waver between disgust, disappointment, and outright rage!

Who cares?

You should! It is a reflection of all of us when an end user, customer, or project manager are recipient to poorly coded products. It is a reflection of us all when a project surpasses deadlines or does not meet requirements. It is a reflection of where the industry might lead when you see a blog post containing bad code, stated as factual best practice, because that is what the developers of tomorrow will grow-up believing to be the truth!

Hard Truth (In my opinion)

The hard truth is, from my experience, that less than 5% of seniors I’ve come across are actually deserving of the title. Less than 5%. At 4Com - my current company, when talking about developers after phone interviews, we use the “Hanselman Scale”; that is, given the renowned .Net Developer Scott Hanselman as a 10, what score would we assign to the candidate.

Despite technical tests and extensive vetting by recruitment agencies, 95% of candidates score below 4 (90% are between 0 and 1).

So before you take on the title of “Senior Software Developer”, try comparing yourself to a famous developer. Our team, including our juniors, know these developers to such a degree that we can openly refer to them by first names or nick names, everyone on the team being expected to know whom Udi [Dahan], Uncle Bob [Robert C. Martin], Greg [Young], Scott [Hanselman], and many more are.

Do you deserve an increase in pay grade, and do you deserve an increase in title, are two very different questions. I’ve worked with companies where for some bizarre reason the entire dev team were junior; yes, I was senior to them, but no, I was not a Senior Developer at the time. Compare yourself to the wider pool, not your peers.

Who am I?

If you’ve made it this far, you’re either enraged by my musings, or (hopefully) happen to agree. You may well be wondering who I am, so let me explain a little about me.

I’ve been developing for a little over 8 years now, originally in the VB4-VB6 arena, adopting .Net from about 2.0 onwards. I pride myself on my technical ability and I’m a strong advocate for clean coding; TDD, SOLID Principals, and correct utilisation of the 24 Creational, Behavioural, and Structural design patterns.

I’m well versed in architectural patterns and have industry experience with CQRS, ESBs, ES, Simple N-Tier, Port & Adaptor, SOA, SaaS, etc. I have not just worked with these patterns, but in several cases taken a principal role in the decision making and implementation of enterprise architecture.

I’ve worked with a broad variety of persistence technologies, not only competent with optimal usage and administration of SQL Server, but NoSQL products such as Raven, MongoDB, and Cloud based storage such as Azure Tables and DocumentDb.

For communication protocols I have witnessed the evolution from tightly coupled VB ActiveX Multi-threaded COM Socket Implementations through to OData and JSON Web APIs within SOA solutions. I’m competent with WCF and Web API’s and able to identify which technology suits a given circumstance along with the pros and cons of different approaches.

I’ve worked through the generations of web technologies from ASP Classic, through Webforms, to ASP MVC vNext, seen the issues we’ve overcome as a result, and the benefits afforded us by the latest frameworks. Coming from VB, I’ve seen similar improvements from legacy WinForms, to the current WinForms, WPF and it’s derivatives such as Mobile and Silverlight.

Within .Net I’m as comfortable parsing string inputs as I am writing de-coupled architectures. I have a strong understanding of under-the-hood implementations, how the CLR as a whole comes together, how to move to the bottom of the .Net stack and work across native Boundaries and emit IL.

I spend at least two hours, every day of my own time studying. Be it improving my skills with functional languages such as F# or Closure, working with the latest C# 6 / Roslyn builds, or catching up on the experiences of other developers on their blogs. I believe that is part and parcel of my trade; social commitments can still function perfectly despite the apparent homework. To me, studying is my downtime, and we all need a bit of that!

For those wondering, I am (in my opinion) at the bottom end of the Senior Developer bracket

Thoughts?

So what do you think, makes a Senior Developer?

Contributors

With thanks to my peers and friends, who shall remain un-named (you know who you are) for proof reading and contributing to this article.

NB: This article was originally posted (by me), here: http://www.notehub.org/2014/9/26/what-makes-a-senior-developer. The original has been stubbed and redirects to this page, so I apologise for anyone that read the original and found this article remarkably similar despite the change in format.