The Skill Nobody Tells You About (And Why It Matters More Than Code)
I finally clicked in my SRE role—not because I learned to code better, but because I stopped thinking coding was the point.
I've been in my SRE role for a few months now, and for the first time, I actually know what to check, what's needed, and why. The weird part? The breakthrough had almost nothing to do with writing better code.
The Setup That Actually Worked
I was assigned a high-priority, high-visibility resiliency automation project. Real stakes. I had to work with the App Team, understand their architecture, and deploy changes through GitLab and Terraform. Sounds like a code problem, right? It wasn't.
What changed everything was working hands-on with a senior engineer. Not in a "watch me code" way. In a "let's do this together and I'll ask questions every step" way. He reviewed my changes, guided me through each decision, and—this is the key part—helped me understand the why behind every piece.
What Actually Made It Click
Here's the surprise: the main skill isn't writing code. It's understanding context.
At first, this confused me. I came from a background where "good engineering" meant clean code, fast implementations. But SRE doesn't work like that. Resiliency automation for an enterprise app team isn't about elegant functions. It's about:
- Why this automation matters for their production readiness
- What specific AWS services and Terraform modules each application needs (which changes per team)
- How to validate that a deployment actually works
- What the entire pipeline does, not just your piece of it
That's not code. That's systems thinking. And it only stuck after repetition and mentorship—not after reading docs.
The Real Catalyst
My manager gave me more work. That sounds simple, but it mattered. I asked for it, he trusted me with a high-priority implementation as the primary engineer (with senior backup), and suddenly I had the repetition and real stakes I needed to stop theorizing and start understanding.
Each deploy taught me something I couldn't get from a tutorial. Each question I asked while pairing revealed gaps I didn't know I had. Each review from the senior engineer showed me what I was missing about the application architecture.
What This Means If You're Stuck
If you're onboarding or in a new role and feel behind: the gap isn't usually between you and the codebase. It's between you and the context.
Here's what actually works:
- Get hands-on repetition. Not simulated. Real work on real projects.
- Volunteer or ask for more. You need the stakes and the reps. Slow onboarding tasks won't cut it.
- Ask senior engineers questions while you work. Not after. While.
- Implement it yourself. With backup, but not hand-held. You need the friction.
This is what makes good engineering: understanding why something matters, not just how to code it. And that only comes from doing it, repeatedly, with someone who can answer the "why" questions.
If you're in that stuck phase right now, push for real work. Ask for mentorship. The concepts will click when you're forced to use them, not when you're reading about them.