When my students ask how I got here, the answer is pretty simple: I was curious and I made a choice that most people in my position wouldn’t have made.

I started out in a rotational program at a digital advertising company. Four months, three rotations. Everyone in that program had the same goal. They all wanted to land on a product software engineering team when it was over. That was the prize.

I picked the app support team instead. Part of that was curiosity, but part of it was that I had a mentor on that team who made it impossible not to. He showed me what the work actually looked like, what you could learn from it, and why it mattered. He made it exciting before I ever did a single day of it. A lot of what I know today traces back to what he taught me in those early years.

This was the early days of DevOps, before it had a name everyone was putting on their LinkedIn. We were the team responsible for the infrastructure that all the applications ran on. We were also the ones getting called at 2am when something broke.

Nobody understood why I chose that. Honestly, I’m not sure I could fully explain it at the time either. But what I knew was that my days were never going to be the same twice. One day I’m digging into a Java garbage collection problem. The next I’m helping a developer get their application deployed through Puppet and making sure their Jenkins pipeline is set up so they don’t need me to hold their hand every time they push a change. The variety kept me engaged in a way I don’t think I would have been on a product team working the same codebase every day.

Now, the 2am calls. I’m not going to sugarcoat it. It was stressful. Every single time. Nervous, anxious, that pit in your stomach when your phone goes off and you know something is broken and people are waiting. And here’s what nobody tells you: that feeling doesn’t go away. I carried it all the way up until I moved into an architecture role. You get better at handling it, you learn to trust yourself more, but the feeling itself never leaves. That’s just the reality of being on call.

What it gave me though, and this is what I tell my students, is something that’s really hard to get any other way. I saw systems from end to end. Not just the code, but everything underneath it. How a server gets provisioned. How an application gets deployed onto it. How it behaves when real traffic hits it. How it eventually gets shut down. That full picture changes how you think about building things. I wasn’t just writing code that ran somewhere. I was the somewhere.

I tell every student who asks that they should start their career on a team like that if they get the chance. Not because it’s a rite of passage or because suffering builds character. Because it makes you a better engineer. You learn to troubleshoot under real pressure. You see how systems actually fail, not how you imagined they would when you were building them. And you walk away with a view of the whole stack that most engineers spend years trying to piece together.

Look, I’m not saying the safe path is wrong. Plenty of great engineers took it. But in my opinion, if you get the chance to be the person responsible for the infrastructure, the one getting called at 2am when things break, you should take it. That experience gave me a perspective on systems that I couldn’t have gotten any other way, and I genuinely believe it’s made me a better engineer and architect. That’s just my take.

I’m glad I made that choice.

If you’re early in your career and you see an opportunity to be on a team like that, take it. It won’t be comfortable. You’ll probably question the decision at 2am. But it will change how you think about building things, and that’s worth more than a comfortable start.