What's the difference between a low performer software engineer and a high performer?

This is going to vary a lot across teams/orgs/companies, so I'm going to start with a couple commonalities I've noticed across low performers in general:

• Didn't take feedback well - This led to them being unable to course correct, which was just asking for trouble.
• Uncollaborative - I don't think I have ever seen an engineer who was very active socializing and working well with other members of the team (asking great questions, helping them out) also be a low performer. When I saw engineers get cut for performance, they were either toxic and actively didn't get along with teammates or were more lone wolves that stayed in their own corner and did their own thing.

Both of the above failure modes are heavily tied to communication skill. For anybody worried about struggling with the above 2, I heavily recommend watching this: Alex's Guide To Effective Communication

Big Companies vs. Small

• When it comes to big companies, I've seen low performance from poor communication and code quality (on top of the above 2 things). Expanding on the poor code quality portion, they often had bad attention to detail in general.
• In small companies, I feel like it's more about code velocity, since that's a much higher leverage thing to do there, especially in startups. However, smaller companies have a ton of variance, so this won't be true a lot of the time - I know small companies that actually do value code quality over speed.

Do you need to work hard to be a high performer?

• Generally yes, but it's not required. I am assuming the more "traditional" definition of working hard meaning a decent amount of hours.
• Some companies equate many hours of work to quality of work, which is rough.
• In the end, software skill is largely a matter of doing, which requires time. This means that it's inherently hard to become a good software engineer without spending a lot of time. I've rarely seen software engineers who just "got it" and were able to have tons of impact and growth while only working 2-4 hours per day or something.

In terms of what makes a high-performer software engineer, there is simply too much to cover: There are so many creative, deep ways software engineers can add a ton of value to an organization. If I were to pick one resource in all of Taro that covers a good amount of these skills, it's my in-depth breakdown of my rapid Robinhood onboarding: [Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta

There's a ton of nuance in this topic, so I recommend going through the related resources below as well.

Related resources:

• "Is it possible to do well at a SWE job working less than 40 hours a week?"
• "How does work-life balance shift across levels?"
• "Advice for someone joining big tech from a non big tech background?"

This is a good question but also very generic. It really depends on the level, the context and the priorities of team. The expectations & areas of focus are very different for different levels.

If I must generalize, a "high performer" are able to do two things compared to a "low performer"

• be self sufficient and able to drive large changes on her/his own.
• be able to share their learnings with others and increase the team efficiency as a whole.

In both cases, it comes down to business impact. Write and rank your list of priorities by business and economic impact. Identify the highest-ranked priorities. Talk about your assessment of business impact with your manager. Work on them all the time. Do not let the tyranny of the urgent keep you focused on low-value work.

To riff on Anna Karenina, great performers are all like; every poor performer is poor in their own way.

Somewhat tongue-in-cheek, but these things are all true of high performers:

• Higher impact than others of the same level. (Remember, all performance is relative. Any high performer would be a complete dog if you promoted them to the right level.)
• Responsible / reliable. You don't doubt they'll get done what they say they will.
• Great collaborator. Increasingly fewer companies continue to value high-impact jerks.
• Great at self-improvement. Alex's comment about taking feedback is spot-on here. The best performers are self-aware, accept others' feedback, and implement feedback effectively.

But poor performance comes in all sorts of shades:

• Icarus. People who ask to be promoted too aggressively will likely land at a level they can barely compete in. Since all performance is relative, getting promoted too quickly is one of the fastest ways to become a poor performer.
• Self-unaware. There's a t-shirt that says, "The only common thing in all your failed relationships is you." Setting the joke aside, there's some real wisdom in there. If you could instantly accept and implement any piece of feedback given to you, you'd be an amazing superstar. The fact is that people don't accept feedback half the times, and the other half, they struggle with implementing said feedback.
• Motivationally challenged. "There are no boring things. Only boring people." Anybody who thinks it's their manager's job to make their job interesting is going to struggle long-term. Smart people are curious and they find the interest in nearly everything. You need to have your own goals and a strong drive to succeed.
• Lackadaisical. If you're just as smart as everyone else, and you work just as hard as everyone else, you're average. By definition — not being cheeky. When I started at Microsoft, I had a sleeping bag in my office and worked ridiculous hours. While I now view that period of my life as foolish, you can bet I outperformed everyone else my level, and by a significant margin. Anyone telling you that you can Have It All™ — work only 40 hours a week, marry a supermodel husband/wife, have IPO after IPO fall on your head — is selling something. You will outperform others only through three means: 1. luck, 2. talent, and 3. hard work. You can't control 1 or 2.

