Loading posts...
Loading posts...
Hello everyone. This article was born from a conversation I had with a friend of mine, a great software engineer, who was my mentor when I first started writing a bit of code. I've been formally in the industry for more than 9 years, my friend has been around much longer, and we hadn't talked in a while.
We took the opportunity to catch up a bit on what each of us was doing, and we wandered off, talking about generalities. The rise of AI, the low demand for junior devs, etc.
Giving my opinion very casually about my stance on various topics, the idea came to me to share my thoughts with you as readers, about something that kept spinning in my head after the conversation: What does it mean to be a senior developer?
If you're looking for me to tell you an axiom, nah, never. I've never trusted someone who tells me "this is how it is". I don't care if they have solid arguments. I believe that in science as such, taking a fact as truth without questioning it is a mistake.
Now, don't confuse me with a conspiracy theorist, no. I have some dignity haha. But I do believe that questioning things makes you really learn and take a solid stance. What I'm saying applies to everything in life, and it can even be something that goes more into the philosophical.
Anyway, we're here to question what it is to be a senior and that's what we'll do.
Clarification: I'm not going to get into any industry/field/trade that I don't know. If you're here, it's because you want to read an opinion from someone who works in the IT industry, specifically software development. So everything you'll read below is focused on this field.
The definition from the RAE dictionary is as follows:
Superior in category and experience to those who perform the same profession or position.
From the base, it makes a lot of sense. The question here then becomes: How do I measure if I'm superior in category and experience to other developers?
Whenever we want to measure something, we need a reference pattern. In this case, the reference pattern is other professionals in the same field.
Who do we measure ourselves against then? With all developers in the world? With those who work in my country? With those who work in my company? With those who work on my team? With social media gurus?
The answer is not simple and depends a lot on your environment. If you're in a bad work climate, maybe it's not healthy for you to measure yourself against your colleagues, considering there's probably a bias. This applies in reverse as well: if you're on a team that makes you feel very comfortable and supported, maybe measuring yourself against them makes you feel you're better than you really are.
I seriously doubt anyone hasn't fallen into this bias. Basically, the Dunning-Kruger effect is a cognitive bias that makes people with low ability in a task overestimate their ability, while people with high ability tend to underestimate their competence.
When is it easy for us to fall into that?
When we feel we learned something new, but not from the very foundation. For example, you spent 1 year learning a specific frontend path: you learned React, TypeScript, Next.js, TailwindCSS, etc. You did personal projects, maybe a couple of freelance projects, and you feel very comfortable with those technologies. It was an intense year, many projects, many ideas, a lot of code written.
The dopamine is immediate. You feel good because in 1 year you manage to stand out, even in front of your peers who have been around longer than you. You attribute your success to something of your own and you're probably a bit right.
By overestimating your abilities and impressing some people, you receive a promotion, you feel recognized. This is where reality begins to crumble.
They take advantage of the fact that you're good at what you do and assign you something you had never done in your learning path. They propose (for example) that you design a solution from scratch. Of course, you don't grasp the weight of what it means to do something from scratch: you create a repository, take what you know, organize the ideas a bit and start writing code.
Once it's your turn to show your design, you realize that you actually didn't design anything.
This hits hard, but also, if you take it from the kind side, this reality check really made you level up. When you realize you don't know anything, you begin to truly learn.
In your first years of experience, your work will be more or less simple. They'll give you a requirement, you review it, you ask questions (and I hope you ask questions), you execute, it takes time but you achieve it.
This answers the premise of what, buuuut halfway. Let's say this "what" is more from the operational perspective. But the real what can be a bit deeper.
The what really answers to the business need, and even more, to solving a need that responds to an investment of time and money.
This is not evident at first glance. In fact, it's likely that even with quite a bit of experience under your belt, you've never had to sit down with a client to understand WHAT they really need.
This question is closely linked to the first one, but has different nuances. The why answers to the justification of the business need.
Understanding the why allows you to comprehend the context in which the project is developed. It helps you understand priorities, risks and opportunities.
RISKS! A very good point. Do you know how to measure a risk? Do you know how to mitigate risk? Do you know how to communicate a risk? I can assure you that a person who considers themselves senior must know how to handle risks.
When you face risks, you can prioritize, plan, communicate, and most importantly (in my opinion): DELEGATE.
Yes, a senior must know how to delegate. You can't do everything yourself, and if you do, you're probably doing your job wrong.
Although it may not seem like it, the how tends to be the simplest part of a process. It's usually linked to the technical implementation of the requirement in question.
Here you may be questioning this point, but based on what I've observed around me, when you feel that implementing a solution is the hardest thing, it's very likely that you haven't had to face a real business problem. In synthesis, if for your day-to-day the how is the hardest thing, you're probably not doing a senior's work.
A senior must understand what delivers value and what doesn't. Defining the value of something is the set of previous questions. Martin Fowler is known for his contribution to the industry from a more communicational angle. We could dedicate an article talking a bit about him. But I found a couple of interesting points I want to share with you (I'll paraphrase):
The value of a feature is not in its technical complexity, but in its capacity to solve a real user problem.
Architecture solves what's important, architecture mitigates risks, it is not an end in itself.
Do you understand the context of the business you work in? If honestly your answer is no, you probably have a bit to go to be a senior.
A senior person doesn't take tasks, they take responsibility for them. Normally a senior has to face many situations where they fail, it's they themselves who must take charge of those failures.
When you're assigned any work and you accept, you are responsible for that work. Here we often make excuses: "person X didn't finish what they were supposed to do, therefore, I couldn't move forward with my part".
What did you do to mitigate that risk? Did you ask person X if they needed help? Did you offer your support? Did you give them a clear deadline? Did you communicate to the team that you depended on that task to move forward with yours? Did you raise your hand warning of your situation?
It's difficult sometimes to accept that, even when you have something that depends on another person, you are still the responsible one.
Uncle Bob says it very clearly in his book "The Clean Coder":
A professional assumes total responsibility for their work, including errors and failures. They don't look for excuses nor blame others for their own mistakes.
And well, it's a book I'd like to talk about in a while, because honestly, I have a sort of love-hate relationship with his narrative.
A senior knows when to say no. It's not a matter of ego or arrogance, it's a matter of responsibility.
In fact, Uncle Bob also mentions it in the same book:
Saying 'no' is an essential skill for a professional. It means recognizing the limits of their capacity and protecting the quality of their work.
In fact, I don't remember the exact words, but it was something like "If you don't know how to say no, then you ARE NOT A PROFESSIONAL".
Ouch, blow to the ego. The criticism of professionalism is strong. I don't agree with many of the things Uncle Bob proposes, but that will be a topic for another article.
If we get more on the side of "Good cop", saying no has to be accompanied by a counterproposal. When you say no, it's because you have something else in mind. Saying no without more makes you incompetent at what was requested.
Now, there's a timing to say no. When something is requested of you, your response should be more along the lines of:
Give me a moment to analyze well what you need, I'll contact you when I have a proposal in mind.
At this point it's key to question what they're asking you and analyze the real value of what you're being asked (we're making connections. Good!).
Saying no is pure experience. Knowing how to say no, to whom you say no, and when to say no, is what makes you senior.
To close this point, I want you to keep something in mind:
Saying NO is an act of profound responsibility.
Humility is something transversal to any type of profession or trade. Believe me that the person who expresses when they don't know something, but arrives in a reasonable time with the answer to what they didn't know, is much more valuable than the person who pretends to know everything.
Here the Dunning-Kruger thing comes in again. Humility allows you to recognize your limitations and seek help when you need it.
Believing that a senior knows everything is terrible. As they say here in my country: It's a shot to the feet.
You're going to retire without knowing many, many things. When you're clear about this, you'll be one step closer to being a senior.
We've mentioned communication several times in this article, and it's fundamental. A senior must know how to communicate their ideas, their problems, their solutions. But beyond that, a senior must know how to listen.
A senior must be internalized with their work environment: listen to ailments, understand personal problems, offer help. A person who stays on the sidelines in the human aspect with the team around them can hardly be a good senior.
Believing that the work of team health responds to positions like "People Manager", "Project Manager" or "Scrum Master" is a mistake. We are all responsible for the team's well-being, and a senior must lead by example.
You, yes, you, are responsible for your team's well-being. Your attitude should always be focused on collective well-being. If you try to apply this in your day-to-day, you'll be one step closer to being a senior.
A senior, by definition, must be a mentor. For me there's no discussion on this. A senior must have the desire to transmit what they know. Transmitting your knowledge causes many positive impacts, and believe it or not, teaching your team delivers tremendous value to the business.
Now, if you're going to teach, do it well. It's not a matter of sitting down with someone and telling them "Look, this is how it is because I said so". Teaching is guiding learning, orienting to seek answers, fostering curiosity, situating in readable and real contexts.
Do you want to teach Python to an intern? Ask first what they know, what they've done, their tastes, their interests. Not everyone learns the same, not everyone has the same motivations. A senior must know how to adapt their teaching to the person they have in front of them.
If you want to be senior, start teaching, and while you teach, learn yourself too!
This is already a personal opinion: there is no double implication between age and seniority. An older person is not necessarily senior. But a senior, very probably, is someone older.
And here I leave the criticism open. When you read job offers looking for seniors and then you review the job description and you come across something like this:
Seeking senior developer with 5 years of experience in React, TypeScript, Next.js, TailwindCSS, GraphQL, Docker, Kubernetes, AWS, CI/CD, Microfrontends, Module Federation, WebAssembly and Machine Learning (and the whole churro of technologies that occurs to the writer on duty).
Are they really looking for a senior?
I'll take the liberty of speaking for myself. I'm not even close to being one. In the context of technology domain and based on the description of a generic job offer, I probably "am" one. But a job offer that seeks profiles of people where the job description addresses the points we've discussed in this article, it's impossible for me to qualify for that position.
And you? Are you a senior? Take some time to reflect a bit on your professional stage.
The most important thing of all, to really grow, is to start by being honest with yourself.
I invite you to leave your comments wherever you read this article, I'd love to know your opinion on the matter.
See you!