the best engineers aren't the best coders
Being a great engineer isn't just about clean code. It's about being someone your team wants to work with.
Don’t overindex on the engineering part. It’s just one pillar holding up what it means to be great.
Your output, your craftsmanship — these are important, of course. But beyond a certain threshold, overdeveloping these skills narrows your career paths. And the narrower the path, the more difficult it becomes to traverse.
I've met many engineers in my career who focus on craft at the expense of healthy team dynamics. They’ll raise objections in meetings and code reviews that stall progress—usually over theoretical concerns that they demand are addressed. What about this obscure edge case, or does this library handle that unlikely problem?
Craft obsession often brings baggage—like people-blindness, overplanning, and misprioritization. Teams want to get it right—but most can’t figure everything out up front. Often, they have to build what they can, serve the users' needs to an extent, and then find the edge cases to address. It's not that we shouldn't handle the unlikely scenarios that may harm the user experience. But we should cap the amount of planning before taking action and learning.
Now about the people part — perhaps what I see least indexed by engineers. I've been working a contract position, embedded as an engineer on a small team in a large org. An agency found me the position and got me in alongside another colleague from the agency. Then we got the news: our contracts wouldn’t continue. No dishonorable discharge—just a reprioritization to invest in full-time staff.
Then, two weeks before the contract end date, my boss at the agency tells me they want to renew. Plot twist!
I was delighted. I learned that my colleague, despite being an excellent engineer, would not continue on. Why?
Here's my theory: I made a commitment early on in this job to show up cheerfully to meetings and to be a joy to work with. I made deliberate efforts to build trust—delivering on time, flagging changes early, and showing real interest in their lives. While we're work colleagues, we're still people — so I care about them as people.
What really tipped the scale though? Meeting my teammates for coffee—in real life.
The position is remote, so I never met any of my coworkers in person. I knew the two product managers on my team lived in Chicago. When I visited friends there, I made arrangements to take them out to a great coffee shop. I was genuinely happy to see them, paid for the drinks, and we chatted for over an hour — life in Chicago, our families, food we liked.
When I let my PM know I might be leaving, he said something I won’t forget: I was the best engineer he’d ever worked with.
Whoa. That's serious praise.
But why? My colleague outputted way more code than I did. He was attentive to code quality. Hell, he kept me accountable when I forgot to put up enough testing and wasn't meeting code standards.
I made a no-agenda effort to be pleasant to work with—and to be a real friend to my colleagues.
That translated to trust at work. Because we had a personal relationship, we had skin in the game — a social bond beyond work that kept us accountable to each other.
So being the "best engineer" in many ways had little to do with engineering. It meant being easy to talk to, dependable, and—above all—trustworthy.
When you're looking at how to uplevel yourself in your career, remember that there are traits that form the foundation beneath your craft. Craft and skill alone can get you far—but they come with a low ceiling. Breaking through it takes tremendous effort. Instead, find a window — make sure to balance your skills with being a team player.
Sometimes, the best career move isn’t writing perfect code—it’s buying someone coffee.