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.
Related resources:
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: