What I Learned From Working Under 3 Principal Engineers for 2 Years

They didn’t just teach me code — they rewired how I think as a developer.

What I Learned From Working Under 3 Principal Engineers for 2 Years

Two years ago, I walked into a new job with a mix of excitement and imposter syndrome. I was stepping into a product engineering role, but what truly caught my attention during onboarding was a detail most would gloss over: I’d be reporting to not one, but three different Principal Engineers across projects.

To most developers, a Principal Engineer feels a bit like a mythical creature — somewhere between a battle-hardened senior developer and a tech visionary who seems to speak only in design docs and architecture diagrams. I was lucky (and slightly terrified) to be working closely with three of them.

Now, two years later, I’ve moved on to a new role — but the things I learned under their guidance fundamentally changed how I think about software, leadership, and growth. Here are the biggest takeaways.

1. Code Is for Humans First, Machines Second

One of the first things I learned — and unlearned — was my obsession with clever code.

I remember submitting a pull request early on with a “clean” recursive solution that I was secretly proud of. One of the Principal Engineers left a comment that stuck with me:

“This is elegant. But would you understand this if you read it after three months and had a headache?”

He wasn’t trying to undermine the code. He was teaching me a core principle: code isn’t just written to execute — it’s written to be read, maintained, and extended. That PR turned into a 45-minute discussion on readability, naming, and cognitive load. I came out realizing that simplicity isn’t a lack of sophistication; it’s a form of mastery.

2. Strong Opinions, Loosely Held

Each Principal Engineer had their own style — one leaned into functional purity, another favored pragmatic solutions, and the third was a system design oracle. At first, it felt like being pulled in different directions. But over time, I realized they all had one thing in common: they weren’t dogmatic.

Yes, they had strong opinions — but they were always open to change when presented with better ideas.

One of them would often say,

“Be passionate about the problem, not your solution.”

This mindset made debates feel energizing rather than adversarial. It wasn’t about proving you were right — it was about collectively finding what was best. It taught me to separate ego from code and value collaboration over being the smartest person in the room.

3. Zoom In, Zoom Out

Working under seasoned engineers taught me how to think in layers.

A junior or even mid-level developer often stays in the “zoomed-in” view — focusing on the immediate task, the current bug, the tight scope. Principal Engineers operate like drone pilots. They can zoom out to think in terms of quarters, platforms, or user impact — and then zoom back in to review a single line of code with surgical precision.

I saw this in action during a design review for a service we were building. While most of us debated naming and endpoint structure, one of the Principals paused and asked, “Why does this service even need to exist?” It completely shifted the room’s perspective — and eventually led us to simplify our architecture significantly.

This ability to shift perspectives — from implementation detail to strategic vision — is a skill I now actively practice.

4. Mentorship Isn’t About Giving Answers

One of the most surprising lessons I learned was how little direct advice I got.

Instead of being told what to do, I was often asked questions:

• “What would happen if this fails?”
• “Who’s going to maintain this in six months?”
• “If you were a new hire, how would you feel reading this?”

At first, it felt like being tested. But I eventually realized they were teaching me to think critically — not just about what I was doing, but why I was doing it. Good mentorship isn’t about transferring knowledge; it’s about shaping how you reason.

Over time, I found myself asking the same questions of others — and even of myself. That shift turned out to be far more valuable than any quick fix or shortcut.

5. Engineering Leadership Isn’t Flashy — It’s Intentional

One of the biggest misconceptions I had was that high-level engineers were constantly making “10x decisions” or pulling architectural rabbits out of hats. The reality was far less cinematic and far more human.

Great engineers lead quietly. They write thoughtful documentation. They show up early to unblock someone. They write the boring glue code that makes everything else possible. They spend time making others better, not just proving they are.

In one project, we had a critical outage during a rollout. While the rest of us were scrambling in Slack, the Principal calmly pulled logs, wrote up a shared doc in real-time, and gently redirected us toward a solution. No drama. No blame. Just steady, focused leadership.

That moment taught me what engineering maturity looks like — not in GitHub commits, but in presence, empathy, and clarity under pressure.

Final Thoughts: Watch Closely, Learn Quietly

You don’t need to work under three Principal Engineers to absorb what I did. Much of it came from simply observing: how they made decisions, how they communicated, how they navigated trade-offs.

If you’re early in your career — or even mid-level and looking to grow — my advice is this: find people who make you uncomfortable in a good way. People who are better than you, not just technically, but emotionally. Watch how they move. Listen more than you speak. And above all, stay curious.

Working under great engineers won’t just make you a better coder — it’ll make you a better teammate, thinker, and leader.

And that, in my view, is the real endgame.

Enjoyed this post?
💬 Let me know in the comments what you’ve learned from senior engineers.