What makes a good software engineer?

I was in an AMA at work, and someone asked me what makes a good software engineer. I said: Someone who is curious and wants to understand why from many points of view (tech, product, customer, etc.), and someone who cares about the outcome, not that they were the ones to “get it” or “make the decision.”

The more I think about it, the more I realize that curiosity is the foundation. You need curiosity about the system you’re building, the organization’s actual goals, and especially about the people you’re working with. But curiosity alone isn’t enough, you also need to be intellectually honest about what you find.

The principle I try to live by is: I would rather be correct than right.

Difference between right and correct #

Might makes right: you can use position and authority to be “right.” But correct? Correct requires curiosity. It’s about the actual circumstance you’re in, not your organizational heft.

I started thinking about this long before I was a principal. I felt annoyed when people senior to me wouldn’t explain themselves, when they’d just make calls without context, “you have to do it like this.” They cared about how the work was done, but not about whether I understood it, or whether I might have useful context they were missing, or whether I could make that same good decision next time. So I wanted to make sure I was doing better, being clear about what I’m about. Because there’s nearly always someone more junior to you who deserves that clarity.

Now as a principal, I can use my position to be “right.” I can make calls. Pull rank. End discussions. But is it the correct call?

Depends. (how you know I’m senior, right?)

I rarely have the full context of a situation because I go broad, not deep (across several topics, rarely deep on one), so I need to listen and dig into what other people are saying, and incorporate that into the bigger picture. And… most of the time, you won’t necessarily get it correct then and there, so you’ll have to loop back.

Which is part of why I hate making decisions in a meeting where we’ve been exploring stuff. I want time to think about it. Time to incorporate what we just talked about and then write it down so we have it clear as day what we agreed to, or at least, what I thought we agreed to.

The truth is, being known as someone who can get shit done, no matter who came up with the idea, is going to take you far. In most good places, that’s what they’re looking for. You don’t want to be “the smartest person in the room.” Instead, aim to be the person who enables everyone else in the room, and that starts with being curious about what they bring to the table.

But knowing the difference between right and correct isn’t enough. You need concrete practices to actually live it. I’ve had to develop specific habits to fight my natural instinct to just be ‘right’, especially as I have the organizational weight to do it, and my boss told me day one that I shouldn’t rely on my weight alone.

How do you do that? #

These are the practices I have internalized and try to live by. Some of them are just about automatic and some still take effort.

Change your mind out loud #

Listen to others and actually evaluate their suggestions objectively. I remember a project back when I was a consultant. I had championed a pattern, and another colleague thought they had a better way of doing it. They weren’t looking forward to having the discussion because they knew I would need to be convinced to go along with them.

They brought up their suggestion, explained what it would be and what it gave us (1-2 minutes, tops), and they looked at me and saw that I was thinking. Then: “Yeah, that’s a much better idea, let’s do it!”

I noticed then how they seemed to relax because they thought it’d be a hard sell and conversation, because they had mostly seen me not convinced by arguments in the past, and colleagues getting frustrated from it.

I continued with why I agreed with them, so it was clear.

Be open about why you changed your mind. Because it sucks to have people around who just keep flip-flopping on stuff.

For example, sometimes we change our mind because “we’ve caused too many incidents because we moved too fast, so deploying multiple times per day isn’t what we need right now. What we need is earlier detection and understanding why we had such big incidents, so when we move faster again we’ll still catch the problem when it’s small.” Not that I have something super particular in mind.

Don’t move the goalpost #

Be caring, intellectually honest, and outcome-oriented enough to make sure you have a stable target for when you’re working together.

I try to explain my decision-making criteria, what my objection is, and what would help me change my mind. It’s about deliberately breaking down what we’re actually trying to achieve so others can engage with it: we need to be on the same page about the goal, not just the solution.

Because it sucks if you say “if this problem goes away, then we can do this” and then they come back having found a solution, and then you add another thing to it. Obviously, it’s hard to capture everything up front, but if you keep moving the goalpost then it’ll suuuck to work with you. Sometimes you have to, but make sure you’re clear that you’re realizing it as you go, and why this has to go into the original criteria.

Meet people where they are #

This is something I learned as a consultant and it’s about understanding your customer and their situation: their context and constraints, but also your goal and where you want them to end up, so you can drive towards that horizon even if the immediate step is something smaller, and maybe slightly sideways.

GeePaw Hill, who writes about technical coaching, says we can never convince anyone of anything, but we can create circumstances so they can convince themselves. Showing that you’re there and understand them will be the thin end of the wedge that hopefully will help them explore what you’re bringing.

Use their language, understand what is feasible to do right now vs. what you want longterm. A small step in the right direction is still a step.

Example:

• My horizon: I want you to do TDD
• Where you are: Tests are a waste of time
• Next step: We’ll have at least a black-box integration test for the success/error case, so we can catch the most egregious regressions. We’ll iterate from there as you see the value without huge changes in how you work

Help the other person shine #

This one only works if you’re already doing the other things. You need to be able to change your mind, be clear about your criteria, and meet people where they are before you can effectively help them succeed.

I realized and learned this during interviews, but it’s equally important with colleagues. When I interview someone to join the company, I know that we have very different backgrounds, and we don’t know much about each other. They’re likely to say things that are some kind of colored flag to me, but I need to try and clarify and understand what they really meant. Because their shorthand that’s a red flag to me might be the culturally right way to sell that idea in their current place.

And if this matters with strangers in interviews, it matters even more with colleagues you’ll work with every day. In theory we’re all steeped in the same culture, but different teams, managers, and just how long you’ve been there shapes it all. We’re rarely working at the same idea of the company.

Clarify, elaborate, help the other person sell their idea to you. Make sure you understand them and are representing their view correctly, confirm it, don’t assume. If I then still disagree, I can explain why much better. And if you both are clear that you understand their perspective, they’ll probably be much clearer that you’re not just saying no because you don’t understand it.

This is something I have struggled with, and something I have had to work on: while I have for a very long time been able to be convinced, I didn’t do enough to help the other person win me over.

The thing about ego #

When I started programming there was a strong feeling that being a software engineer also kinda meant you were a lone basement dweller changing the world, or well, your part of it where you rightfully were god emperor. But, it’s about working with people, and clear communication, both with humans and machines.

To me, a lot of it is just about being very clear about what you value and want (both design and architecture, but also in how to work), and then being able to communicate it. And also not getting too caught up in your ego and instead thinking about the goal for whatever you’re doing.

So when someone asks me what makes a good software engineer, that’s what I think about. Not the person who’s always right, but the person curious enough to find correct. The person who cares more about the outcome than the credit.

I’m never as awesome as I might fool myself into believing. My ideas get better when discussed and improved upon as a group, and that’s the way it works. The best engineers I know aren’t trying to be the hero with all the answers. They’re the ones asking “what would change your mind?” while offering “this is what would change mine.”

A friend once told me that a high-performing team is one that wants to be. A team that decides they want to be correct in their outcomes, they’ll set ego aside and work together. I bet they’ll be high-performing, because they’re actually working together, not just sitting in the same room competing to be right.