Yes, metrics alone are not sufficient here. But I did not want to include opinionated targets where optimization towards might be problematic.
For me, I had 2 reasons to look at the metrics: First, I wanted to split my work into smaller chunks and commit more often, and I wanted to track whether I achieved this goal. Second, it occurred to me that I was using some IDE refactorings a lot of times, but I was wondering where my „blind spots“ where, i.e which types of refactorings I was using rarely or wasn’t even aware of. This inspired me to track IDE refactorings in the plugin as well.
However, there might still be the use case of some kind of „trainers“ that could be included in the plugin that help you improving your coding. Running tests more often, continuously integrating your branches, committing more often - these are not silver bullet mechanisms, but they do make sense a lot of times and a tool might help here.
For me, I had 2 reasons to look at the metrics: First, I wanted to split my work into smaller chunks and commit more often, and I wanted to track whether I achieved this goal. Second, it occurred to me that I was using some IDE refactorings a lot of times, but I was wondering where my „blind spots“ where, i.e which types of refactorings I was using rarely or wasn’t even aware of. This inspired me to track IDE refactorings in the plugin as well.
However, there might still be the use case of some kind of „trainers“ that could be included in the plugin that help you improving your coding. Running tests more often, continuously integrating your branches, committing more often - these are not silver bullet mechanisms, but they do make sense a lot of times and a tool might help here.