Lessons from Being On-Call
Lessons from Being On-Call
Some of the most useful things I've learned about our systems didn't come from architecture diagrams or code reviews, they came from being on-call.
When you're on-call, you don't get to focus on just one service, feature, or repo. You see the whole system in motion, how services interact, what fails silently, what doesn't recover well, and where the logs are helpful or not.
What You Start to Understand
- Where the real bottlenecks are
- How dependencies behave under pressure
- What users actually experience when things go wrong
Before going on-call, I understood parts of the system well enough. But after a few incidents, I started to see how everything fit together, and it reminded me of when I was first learning to code.
A Familiar Learning Curve
I didn't go to university. I was 16, self-teaching, reading PHP docs over and over trying to make sense of it all. But when I got my first junior dev job and started learning from others, my progress skyrocketed.
Being on-call felt similar, not quite as intense, but the learning curve was real.
It changed how I think about logs, alerts, and documentation, because future me, or someone else, might be debugging it at 2am.
More Than Firefighting
Being on-call isn't just about firefighting. It's one of the fastest ways to go from "I know this code" to "I understand this system," and I'd recommend it to anyone who has the chance.
Curious what others have learned from being on-call, or how your team makes the experience more humane.