At 18, I didn't know what a distributed system was. At 21, I was building them at a FTSE 100. The gap in between was just willingness to feel stupid.
I started as an apprentice software engineer in February 2020. I was 18. By October 2023, I was a Senior Platform Engineer at a FTSE 100 company. I was 21. Three and a half years.
This isn't a humble brag. I'm not here to tell you I'm exceptionally talented or that I figured out some secret. I'm here to talk about the gaps nobody warns you about, how I actually closed them, and the difference between having a senior title and actually providing senior value.
Because those are two very different things.
What even is platform engineering?
I should probably explain what I do, because "platform engineer" isn't as self-explanatory as "frontend developer" or "data scientist."
Platform engineering is a specialised area of software engineering focused on developer enablement, experience, and infrastructure. We build the tools, systems, and abstractions that let other engineers ship faster. Internal developer platforms. CI/CD pipelines. Infrastructure as code. Observability. The stuff that makes the difference between a developer waiting 45 minutes for a build versus 5 minutes.
Unfortunately, it's also compliance and security. ISO 27001. SOC 2. HIPAA if you're unlucky. Making sure the infrastructure is secure, auditable, and meets whatever standards your enterprise customers require. It's not the glamorous part of the job, but it's the part that lets you sell to big companies. Someone has to care about it.
A platform engineer is a software engineer's software engineer. We build for builders.
I fell into it because I hated inefficiency. As a developer, I was constantly frustrated by our CI pipeline. Context switching. Waiting for builds. Random tools breaking. I just wanted the thing to work. So I started making the thing work. Started improving efficiency where I saw it.
Turned out that was an entire discipline. And I loved it.
If you're early in your career, pay attention to what frustrates you. The things that annoy you about your developer experience might be the thing you end up specialising in. I didn't plan to become a platform engineer. I just kept fixing the things that slowed me down.
The gaps (or: feeling like the dumbest person in the room)
When I joined Anaplan in 2021, I was 19 years old with an 18-month apprenticeship under my belt. My team was full of people with PhDs and Masters degrees in physics, computer science, electronic engineering. Staff engineers who'd been writing distributed systems since before I could even spell "distributed systems."
I felt like the stupidest person in the room. Constantly.
But that's where real growth happens. Working with people significantly more experienced than you is a goldmine. I learned how to be an effective engineer. How to balance technical mastery with commercial awareness. How to understand that the business context matters just as much as the elegant solution.
The gap nobody tells you about: you will feel dumb. A lot. For a long time. And that's not a bug, it's a feature. If you're the smartest person in the room, you're in the wrong room.
When I joined Anaplan's core resource scheduler team, I had to learn Kubernetes, Docker, and Rust simultaneously. We were writing Kubernetes controllers in Rust. Before this, I was rewriting legacy financial applications in Java. It was a whole new world.
Picking up Rust syntax, understanding systems programming, wrapping my head around memory management and ownership. I felt behind compared to my peers who'd been writing Rust for 2-3 years. There were definitely "I should know this by now" moments.
But you just have to do it. There's no shortcut. You learn by doing, by asking the dumb questions, by being the fool, by trying things and breaking things and fixing them.
Learning how to ask dumb questions
This sounds obvious but I got it wrong for a while.
The instinct when you're stuck is to immediately ask someone. The opposite instinct is to sit there for hours refusing to ask because you don't want to look stupid. Both are wrong.
What actually works: spend 15-20 minutes genuinely trying to figure it out. Google it. Read the docs. Try things. If you're still stuck after genuine effort, ask. But when you ask, show your work. "I've tried X and Y, my understanding is Z, where am I going wrong?" gives someone something to work with. "I don't get it" gives them nothing.
I kept a running doc of things I didn't understand. Some of them I figured out myself eventually. Some of them I batched and asked about. Having the list meant I wasn't interrupting someone every 10 minutes, and I could see patterns in what I was struggling with.
The other thing nobody tells you: senior engineers love good questions. The ones that show you've thought about the problem. The ones that make them think. Those questions aren't annoying. They're interesting. It's the lazy questions that drain people.
The T-shaped thing
I learned about the power of being a T-shaped engineer: broad knowledge across many areas, deep expertise in a few. Knowing what to know. Knowing where to go deep.
In your first couple of years, go broad. Expose yourself to as much as possible. Frontend, backend, infrastructure, databases, CI/CD, monitoring. You don't need to be good at all of it. You need to understand how the pieces connect. You need to know enough to have an intelligent conversation with someone who specialises in each area.
Then go deep. Once you've seen the landscape, pick something that genuinely interests you and become good at it. For me, it was infrastructure and platform tooling. I'm still not as deep as I'd like to be in a lot of areas, but I know enough to know what I don't know. For you, it might be something completely different.
The trap I see juniors fall into: specialising too early. Deciding they're a "React developer" or a "Python developer" in their first year. This limits your growth and your options. Stay curious. Stay broad. Specialise later.
The communication thing
Growing up, I hated public speaking. Presenting to big rooms terrified me. But as an engineer, I learned to love it.
There's no point doing great engineering work if you can't communicate its value to the right audience. As a platform engineer, you need to get engineering teams on board with your ideas. You need to articulate your value to the business. You need to sell the vision, not just build the thing.
This turned out to be one of my strengths. I didn't expect that.
Most engineers avoid this stuff. Demoing work. Presenting to stakeholders. Writing documentation. Explaining technical concepts to non-technical people. That avoidance is exactly why it's valuable. If you can do the thing most engineers can't or won't do, you become disproportionately useful.
Volunteer to present. Every time you communicate technical concepts clearly, you're building a skill that compounds.
How I actually closed the gaps
No magic. Just doing the work.
I got mentored by amazing engineers. Pair programming. Mobbing. Knowledge sharing sessions. And then running my own sessions, teaching others. When I first had to mentor interns, I learned more than I taught.
The formal mentorship programs were fine, but the informal stuff mattered more. Engineers I looked up to who weren't formally assigned to help me but did anyway. The staff engineer who let me pair with him on a tricky problem. The principal who answered my Slack questions even when she was busy.
How do you get those relationships? You make it easy for people to help you. Not "will you be my mentor?" That's a big, vague commitment. Instead: "I saw your PR for X, could you walk me through how you approached it?" or "I'm stuck on Y, could I ask you a few questions?" Then you come prepared. You respect their time. You actually do the thing they suggest. And you follow up to tell them how it went. That closes the loop and makes them more likely to help you again.
Some resources that genuinely helped me: Advent of Code is brilliant for picking up new languages. Small problems, immediate feedback, and you can see how others solved the same thing. Rustlings specifically for Rust. And The Pragmatic Programmer changed how I think about building software. I read it as a junior and got one set of lessons. Read it again a year later and got completely different ones.
For staying current, I watch a lot of ThePrimeagen and NeetCode. Good for seeing how other engineers think, what they're excited about, what they're skeptical of. Not a replacement for doing the work, but a good supplement.
The honest truth about courses: Udemy and Pluralsight are fine for structured learning. But I learned more from doing real work than from any course. Courses give you the map. Work gives you the territory. I still have a backlog of courses I tell myself I'll finish. I probably won't.
Taking ownership before you feel ready
This is the thing that accelerated me most.
Owning areas of the codebase. Owning projects. Volunteering for the thing nobody else wanted to do. Saying "I'll figure it out" when I wasn't sure I could.
At one of my jobs, there was a piece of infrastructure that nobody really owned. It wasn't glamorous. It was annoying to maintain. I said I'd take it on. Within a few months, I understood that system better than anyone. When decisions needed to be made about it, people came to me. That's how you build expertise and visibility without waiting for permission.
Every team has gaps. Things that need doing but nobody wants to do. Documentation that's out of date. Tooling that's annoying. Processes that are inefficient. These are opportunities. The unglamorous work that nobody wants? That's where you can add value immediately, and where you can own something end-to-end.
This is uncomfortable. You will mess things up. You will feel like a fraud. Do it anyway.
Putting yourself out there
The other thing that accelerated my career: just being willing to take the jump.
Applying for jobs I wasn't qualified for on paper. Saying yes to opportunities that scared me. Moving from a comfortable bank job to a tech company where I'd have to catch up on years of tooling. Starting a company while working full-time. Writing publicly about what I was learning.
Most people wait until they feel ready. They wait until they have enough experience, enough confidence, enough credentials. They wait for permission. That wait is usually indefinite.
To be clear: I'm not saying apply for things you're completely unqualified for. That's just stupidity. But if you meet 60-70% of the requirements and you're willing to learn fast, take the shot. The worst they can say is no.
I applied for Anaplan when I probably shouldn't have. I didn't have the experience they asked for. I got the job anyway. Same with Legal & General. Same with most of the jumps I've made.
The worst thing that happens when you put yourself out there is rejection. And rejection teaches you something too. The best thing that happens is you get the opportunity and rise to meet it.
You miss 100% of the shots you don't take. I know that's a cliché. It's also true.
Side projects
Starting Auralyze forced me to own all the infrastructure, get a holistic view of what it means to build, iterate, and launch. How to speak to customers. How to implement feedback. You learn differently when it's your thing and your money and your users.
At work, you see a slice of the stack. On your own project, you see everything. Frontend, backend, infrastructure, deployment, monitoring, user feedback, costs. This breadth makes you a better engineer even when you go back to your day job. You understand why things are built the way they are. You understand tradeoffs.
You don't need to start a company. Build something. Ship it. Maintain it. That's the learning.
What the apprenticeship taught me (and what I had to unlearn)
My apprenticeship was at a bank. Financial services. Big enterprise environment, legacy systems everywhere, lots of regulation.
I learned useful things. How enterprise environments actually work. How to navigate legacy codebases without breaking everything. The reality that most software isn't a shiny greenfield project. How regulated industries operate and why they move slowly.
But I also got comfortable. Financial services is years behind technology companies in terms of tooling and practices. The pace is slower. The expectations are different. It's easy to coast.
I always knew tech companies were a different ball game, and that was the game I wanted to play. So I made the jump early. My career has bounced around a bit since then. Fin services to tech to insurance to tech again, now working on agentic AI infrastructure. Each jump taught me something different.
When I first moved to a tech company, it was a culture shock. Everything moved faster. The tooling was modern. The expectations were higher. I had catching up to do, and I had to do it while also delivering. It was uncomfortable, but it was the best thing for my growth.
If you're starting out in a traditional industry, learn what you can from it. But don't let it define the ceiling of your skills. Keep learning modern tools on the side. Know that the tech industry moves faster, and be ready to catch up when/if you make the jump.
The jump to senior
It's not just about being good at your job.
As a junior, you're measured on executing tasks. As a senior, you're measured on impact. Did the team get better because you were on it? Did you solve problems that weren't assigned to you? Did you make good decisions when the path wasn't clear?
Senior means taking leadership and ownership of projects. Owning parts of the codebase. Being willing to share what you learn. Visibility. Setting up meetings. Seeing gaps and taking initiative to propose solutions. Getting those solutions aligned with the roadmap.
Senior is about impact beyond your individual contributions. It's about making the team better, not just shipping your tickets.
You're probably ready when people come to you with questions about your area. When you can take a vague problem and turn it into a concrete solution. When you've mentored someone else. When you think about the team's success, not just your own tasks. When you can communicate technical decisions to non-technical people. When you've shipped something from idea to production without hand-holding.
You're probably not ready when you still need detailed instructions for most tasks. When you avoid ambiguity. When you haven't owned anything end-to-end. When you can't explain your work to someone outside your team.
Imposter syndrome
Imposter syndrome was worst when I was a junior. Specifically, when I got promoted from grad to associate. That's when it peaked.
Dunning-Kruger in action. I was finally at a point where I understood how vast my ignorance was. I could see how much I didn't know. And I was surrounded by the smartest people I'd ever worked with, people intrinsically passionate about doing good work and taking pride in what we did as a team.
I had amazing mentors and an amazing manager who helped me combat it. But it was rough for a while.
By the time I got to senior, I'd made peace with not knowing everything. The imposter syndrome faded. Not because I knew more, but because I'd accepted that not knowing is permanent and that's okay.
What actually helped: keeping a running list of things I'd done well. Every time I did something good, I wrote it down. When I felt like a fraud, I read the list. It's hard to argue with evidence. This is also great ammunition when promotion or pay evaluation cycle comes around. You'll forget what you did six months ago. The list won't.
The other thing that helped: realising everyone feels this way. The senior engineers I admired told me they felt like frauds too. It never fully goes away. You just get better at managing it.
The honest bit
It's easy to get promoted to a senior title. It's very different to provide senior value.
I got promoted to senior before I was delivering senior value. I know that. But that's part of the learning curve. Having the title pushed me to accelerate. To understand how to add value. To not just build solutions, but tackle problems at their root.
The title came first. The capability followed. I'm not sure that's wrong, actually. Sometimes you need the pressure of the expectation to rise to meet it.
The uncomfortable truth: some people get senior titles and coast. They were good enough to get promoted, then they stopped growing. The title became the destination instead of the beginning. Don't be that person.
What I wish someone had told apprentice-me
You got the job you'd dreamed of since you were a pre-teen. It's everything you wanted and more.
But you're still nowhere near as good as you want to be.
And that's fine. That's the whole point. You keep going.
Your first job matters, but not as much as you think. It's a starting point. You can course-correct. Don't stress too much about getting it perfect.
Switching jobs is how you learn fastest. Different codebases, different teams, different problems. Each switch accelerates your learning. Don't stay somewhere comfortable for too long.
Nobody knows what they're doing as much as you think they do. The senior engineers are figuring it out too. They're just better at managing uncertainty.
The soft skills are the hard skills. Communication, collaboration, managing up, giving feedback. These matter more than you think. Technical skills get you in the door. Soft skills determine how far you go.
And for the love of god, take care of yourself. You can't code if you're burned out. Sleep. Exercise. Take breaks. This is a marathon.
Three years from apprentice to senior. Looking back, the speed wasn't because I was special. It was because I was willing to feel stupid, ask questions, take ownership before I was ready, and learn from people much better than me.
And for the record: I'm a few years into the senior thing now, and I'm still dumb. I'm still nowhere near as good as the engineers I look up to. The senior title doesn't mean I've figured it out. It means I've figured out enough to be useful while I keep learning.
That's it. That's the whole thing.
If you're just starting out: you've got this. It's going to be uncomfortable. You're going to feel dumb. That's the job. Keep going.