This conclusion from the linked-to study [0] resonated with me as a programmer: "Excellence is a qualitative phenomenon. Doing more does not equal doing better.

This conclusion from the linked-to study [0] resonated with me as a programmer: "Excellence is a qualitative phenomenon. Doing more does not equal doing better." And in another section: "Excellence is mundane. [It] is accomplished through the doing of actions, ordinary in themselves, performed consistently and carefully, compounded together..." Programming can be a solitary practice. Even if you're working with a team and using GitHub, there's a lot of quiet, introspective time, during which you draw on your own skills and judgement to make small decisions about code. Because of this autonomy, it's easy to revert to the programming languages, frameworks and workflow that you find most familiar. Many programmers answer to managers who are outcome-oriented; they tend to care more about the end result than the minute technical decisions made along the way. But minute decisions, whether they concern optimization or design patterns or frameworks, are compounded. Taken as a whole, they can affect the look, feel and performance of a software product. For this reason, I'm inspired by the swimmer's commitment to slow, persistent improvement — approaching small decisions deliberately and thoughtfully, with the realization that they add up over time. I think the take-away for programmers is that we should focus not only on the quantity of problems solved ("Show HN: I made 101 apps this year!"), but on approaching small decisions with a fresh, qualitative perspective ("I tried switching up my workflow and experimenting with new techniques"). [0]: http://www.lillyfellows.org/Portals/0/Chambliss-Mundanity%20of%20Excellence.pdf http://www.lillyfellows.org/Portals/0/Chambliss-Mundanity%20...