The kind of engineer I want to be
Not the loudest in the room — the one who ships things that actually work for real people.
I used to think the best engineers were the ones who knew the most frameworks, talked the fastest in meetings, or had the sharpest takes on architecture Twitter. I still respect deep technical skill — but the people I admire most now are quieter about it.
They're the ones who ask what problem we're actually solving before opening an IDE. Who read the ticket twice, check the edge cases, and leave the codebase a little clearer than they found it. Who don't need credit for every fix, but do need the thing to work in production on a Monday morning.
That's the engineer I want to be.
Shipping over performing
There's a difference between looking productive and being useful. Demos impress. Reliable deployments help people do their jobs. I'd rather be trusted with a messy integration than celebrated for a prototype that never leaves my laptop.
Clarity over cleverness
Clever code is fun to write and painful to maintain — especially in enterprise environments where someone else will own your work in eighteen months. I try to favor boring patterns, explicit naming, and documentation that answers the question a new teammate would actually ask.
Listening as a skill
The best technical decisions I've been part of started with someone non-technical explaining how a process actually works. Users don't care about your stack. They care whether the screen loads, the number is right, and they can get home on time.
I'm still learning all of this. But when I think about the career I want, it's not defined by job titles or conference talks. It's defined by whether the systems I touch make someone's day a little easier — and whether the teams I join would hire me again without hesitation.
That's enough of a north star for now.