Who really is a senior senior developer?

Originally written at pooyan.info Who is the author? Check out my profile on LinkedIn. Do we type faster? Do we write error-free code all the time? Have we memorized all syntaxes and algorithms? Do we know everything? Probably not! That's a 10x dev job! The myth of "years of blah blah" seniority in IT The idea that seniority is only about the number of years in the field is misleading. Just because someone has been coding for a decade doesn’t mean they have been growing, learning, or adapting to new technologies. Experience is valuable, but only if it is accompanied by continuous improvement, problem-solving skills, and the ability to make sound technical decisions. There are people who have been doing the same thing for decades without even considering to learn something new. Such people are not only not senior, but also will bring a toxic culture and a heavy inertia to your team. Seniority isn’t just about technical skills—it’s also about leadership, communication, and understanding business needs. A great senior developer knows when to push back on unnecessary features, when to mentor junior engineers, and when to advocate for refactoring versus shipping quickly. Value people who value learning, growth, and adaptability; and forget about measuring based on stupid things like "years of experience". Time to ask yourself ... Do we measure based on ... Lines of code? Number of commits? Number of Pull Requests? Number of fixed bugs? Number of features? If your answer is yes, then you'd probably hire based on "years of experience". If you are looking for something to "show progress", such things can easily be tempting to be valued. KPIs will be met. Something can be presented as "progress". High-level managers will be fooled, and mid-level managers will be happy! If that's the case, "seniority" can also be measured by "years of experience" and metrics like that. But real seniority is ... But real seniority is about impact, decision-making, and mentorship. It’s about knowing when less code is better, when not to reinvent the wheel, and how to guide a team towards better software, not just more software. Instead of focusing on vanity metrics, ask deeper questions: Who is enabling the team to succeed? Who is reducing technical debt? Who is improving developer experience? These are the real signs of seniority. If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn. Copyright & Disclaimer All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article. While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site. The contents of this article should not be construed as legal advice. Opinions are my own and not the views of my employer. English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication. Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents. If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Apr 6, 2025 - 05:49

Who really is a senior senior developer?

Originally written at pooyan.info
Who is the author? Check out my profile on LinkedIn.

Do we type faster?

Do we write error-free code all the time?

Have we memorized all syntaxes and algorithms?

Do we know everything?

Probably not!

That's a 10x dev job!

The myth of "years of blah blah" seniority in IT

The idea that seniority is only about the number of years in the field is misleading. Just because someone has been coding for a decade doesn’t mean they have been growing, learning, or adapting to new technologies.

Experience is valuable, but only if it is accompanied by continuous improvement, problem-solving skills, and the ability to make sound technical decisions. There are people who have been doing the same thing for decades without even considering to learn something new. Such people are not only not senior, but also will bring a toxic culture and a heavy inertia to your team.

Seniority isn’t just about technical skills—it’s also about leadership, communication, and understanding business needs. A great senior developer knows when to push back on unnecessary features, when to mentor junior engineers, and when to advocate for refactoring versus shipping quickly.

Value people who value learning, growth, and adaptability; and forget about measuring based on stupid things like "years of experience".

Time to ask yourself ...

Do we measure based on ...

Lines of code?

Number of commits?

Number of Pull Requests?

Number of fixed bugs?

Number of features?

If your answer is yes, then you'd probably hire based on "years of experience".

If you are looking for something to "show progress", such things can easily be tempting to be valued. KPIs will be met. Something can be presented as "progress". High-level managers will be fooled, and mid-level managers will be happy! If that's the case, "seniority" can also be measured by "years of experience" and metrics like that.

But real seniority is ...

But real seniority is about impact, decision-making, and mentorship. It’s about knowing when less code is better, when not to reinvent the wheel, and how to guide a team towards better software, not just more software.

Instead of focusing on vanity metrics, ask deeper questions: Who is enabling the team to succeed? Who is reducing technical debt? Who is improving developer experience? These are the real signs of seniority.

If you liked the article and want to keep me motivated to provide more content, you can share this article with your friends and colleagues and follow me here on Medium or LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.