Often, what separates a junior developer from a senior one goes beyond technical mastery. When you are starting out everything looks like a grey area. I went through that too.
what nobody tells you about "becoming" senior
I have met brilliant developers. People who built frameworks, competitive programmers, people capable of doing whatever they wanted with their favourite language.
But what actually makes someone be considered senior, or a specialist?
When I was an intern, my question was: what am I missing to be a junior? After I became a junior: why do I still not feel mid-level? And so on, between moments of impostor syndrome and moments of a God complex.
I started programming early. Being self-taught, I learned things as they came up: languages, frameworks, strategies. All separate, and often the ends did not seem to connect.
In 2019, after two years studying programming on my own, I started university expecting the degree to give me the confidence to work as a developer. So I decided to speed that process up: I took part in research programmes, hackathons (I even won one), entrepreneurship events, and I even joined the chess team for the university games (I failed miserably).
Between comings and goings, I got my first internship. And that is where the seniority journey began.
the "make it work" syndrome
In my first job, I was thrown straight into the fire. With no technical guidance, it was up to me to solve problems with code, and I could not let that opportunity slip.
So I made it work.
But "making it work" is only the beginning. I was learning to solve problems, but I was far from knowing how to design solutions.
That is where I started developing what I would later know as technical autonomy, but still without engineering maturity.
And that is fine. It is not common for a beginner to make architecture decisions. But having those opportunities gave me some insights.
when junior and mid-level look the same
Over time, I realised my work was not that different from what the mid-level developers were doing. The difference was in the confidence with which they decided.
I still did not feel entitled to propose patterns, so I followed guidance until I started getting room in the discussions. That was essential.
I went after communities, watched documentaries, watched talks, and revisited the university material I had ignored before. I started doing my own deploys, even simple ones.
In that phase I also had my first experience as a "technical lead". It was still very informal, but I got to make my first project-level decisions.
I started publicising my work and that opened a lot of doors. The more access I had to deep technical content, the more I noticed that the "trivial work" of day-to-day started losing its complexity.
Many developers, when they pass through that filter, come to think every solution has to be unnecessarily complex. They add verbosity, they want to write very idiomatic code and show that they know architectures, theories and complex tools, all of it in a system with few customers and almost no budget.
For code to be good it has to be built with clean/onion architecture, DRY, KISS, SOLID, TDD, DDD, plenty of classes and design patterns, and preferably with a nice robust infrastructure running underneath.
And that is where I met overengineering (or mid-level syndrome). All of it driven by a desire to know the truths, the silver bullet that could solve any problem.
the difference between knowledge and experience
One of the tech leads who taught me the most said something I never forgot:
"You already have mid-level knowledge. What is missing is turning that into experience."
Until then, I thought what I was missing was learning more. In fact, I needed to live through more real situations, make mistakes in design decisions, watch systems fail, refactor services I had built wrong myself. Really explore my potential.
Even with a lot of study, my opinions were still biased. I repeated patterns without understanding the context behind them. Depth was missing.
Some time later, on a trip to São Paulo, I had a conversation with the lead on another project. During a one on one he said something that flipped a switch: "What you are missing to be senior is a case. A successful project that validates your decisions."
And he added: "Do you know how to scale what you are producing?"
the turning point: thinking before doing
That question changed the way I work.
Seniority starts making a difference when you stop thinking only about what needs to be done and start visualising how it will behave in 6 months, 1 year or 5 years.
You can call it system design, software architecture or solutions engineering; the name matters little.
Designing systems is not drawing little boxes in Excalidraw. It is making technical decisions with organisational impact.
When you start understanding the components of your system as tools to be combined, your level of abstraction rises. And that whole fight about "where does this class go" becomes a detail; let us pay attention to the concepts being applied.
Good architecture is about trade-offs, not about frameworks or folder organisation.
closing the loop
There is no day when you wake up and you are "senior".
What exists is a sequence of experiences, mistakes, attempts, reflections and decisions. Some conscious, others not so much.
Today, when somebody asks me:
"What am I missing to become senior?"
I usually answer:
"In short, maybe just somebody hiring you with that title."
Keep building, listening and thinking about what you are constructing. The answer comes along the way.
Today, after a few more years and a lot more projects, the sense I have is that I can build any solution for the vast majority of requirements; what changes is how long I would take to solve each problem.
In the end, it is all a man-hour problem, and a question of which kind of problem you want solved. Knowing that what sets us apart is less and less the number of lines of code we write, especially in a world where every programmer already has an LLM at their disposal, and more the experience and exposure to different combinations of environments and solutions.