Properties of Great [Software] Engineers

There is no one recipe for turning yourself into a “great” software engineer, but I’m very confident that if you look around in your own organization and examine the people you think are “great”, then you will discover that they tend to have these properties. This article is a bit proscriptive and also a bit myth-busting. As far as your own organization goes, well, your mileage may vary.

If you are doing all these things, you might be a “Great Engineer”

1. No job is beneath you

Some of the most important problems require working on things that are not very glamorous. In fact, the anti-property here is this: if you tend to only work on glamorous stuff, you are probably leaving a lot of greatness on the table.

There are many ways to help your team and sometimes it involves fixing the build, debugging a bunch of crashes, digging into a bunch of performance traces, or something else that seems not very exciting. An interesting thing is that when a Great Engineer starts doing one of these things, suddenly that thingexciting. New ways to analyze telemetry, crashes, build times, or any other such kind of thing can result in amazing gains for your team. But they also provide tremendous insight into What Is Actually Going On(TM) which in turn gives you the ammunition you need to Do Great Things.

You can get awesome insights from anything.

From an assessment perspective: In a healthy organization team players will get props for doing what’s needed and likewise, “I can’t get [Person] to do anything but [Fun Thing]” is not likely to play well in evaluations.

“There are no small parts, only small actors.”

2. You don’t rush to turn in junk

When a deadline is looming its very tempting to start cutting corners to get your code into whatever the release vehicle is in time for the beta or whatever. This is so backwards.

The truth is that the less time you have left, the more careful you need to be. Let me say that again, if time is running short you cannot afford to be cutting corners, that’s a time to be extra careful so as to be sure you’re not going to break everything around you.

Organizations frequently get this wrong; they celebrate amazing last minute results and then all too often find out later that the results were not real. The code was full of bugs and a bunch of work will be needed to correct it. This is horrible behavior and Great Engineers do not engage in this.

I can’t tell you how often I’ve heard things like “writing all these tests will slow me down” but the kinds of gains you get by skipping important steps (like testing) do not result in good product. I’m fond of saying, “The root word of productivity is product; I’m not interested in increasing your crapitivity.”

You’ll find that the most productive engineers are the most ruthless about the quality of their code. Believe me, nobody is interested in how quickly you can ship something broken. Certainly not “upper management.”

From an assessment perspective: A healthy organization waits a while to recognize success and “fake successes” are not rewarded. Quite the opposite in fact.

“Measure twice, cut once.”

3. You deliver things methodically

This is kind of like the dual to #2. Great Engineers deliver things in a regular predictable cadence. They don’t hide in a room and then deliver a completed solution at the finish line. That’s for rookies.

Whatever it is that you’re working on, find ways to deliver pieces of it in regular intervals, verify that those partial pieces are working, and then keep iterating like that until you’re done. This isn’t always easy but that’s what Great Engineers do.

If you’re doing this you won’t often get to the end of a 20-day project and discover that you need 20 more days. This is an important point, if you are doing a 20-day project and on the first day you discover it will actually take 40 days then you are a hero. If you make that discovery on the 20th day then you are a bozo. And also any chance of changing the deliverable or getting help is at least partly lost.

From an assessment perspective: Organizations value consistent predictable results. Surprises and overages are costly, and they are more costly when there is less notice.

“Engineering is about getting predictable results for a predictable cost.”

4. You help others like it was your religion

This is a funny one because sometimes I hear people saying they are conflicted by the fact that they know they will be in some kind of contest with their peers for the best rewards. I’ve always found this to be a strange thing to worry about because helping your peers to succeed is probably the surest way to achieve your own success.

I’ve spoken about this particular phenomenon several times and my favorite metaphor is Wayne Gretzky. The Great One did score a lot of goals, and that’s pretty amazing, but what’s completely crazy is how many assists he managed to rack up during his career. When Gretzky is on your team everyone is scoring more, not just him. And people are very excited about being on his team because they know opportunities are coming their way.

Great Engineers are very much the same. They create opportunities for others, they clear the road, they help when people are stuck. In short, they make everyone around them better. In many ways, that’s the gig.

From an assessment perspective: Increasing the productivity of a large number of people by even a small amount is incredibly valuable to any organization. People who only focus on their own success, especially if it is at the expense of others, are unlikely to be rewarded.

“Strong people don’t put others down… They lift them up.”

5. You seek help often and share credit

Even Great Engineers do not know everything (that would be kind of a sad situation actually) so you can expect to encounter things you do not know. Problems you do not know how to solve. Equipment you’ve never used. Whatever.

I’ve often heard people earlier in their career report that they were afraid to ask for help because it would make them seem to be weak, or uninformed, or something of that ilk. But again, this is backwards. If you succeed with help the key word in that sentence is .

Great Engineers are always looking for opportunities to learn and collaborate; They often lead into areas they do not fully understand and in so doing inspire others to come along and do amazing things. They pick opportunities based on what they are likely to learn and who they might get to learn from and then make it happen. Then they tell stories about how awesome their team was.

From an assessment perspective: Creating opportunities for others to grow is itself invaluable. Nurturing your own growth and striking out into scary areas with backup shows that you are willing to take risks to do what’s right for the team. All of these things are going to make you look good. In contrast if you only work alone, or insist on a limited set of people you are less valuable.

“There are no problems we cannot solve together, and very few that we can solve by ourselves.”

6. You are egoless about your work

Seriously, it’s just code, get over it.

Defensive behavior about coding and code reviews is a hallmark of junior people. Its absence is found in the Great.

Even if you are a great coder and your output is 95% perfect you still need people around you that will help you get (at least some of) the other 5%. You need to seek that out and let them help you. And when they suggest things you must give them a lot of weight and incorporate their ideas. You don’t have to accept every little criticism but if you find yourself being inflexible, you’re almost surely doing it wrong.

When your output starts to include entire designs rather than just code its even more important to get feedback from people you trust, and use it. Seek out people who will challenge you, people who see things maybe a bit differently than you. Diversity is most likely to lead to the greatest improvements in design or execution, much more so than a double-check from someone just like you.

Even more important than being willing to accept feedback is to be willing to admit that you’ve been on the wrong track and kill your own work. You must not feel like what you’ve done is somehow special. Great Engineers see their mistakes and abandon their work quickly and ruthlessly.

From an assessment perspective: People who have trouble accepting feedback are invariable more difficult to work with and less likely to get great results. Contrariwise those who can listen, learn, and adapt are bound to succeed. People who continue on a course that is obviously flailing are a danger to their organization. They won’t be rewarded.

“ I don’t need someone who will always agree with me, I have the mirror for that.”

You don’t have to do all these things, but it all helps.

Written by

I’m a software engineer at Facebook; I specialize in software performance engineering and programming tools generally. I survived Microsoft from 1988 to 2017.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store