Clear Signs that You Are Not A Senior Developer

Not even close!

Senior, junior, mid-level…do these titles matter? My personal opinion is that they are meaningless. In fact, I have yet to see a reasonable justification for these titles to have any kind of meaning within a dev team other than to stroke people’s egos.

Even years of experience isn’t something that should be used as a measure to assign these labels, in my opinion.

That said, I understand that a lot of folks swear by these labels in the software industry. And there is an endless number of opinions out in the wild on what makes one a “senior developer”. Most of it is at best a difference in opinion but at worst, meaningless drivel. In fact, if you are one of the people who think one or more of the following makes you a senior developer, then you’re most likely not one yourself.

So, if I were forced to assign these labels to software developers, the following is a list of things that if you believe them or promote them, you’re not a senior software developer.

Later I will share what I think would be a good criterion to consider someone to be a “senior developer”.

You think code/module/service ownership is a big deal

Some people think that as soon as you’re given responsibility for a piece of software, some code, some module and you become the go-to person to ask questions pertinent to that part of the software, then that means that you’ve made it into the exclusive club of senior developers.

In reality, having the responsibility for a piece of code says nothing about your seniority. It’s a simple management exercise! Your basic job as a software developer is to develop software, and naturally, if you’re more familiar than others on the team with a certain part of the software then you are going to be assigned the responsibility of maintaining that module or piece of code.

It’s not a badge of honor that no one keeps looking over your shoulder constantly to make sure you don’t blow something up. You’re past the baby steps stage, this was part of the job all along!

You think patterns and coding best practices are more important than business needs

This is a huge telltale sign of someone who is inexperienced. A lot of fresh graduates from college, especially those who’ve had it drilled into their head for the last 4 years that a certain way of writing programs is the best way to do it and the only way to do it have a hard time detaching themselves from coding “best practices”.

This is usually not a big issue. Some sort of structure and guidance when writing your code is a good thing. Especially within a team that is made up of people from all over with different backgrounds, having these best practices is a good way to keep things manageable.

But there are times, in almost every project, where “coding” best practices have to and should take a backseat to something that is essential to the business. If you don’t understand that business requirements are more important than your precious code, then you are definitely not a senior.

You think you know better than junior developers

This doesn’t require a lot of explanation. It isn’t a secret that those new to programming can be a bit slow in producing results but that doesn’t mean they are unable to contribute ideas that could prove to be very good for the overall project.

If you’re the kind of person who discounts or ignores the opinion of new or “junior” developers, then you’re not only not a senior developer, you should demote yourself and get your ego checked.

You look for opportunities to say RTFM whenever someone asks you a question

This is a personal pet peeve of mine and anyone who uses the term “RTFM” with new developers on my teams is given the boot.

This horrible phrase wastes more time than it saves. It serves absolutely no purpose in training people to be self-sufficient. It’s like changing that saying, “teach a man to fish” to “yell at the man to go find a manual to figure out how to fish”. Yeah, by that time the man will have died of hunger!

Our industry should completely get rid of RTFM for new developers. Not because it hurts people’s sensitivities but because it serves no good purpose. After people get a bit of programming practice under their belt, it is fine to recommend people read the documentation.

So, if you’re one of those developers who are always itching to use this phrase, then you’re not a senior developer at all.

You are dogmatic about methodologies and other meaningless things

You think making snarky comments about light theme vs dark theme, or tabs vs spaces is important. You think that methodology X is better than methodology Y and you’re always ready to argue for your side.

If this describes you, you’re not a senior developer and probably never will be a good developer.

You claim or act like you never make mistakes

Making mistakes is part of the day-to-day of any developer, regardless of the number of years of experience one has. Programming, especially problems you’ve never dealt with before, is a journey of discovery of solutions. There are bound to be wrong turns you take. This is understood industry-wide.

But still, there are people who act like they’re perfect and never make mistakes. In fact, they’re so conscious of wanting to appear to not make any mistakes that they will try and hide them when they realize they have made them.

If you suffer from this juvenile urge, you are not a senior developer.

You think using technology jargon makes you sound smart

The fact is that it makes you sound like you don’t know what you’re talking about at all. Good programmers are able to break things down into smaller and simpler problems. Those problems should be formulated such that they can be easily explained to everyone else in the team, but more importantly, to the non-technical stakeholders.

Yet, there are countless programmers, especially those who gain a bit of experience (in terms of years) who feel the need to continue to use meaningless jargon because they think that proves that they know more than others in the room and they can get away with not having to explain how they’re actually going to solve the business’s problems using technology.

They also think and believe that how the software works and how it is all put together is too complex for mere mortals such as business decision-makers to understand. Instead, they should just take their word for it when they say, “this is too complicated, it’ll take me 2 months!” or “there is no way to do what you’re asking, why? Too difficult for me to explain!”

You think being an expert at leetcode means you are better at solving line of business application problems

Yes, knowing how to leetcode…or being great at hackeranks does not make you a senior developer. It just means you’ve put in enough time into solving those kinds of specific problems.

In fact, being good at leetcode means absolutely nothing about whether you’ll even be productive within a team, let alone your seniority level.

You think software products don’t need designs

This is starting to become fairly common in the agile space where architects are looked down on. Some programmers think the architectural context in the shape of the design is a hindrance to producing a good product.

A lot of programmers who came up in the industry with their dogmatic outlook toward agile and related practices fall into this trap.

This is then justified by the endless iterations and not having any meaningless definition for “done” as if those are time-tested success-producing methodologies that must be followed at all cost.

This shows naivete on the part of the developer that clearly shows that they are not a senior developer at all.

Who is a good senior software developer?

As I said before, I don’t believe in these labels but if I had to award someone the label of a senior developer, they’d have to be an exceptional leader. This person doesn’t need to lead the team, however, they’d have leadership skills that translate to lifting up the team.

They’re able to explain their programming decisions to the business. They are able to answer questions from the juniors without dismissing them. They have no problem admitting they are wrong when they are. And they continue to learn from others because they never think they know better than everybody else.

I think it’s clear from this that my definition of a “senior developer” has absolutely nothing to do with someone’s programming abilities…let’s face it, even monkeys can learn to code. Instead, being a “senior developer” within a team has everything to do with their personality. How they treat others and communicate with others, and effectively lead others (regardless of their position within the team) is what defines whether someone is a senior developer or not.

Let me know what you guys think. Do you agree, disagree, don’t care?