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 my series on 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 how I became an acting tech lead at Robinhood just ~1 month after joining.
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.