Why This Journey?
Over the next 16 weeks, I'm building my way into becoming a Backend/Platform Engineer with genuine SRE ownership. This isn't about credential collecting or tutorial completion. It's about constructing real systems, intentionally breaking them to see how they fail, and extracting lessons from those failures that stick.
What Makes This Different?
The typical learning path teaches you how to build features. I'm focusing on something harder: learning how to operate systems. There's a crucial difference between writing code that works on your laptop and running services that stay reliable under production pressure.
Instead of just building a service, I'm learning to operate it when things go wrong. Instead of just writing code, I'm deploying it, monitoring its behavior, and practicing recovery when it fails. Instead of memorizing patterns, I'm making deliberate architectural choices and living with their consequences long enough to understand the trade-offs viscerally.
The Plan
The journey breaks into four phases, each building on what came before.
Phase 1 (Weeks 1-4): Service Foundations starts with building a backend service, but with explicit attention to boundaries and contracts. I'm implementing comprehensive failure handling from the beginning, not as an afterthought. Observability isn't something I'll add later—it's part of the foundation, because you can't operate what you can't see.
Phase 2 (Weeks 5-8): Production Reality takes that service and deploys it to an actual cloud environment where real costs and real failure modes exist. This is where chaos engineering enters: deliberately injecting failures to see what breaks and how. I'll practice incident response and recovery, building muscle memory for staying calm when alerts fire.
Phase 3 (Weeks 9-12): Platform Thinking shifts perspective from single services to reusable components. I'll define Service Level Objectives and error budgets, treating reliability as a product feature with explicit trade-offs rather than an ideal we wish for. This is where you start thinking like a platform engineer: how do I make it easier for other engineers to build reliable services?
Phase 4 (Weeks 13-16): Communication recognizes that technical work needs clear documentation and explanation. I'll create technical writing that demonstrates ownership and build documentation that's actually useful to others. The goal is a portfolio that shows not just what I can build, but how I think about reliability and operations.
Learning in Public
Everything I do will be visible and documented. Each week, I'll publish posts covering what I built, what broke, and what I learned from it. Every Friday is "Failure Friday," where I write honest postmortems about that week's problems. I'm keeping decision logs that explain why I chose one approach over another, including the trade-offs I considered. All the code lives in GitHub where anyone can see the actual work, not just polished summaries.
The Three Questions
Every Friday, I'm answering three specific questions that keep me honest:
First, what failed or almost failed this week? If my answer is "nothing," then I know I didn't push hard enough or I'm not being honest with myself.
Second, what signal caught the failure, or what signal should have caught it but didn't? This forces me to think about observability and whether I would have known there was a problem in a real production environment.
Third, what human decision mattered most? Technology choices matter, but often the critical moment comes down to a judgment call—how I prioritized, what I decided to investigate, when I chose to simplify instead of adding complexity.
Following Along
You can watch this unfold in several places. My GitHub repository contains all the code and documentation as it develops. I'm using Notion as my learning system, tracking progress and organizing notes. This blog will have weekly updates every week. There's also a spreadsheet tracking my progress against the plan.
I want to be clear about something: I'm not starting this as an expert. I'm documenting the journey from being a competent developer to becoming a platform engineer who can operate production systems with confidence. If you're on a similar path, I'd love to hear about it in the comments.
What's Next?
Week 1 begins tomorrow. I'm setting up the learning system that will carry me through these 16 weeks. I'll define the first service I'm building and write its OpenAPI specification before touching code—practicing that discipline of thinking through contracts and interfaces first.
If this resonates with you, subscribe to follow the journey. If you're learning similar skills or have been through this transition yourself, I'd value hearing your perspective in the comments.
GitHub: platform-engineering-portfolio
Week: 0 of 16
Hours invested: 0
Top comments (0)