There are way too many other ways to be a poor performer to continue listing them. But I hope this is a helpful start.

Taro has come a long way since I originally commented on this post, so I have a bunch of new thoughts. In particular, I didn't cover high-performers too much before, so I'll do it now.

When it comes to high performers, there are 2 big core traits I have noticed:

1. They are exceptional at learning from others from them, both directly and indirectly.
2. They develop higher-level skills that are applicable everywhere across any team, any tech stack, and any given situation.

Learning Through Osmosis

By being able to quickly absorb good behaviors, expertise, and skills from their peers, this makes it so that once a high-performer finds a great team, they are going to grow like a rocket ship. Here are some excellent resources covering this:

• Use Code Review Feedback For Hypergrowth - Meta Prodigy Engineer Story
• This Is How You Get Feedback - Making The Process Smooth
• Suppress Your Instincts And Treat All Feedback As A Gift
• Properly Learning From Software Engineers More Senior Than You

Developing Better Skills

What would you rather have:

• 1 skill that makes you tremendously useful in 1 type of situation?
• 10 skills that make you at least moderately useful in 1,000+ different types of situations?

The first is a common failure mode for struggling software engineers: They focus too much on the tech and only become good at 1 specific tech stack (i.e. the one used by their team). Sure, they're the most useful person in the world when there's a tricky task in Python 2.7 and they have written Python 2.7 for the past 10 years. However, this also means that when they're put in a non-coding situation or a different team, their usefulness plummets to near 0.

The second is what rockstar high-performer engineers do. Of course, they'll develop the technical proficiency to accomplish the tactical parts of their job, but they're also getting good at skills like communication, building relationships, and time management. This means that no matter the situation, they have this solid bedrock of fundamentally useful skills to fall back on. This allows them to always add value, whether it's through effective project management or asking insightful questions.

To learn what more about those fundamental skills, check out these awesome resources:

• "What are the Core skills a SDE should be consistently developing?"
• "What are product skills and how to develop them in the age of ChatGpt and CopilotX?"
• "How to develop soft skills like leadership, stakeholder management, etc.?"

I'll illustrate high performance with the story of my friend from college. We were taking the classic Stanford weeder class, CS107, systems programming in C. This class was extremely difficult since it was the first time we were exposed to:

• Writing sophisticated C code
• Managing our own memory, e.g. malloc() and free()
• Using the command line and CLI-based text editors like vim/emacs
• Figuring out how to compile and run programs with Makefiles

The learning curve was steep. Most people, including me, would wait until the last few days before the deadline and then attempt to speedrun the assignment. But there were too many moving parts, too much to understand, for this to be feasible. I became overwhelmed.

On the other hand, my friend made methodical progress every single day. He wouldn't try to get the whole thing done in one go, but he'd create mini-milestones: today he'd dive into Makefiles, tomorrow he'd understand valgrind, and the next day he'd achieve milestone 1 in the assignment. Needless to say, he not only aced every assignment, but he also had enough time to extend projects for extra learning (and extra credit).

Two unique behaviors that led to his success:

• Proper decomposition led to focus. At a certain complexity scale, you need to break problems down and tackle them one at a time. You need to not only figure out the decomposition, but also how the pieces fit together once you solve each piece.
  • Attempting everything results in achieving nothing. You can't learn AI, blockchain, and the newest JavaScript framework simultaneously.
• Steady progress led to deeper understanding. One pernicious trait of weaker engineers is second-guessing themselves: they'll think component A is responsible for a bug, but then some other data leads them to another conclusion.
  • Same thing with building systems. You want to make methodical progress so that you emerge with a rock-solid understanding of the tool/system (can you teach others?)

My friend is now a Senior Staff Engineer at a company in San Francisco valued at $9B, operating in one of the most senior roles. The path to high performance is simple but not easy: show up consistently and put in the effort over an extended period.