I know that the practical meaning of seniority varies. A long time ago it used to be tied to years in the field alone. It was simpler time when the field itself wasn't as varied as now, the web was in infancy and web development meant knowing all the HTML tags while Javascript was an innocent dream unaware of the psychological trauma i would inflict on the world decades later.
This is more or less my definition about what it means to be a senior developer, regardless of how others see you. This definition is a little bit more than "ok, so you have 20 years behind you, can you show these baby-developers how it's done".
The years of experience are a trap that lead to a false certainty about how this are done. Developers are forced to keep up and develop at an accelerated pace but each iteration in the evolution process comes with a certain tendency to preserve a "way of doing things" grounded in the past. This way is useful in that it's a battle tested approach but it's a false feeling of certainty in that it's possible that a method may be rendered obsolete by new technology. There's no absolute here.
That's why my definition isn't necessarily anchored in experience. So here it goes. You're a senior developer if ...
nobody has to come to clean up after you
what does that mean?
It means you know your tools of the trade. You know what it means to take a requirement all the way to production, what it takes to develop it, run it, maintain it, monitor it and answer questions about why it doesn't work. Even if you don't do each and every thing by yourself, you know what each entails so that your code is a one-way street. For example, you know an application needs to be benchmarked, logged and monitored so you don't come back 5 years later to add those bits.
But in a more pragmatic way it means you own your work. It doesn't mean you're doing it perfectly the first time around, just that you know when you're wrong and you go back to fix it. You know your faults, lacks and strengths equally and you work on them.
You're not afraid to admit when you're wrong and perhaps you even have ways to test your approaches to determine that.
You don't manage other (younger) developers. You empower them, you share your knowledge but knowing that sharing is a two-way street which allows you to absorb news about new techniques and new technologies from them.
You are grounded in pragmatism. You build your theories, methods and approaches on experience but when you act, you act on empirical data that comes out of testing those theories and approaches.
Your mistakes are your own and so is the responsibility to fix them. While a fix may be a collaborative effort, the responsibility is yours alone.
You're not dismissive of others. You acknowledge that people, including you, come with the intent to do their best (until proven otherwise) and that this best is supposed to get better over time. Everyone comes with some knowledge (practical or theoretical) which should be put to the test.
Top comments (0)