[logankeenan]

> You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change).

The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one time matters a lot

[Fr0styMatt88]

As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases.

It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.

[N_Lens]

What if you’ve become too curious and critical of yourself?!

[dolmen]

You're now a C.

[adamors]

The flip side of this is the "high performer" who is constantly refactoring legacy code because they can only understand code that they wrote. And then add overly DRY refactors all over the place that is a pain to then make specific again.