emhauck

Yes, the tagalog meaning of 'companion' was the reason behind the name.

Yes, well noticed!

Yes, these are great questions!

When I look at my own experiences, I wouldn’t focus strictly on code quality and productivity in the narrow sense. What I mean by that is that my focus on smaller commits and smaller branches helped team members understand changes more quickly, making knowledge transfer easier. For branches where code reviews/approvals were necessary, this helped our overall flow because stories were not blocked that long due to long-lasting approvals.

Another point was that, with Kasama, I was able to track the runtime of long-running tests and build tasks, which allowed me to point at tasks where optimizations were needed. Otherwise, such discussions were always based on gut feelings, and improvements were usually postponed…

No, but who is the one interested in your improving? :-)

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.