Week 29: Learning to Be a Principal Engineer (Three Years In)

Life is sometimes weird. I joined Ellucian as a Principal Software Engineer, and after being in this role for almost three years, I feel like I’m just now beginning to understand what it truly means.

When I first joined, I assumed the role was straightforward. But in today’s fast-paced, ever-changing software world, I’ve realized it’s much bigger and more demanding than I imagined. Honestly, I feel overwhelmed at times.

Recently, my brother sent me a screenshot from the book Staff Engineer, pointing out that Principal Software Engineer sits above Staff Engineer, almost at the Director/VP level. Brother, if you’re reading this—you’re not helping. 😅 I was already stressed about living up to the responsibilities of this role, and knowing it’s that high up only makes me more nervous.

But then again, fear can be good. It’s often in moments of fear that we bring out our best.

Alfred: Why do we fall, sir? So that we can learn to pick ourselves up.

And once you develop that hunger to learn, things slowly fall into place.

This week was proof of that. The project I’ve been working on got a complete rewrite under the guidance of a Principal Architect. Watching him work was eye-opening. From requirement gathering and stakeholder meetings, to system design, performance analysis, and automation—his approach changed everything. He even rewrote my initial solution in a way that now scales to handle billions of records, something my version couldn’t achieve earlier.

What impressed me most was not just the technical brilliance, but his mindset—automate wherever possible, reduce manual intervention, and design for reliability. It completely changed how I see system building.

This is the first project of my career where I’ve worked on something at this scale—millions to billions of records. A real use case. A proper learning experience. And I’m hooked.

If nothing else, this project alone will be one of the most valuable additions to my resume.