Let’s face it, there is no clear path on how to become a senior developer. There is no certificate, no finish line, no manager who will walk up to you one day and say “you did it, congratulations, you’re a senior now”.
The Senior title might exist on paper, but what it actually means varies so wildly that a senior developer at one company can feel lost at another. Most of the time, your job decides what you learn, not you. That’s fine, until the day you realize you want more.
So instead of a checklist, let’s talk about the things that actually make a difference.
Keep Learning. Keep Practicing.
No matter how long you’ve been in the field, you will always face new things to learn. Some people go to the extreme and set strict goals, like the famous (and controversial) advice from Uncle Bob:
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you.
That might work for some people, but for most of us, going that hard just isn’t possible in the long term. Unrealistic goals usually don’t end well: you start strong, miss a few days, fall behind, and suddenly it turns into frustration instead of progress.
One approach that can work for most of us is the 1% Rule, also known as continuous improvement or “Kaizen.” The idea is straightforward: get just a little bit better every day. As long as you move forward, even by 1%, that’s already a win.
Real improvement doesn’t happen in just one way, it comes from two sides:
- A theoretical side: concepts, ideas, mental models
- A practical side: building, applying, breaking things
Dimension 01
The theoretical side
There's no single recipe to becoming an expert. You have to explore, try things, and see what works for you.
In practice
- Read books and technical articles
- Read the documentation
- Take online courses on topics you don't fully understand
- Work toward and try to gain certificates
Dimension 02
Practice. Practice. Practice.
Learning alone isn't enough, you also need to practice a lot. The gap between understanding something and actually being able to use it only closes through doing.
In practice
- Keep writing code
- Rebuild things from scratch to understand how they work
- Apply new concepts immediately after learning them
Developer Growth Dimensions
Here’s the real problem with “just keep learning”: many developers don’t know what kind of growth they’re actually looking for - I’m talking from experience - we get distracted by new tools, a new framework, the next shiny thing. Technology FOMO is real. And without clarity, we could end up spending years focusing on the wrong things. There are actually three dimensions a developer can grow in, and we need to understand that they are not equal.
Dimension 01
The Fundamentals (How you write code)
This is the foundation. The fundamentals. Not just knowing the syntax, but understanding the decisions behind every line you write. Senior Developers master the fundamentals of their tech stack and know the why behind every decision.
In practice
- Master the fundamentals of your language
- Understand data structures and algorithms, know when to use the right one and why it matters
- Solve the same problem in multiple ways and benchmark the results
- Practice debugging, TDD, and profiling
- Refactor and clean up old code and ask what you would do differently now
- Learn SOLID, DRY, KISS, YAGNI understand the problems they solve
- Study design patterns: Factory, Observer, Strategy, Decorator
Dimension 02
The Architecture (How you structure solutions)
At some point, writing clean code isn't enough. You start designing complex systems, thinking about how all the high-level components interact with each other. This is where many stop pushing further.
In practice
- Learn software architecture styles: monolith, layered, hexagonal, microservices
- Understand system design: how components interact, how data flows
- Study DDD, CQRS, and event sourcing as ways of modeling complex domains
- Practice API design and security
- Build small projects without frameworks
- Learn about monitoring systems: metrics, logging, tracing
Architecture is about the important stuff. Whatever that is.
Dimension 03
The Trap. (How you choose what to learn)
This is where most developers get stuck. Learning a new framework, a new tool, something to add to your CV. It feels like progress, but breadth without depth is the fastest way to spend years learning without actually growing. The best developers don’t learn more, they learn what matters.
In practice
- Prioritize fundamentals over tools
- Choose depth before breadth, then expand intentionally
- Apply what you learn immediately
- Avoid learning out of fear (FOMO)
- Say no to most things
- Master one language before learning a new one
- Avoid switching frameworks too early
Pick One Direction. Start Small.
If you don’t know where to start, pick one Dimension and start with the smallest exercise you can think of. More ideas will follow naturally.
Things you could try today:
-
If you want to go deeper on The Fundamentals: Pick a Kata exercise and solve it in multiple ways: use TDD, mocks, and test data builders. Refactor old ones and compare the results. Benchmark both, and ask yourself why one is faster. From there, you will find the motivation to explore other topics.
-
If you want to improve your Architecture thinking: pick one principle or design pattern, read about it and just build a small, simple experiment or concept that shows how it works. Once you’re comfortable with the concept, refactor your existing code to another principle or design pattern.
-
Create an empty project using PHP, Composer, Docker, and Nginx, and build your documentation with MkDocs Material using multi-stage Docker builds. You can orchestrate everything with docker-compose. This lets you practice multiple tools in a real-world scenario.
-
Build a React project from scratch at least once without a tool like Vite and manually add all dependencies. Start asking yourself:
- Which package manager should I use? npm, pnpm, or Yarn?
- Which bundler fits my needs? Webpack, Rollup, or esbuild?
- Which transpiler should I use? Babel, SWC, or esbuild?
- Should I add TypeScript for type-checking?
It’s okay to feel lost and not have a plan. The key is to start. Start small enough that you actually follow through.