Senior developer? You Keep Using That Word, I Don’t Think It Means What You Think It Means

Nah, I don’t think so.

I mean, is not that I don’t think I’m senior — to be honest, I don’t know.

But being a developer for 10 years doesn’t make anyone senior by default. You have to earn it.

Does having used tons of frameworks make me a Senior Developer?

Does knowing an API by heart make me a Senior Developer?

Does being older than you make me a Senior Developer?

Does leaving more comments on a Pull Request make me a Senior Developer?

Does having X years of experience in Y framework make me a Senior Developer?

I dunno. Maybe it does. Fuck, it does for recruiters, doesn’t it?

Okay, I can relate to that.

In our industry, “Junior” and “Senior” are blank labels, ready to be filled with any meaning we want to give them. We haven’t decided what being “Senior” means.

So, I’m gonna do it, too.

I’m gonna say that, for you to be a senior developer, you need to provide 4 things to your team:

Accountability and confidence

People can rely on you. You deliver. Understand me here — It’s not about you doing all the job. It’s about knowing what is possible and what is not, and under what circumstances.

It’s about helping to get shit done, building a bridge between the team and its external community. Business people, stakeholders, users, other teams, whatever.

And something else — mistakes. Everyone makes mistakes. The difference here is how you deal with them. “It’s not my fault, I did what my ticket said.” Yeah, well. Wow, such maturity.

Perspective and self-awareness

Keep a view of short-term and long-term goals. Of your project, of your team, of yourself. You help your team achieve a balance between them.

You understand the role you play in your organization — or, at least, with the immediate people that work with you. You communicate your intentions and your expectations — because you know you can set some.

I’ve been struggling here. Sometimes it’s daunting. You are focused on an issue you know nobody is gonna solve for you. While at it, someone asks you for a forecast. For help with unrelated stuff. For help with this stupid small bug that is so damn easy to solve you don’t understand why it wasn’t finished two hours ago.

And you need to understand that this is your role. You are not just developing alone inside a giant bubble. You are also providing value with these activities — a value that only you can provide, probably.

You understand that being a senior developer is a responsibility, not a “gift” or a “promotion”. You can see things other people can’t, so you must act when they happen.

A growing mindset

For both you and your team. You have a learning path and help others set their own. You create, you share. You live by this idea. You know you Circle of Competence, and you work towards increasing it or at least staying around.

Are you thinking about technical things? Yeah, you are thinking about technical stuff. Yes, it is a must to set up good standards (more on that later). But this point goes beyond that. You irradiate information: you help juniorish and not-so-juniorish people understand how to deal with situations.

The hard part of this? You’ll be setting an example on things you don’t pay attention to. Because you’ve done them thousands of times before. Again, don’t think only in technical terms.

A pragmatic craft

This might be an unpopular opinion. But hey, it’s my newsletter after all, right?!

You value good practices, clean code, clean architecture, and well-structured stuff. You also weigh in the importance of delivering.

I see this with myself. I used to focus so much on “best practices”. Is it important? Hell yes. It taught me a lot. Trying to dig deeper and deeper, helped me understand tons of stuff. It still does.

Yet, now I tend (try) to be more flexible about it. I see the value of juniorish people delivering stuff. About them feeling proud of their work. Yeah, there’s always a better way — but sometimes, it’s not worth it to push it harder.

Pragmatism is an underrated skill.

Notice the crucial difference here. I’m talking about going beyond the point of focusing solely on the beauty of code. Not before understanding it. I’ll say that again, capitalized, bold: Not. Before. I guess I’m trying to explain this.

It’s like shu-ha-ri: first, you need to master something. And when you get to see the true nature of it, then you can start transcending from it and finding your own path.

As Dumbledore told Harry in the last book (lol), youth cannot know how old people think, but old people can’t forget how it was to be young. (The quote is accurate. I have the 7 books in my head).

The point is that if you are a senior developer, you might be able to see yourself in the shoes of a less experienced(?) developer. You can understand his or her needs, and it is your job (yes, your job) to take it into account.

The sweet spot? Allowing other people to fail safely, and provide a safety net. Let them try out things, fail, understand why, and try again. If they don’t feel pain, they won’t understand the reasoning behind things.

But hey — It is easier said than done.

From my point of view, all these things are way more important. Way more important than knowing the last framework or being nitpicky with trailing commas and indentation. They define what seniority means, which has nothing to do with such stuff.

So, how do you feel about it? What do you think are the common traits of a Senior Developer? Do you identify as such? Why? Don’t you? Why?