2 Important Lessons I Learned from a Principal Engineer That Made Me a Better Developer

What one conversation with a Principal Engineer taught me — and how it changed the way I code forever.

2 Important Lessons I Learned from a Principal Engineer That Made Me a Better Developer

The Conversation That Changed Everything

I had been coding professionally for about two years when I was lucky enough to work directly under a Principal Engineer at my company. I expected mentorship, sure.

What I didn’t expect was how profoundly a few conversations with him would reshape my understanding of what it really means to be a great developer.

I want to share two of the most powerful lessons I learned from him — insights that helped me go from writing just “working code” to writing thoughtful, scalable, and developer-friendly code.

These two lessons continue to guide my decisions today, and I believe they can do the same for you.

Lesson 1: “You’re Not Writing Code for the Machine — You’re Writing It for Other Humans.”

Let’s be honest. When we’re new in the field, there’s a natural obsession with making the code work. That’s the bar: does it execute correctly? Is the bug gone? Is the feature delivered?

But one day, after a pull request of mine had passed all tests and delivered the functionality as expected, I got a comment from the Principal Engineer that made me stop and think.

“This works. But would you enjoy reading this if you saw it a year later?”

He was right. The logic was convoluted, the naming inconsistent, and the structure unclear. It was correct — but painful to read.

What He Taught Me

Software is a collaborative, long-term effort. The compiler doesn’t care if your variable is named a or customer_subscription_status. But the next developer does — and that next developer might be you.

Here’s what I started doing differently:

1. Meaningful Naming Over Clever Naming

# Before 
def c(u):  
    return [x for x in u if x.p] 
 
# After 
def get_active_users(users):  
    return [user for user in users if user.is_active()]

Cleverness fades. Clarity lasts.

2. Write for the Reader

Comments aren’t a crutch. They’re documentation for context, why something exists, not just what it does.

# Before 
# increment x 
x += 1 
 
# After 
# Move to next index after successfully processing current item 
index += 1

3. Structure Like a Story

Break your code into logical blocks that mirror how someone would think through the problem.

Lesson 2: “Code That’s Hard to Delete Is Usually Code That Shouldn’t Exist.”

This one hit me harder than I expected.

I was hesitant to refactor or remove a legacy utility function because it had been around forever. I wasn’t even sure what all used it. I said, “I’m afraid to touch it — what if it breaks something?”

His response?

“If you’re afraid to delete it, that’s a red flag. Either the code isn’t well-tested, or it’s doing too much. Either way, it needs attention.”

Many developers think seniority means adding complexity. But the opposite is true — great engineers make things simpler.

Over time, I learned that the real art of development isn’t about writing more code. It’s about writing less code that does more — and knowing when to let go of what’s no longer serving the system.

What I Changed in My Practice

1. Refactor Aggressively, But Safely

• Write tests before you touch legacy code.
• Use feature flags to test risky deletions in production environments.
• Always ask: Is this still needed?

2. Aim for Low Coupling

If deleting one file breaks ten others, your architecture is too entangled. Prefer modular designs where changes are localized.

3. Let Simplicity Win

Just because something took you a long time to write doesn’t mean it deserves to stay. Let go of your ego.

These Lessons Made Me Think Differently

Before these conversations, I thought great developers were defined by:

• Knowing every language feature
• Being lightning-fast at coding
• Solving hard problems solo

Now I know that the best developers are often the most humble. They:

• Write code others can understand
• Simplify instead of over-engineer
• Think about systems instead of just features
• Care about the developer experience, not just user experience

Final Thoughts: You Don’t Need a Title to Think Like a Principal Engineer

The biggest takeaway?

You don’t need “Principal” in your title to act like one. You can start today by:

• Writing for the next reader (or your future self)
• Questioning complexity and letting go of unnecessary code
• Building habits that prioritize clarity, simplicity, and empathy

These two lessons didn’t just make me a better developer — they made me a better teammate, reviewer, and mentor.

And now, I hope they do the same for you.

If you’ve ever learned something powerful from a senior engineer, share it in the comments — I’d love to hear your story.