This is surely debatable, but the best code is readable by Engineers of Tomorrow with the least amount of effort.
Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you).
Don't focus on commenting about how. They can read the code for that, and those comments almost always drift from truth. Instead, focus on writing code and comments that describe the why. Consider describing what other approaches you tried, why you didn't use them, and why you went with the current implementation.
This especially applies if your solution may not be the obvious first answer.
Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them up to make new and grander mistakes, instead.
I think that is nice, but may not be aligned with what the company wants. If <golden coworker> is respected, well paid and promoted then by all means try to emulate them. if <golden coworker> is gold plating a lot of small projects that dont really help the business, and hackers are getting rewarded for delivering new functionality that the bosses want, then that route is better.
Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you).
Don't focus on commenting about how. They can read the code for that, and those comments almost always drift from truth. Instead, focus on writing code and comments that describe the why. Consider describing what other approaches you tried, why you didn't use them, and why you went with the current implementation.
This especially applies if your solution may not be the obvious first answer.
Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them up to make new and grander mistakes, instead.