Some additional questions:
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:
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
Do you need to work hard to be a high performer?
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.
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"
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:
But poor performance comes in all sorts of shades:
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:
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:
What would you rather have:
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:
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:
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:
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.