While I appreciate the effort put into development, I have some questions about the underlying premise.
1. How do detailed metrics about coding sessions, git interactions, and test runs actually leads to meaningful improvements in your productivity?
2. Assuming you have used this plugin for a while now, how does tracking these metrics correlate with better code quality?
I hope I'm not coming across as overly critical, as that's not my intent. I appreciate the effort put into the development of software regardless of the final intent.
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…
Congratulations on launch. But I don't like when number of hours is used to quantify my work. Because x hours of work is not necessarily a good representation of complexity / quality of work. Even the number of commits is not a good metric. I want to know what HN thinks and how they measure their productivity?
These "quantified self" stats provide countless insights.
One example.
There is a refactoring view in there. By time, by projects, even breaking the figures down by type of actions.
Benefits:
- Self awareness. It is hard to gauge how much time is spent refactoring. If your priority isn't to refactor but meet a soon coming deadline, these stats tell you whether you are adhering to the priorities.
- Quantifies. If you are trying to explain to your colleagues that you find yourself needing to do a lot of refactor for that particular project, you've got numbers to communicate. What's a lot? Some colleagues often ask.
- Evidence. Showing these numbers communicates better certainty than "I think I've been doing a lot of refactor on this project today"
Plus, oftentimes with visualisations, we don't know what we are looking for. Until we find it.
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.
I mean, that's something you should try to answer yourself, if you think you can extract any benefit from having these stats.
To me it's similar to a fitness app that can tell you things like time, speed, distance, elevation, but won't really tell you how to run better.
I have a hard time coming up with ways this could help my coding habits right away, but I think this would be on the user to find these, not the stats reporting tool, no? And if you find no real use, then it's maybe just not for you.
It's data. Creating a colorful dashboard turns it into information,
To get knowledge and action is another step.
The plug-in does what it says on the tin,
it's up to the user to make something of it,
or leave it as inert knowledge.
While I appreciate the effort put into development, I have some questions about the underlying premise.
1. How do detailed metrics about coding sessions, git interactions, and test runs actually leads to meaningful improvements in your productivity?
2. Assuming you have used this plugin for a while now, how does tracking these metrics correlate with better code quality?
I hope I'm not coming across as overly critical, as that's not my intent. I appreciate the effort put into the development of software regardless of the final intent.
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…
> What’s your Kasama score?
As with many of these "quantified self" stats it feels like it will result in a colorful and nice to look at dashboard...with no benefit.
One example.
There is a refactoring view in there. By time, by projects, even breaking the figures down by type of actions.
Benefits:
- Self awareness. It is hard to gauge how much time is spent refactoring. If your priority isn't to refactor but meet a soon coming deadline, these stats tell you whether you are adhering to the priorities.
- Quantifies. If you are trying to explain to your colleagues that you find yourself needing to do a lot of refactor for that particular project, you've got numbers to communicate. What's a lot? Some colleagues often ask.
- Evidence. Showing these numbers communicates better certainty than "I think I've been doing a lot of refactor on this project today"
Plus, oftentimes with visualisations, we don't know what we are looking for. Until we find it.
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.
I mean, that's something you should try to answer yourself, if you think you can extract any benefit from having these stats.
To me it's similar to a fitness app that can tell you things like time, speed, distance, elevation, but won't really tell you how to run better.
I have a hard time coming up with ways this could help my coding habits right away, but I think this would be on the user to find these, not the stats reporting tool, no? And if you find no real use, then it's maybe just not for you.
2. Use scripts to commit junk to local or remote repos
2a. Extra points if you use chatgpt, Claude, gemini beta alpha0 to generate junk commits
3. ???
4. Profit. Sit back for a few months or quarters. Interview for new jobs, and then bounce out of there