Show HN: Karma, a CLI-first dev gamification engine | Hacker News Reader

Show HN: Karma, a CLI-first dev gamification engine

getkarma.dev

38 pointsthomas-vds16 comments

I'm sorry, but this is the stuff of nightmares. Everybody I know who hates reddit hates it for the reputation system - reddit karma is what makes it so full of shitty memes that get regurgitated again and again. Tying that sort of system into work (especially ones that docks points for things like introducing bugs! Try having a blameless postmortem after that!) is a god damned nightmare.

Not too long ago people in this community were pissed at workplace monitoring tolls that were introduced as wfh started due to COVID and Microsoft for adding individualised metrics in teams. I'm sure you have positive intentions with this, especially with incentivising micro-interactions like cheering teammates for good work. But whether or not you intend it to be a workplace monitoring system is irrelevant, with easy to see metrics it will become one. I dread the day I'll have to ask my coworkers to "cheer" me on PRs because I introduced a bug and my karma has gone down.

yup. all these companies trying to build crap that just builds drama and increases unnecessary competition and bickering amongst coworkers.

Yes.

Thanks for your frank feedback - I do share you POV on the risk of metrics being used for the wrong intentions. Nevertheless I do think that introducing a bug in CI/CD tests on master (because e.g. you did push directly on master and not on a feature branch, where introducing bugs is fine) is the kind of behaviour that as a manager you want to see reduced. If such things happen, as a CTO I'll anyway ping the dev to let them know they should watch out next time. Delegating this to a simple rules-based engine with rules that everyone agrees on suddenly makes the whole discussion much more objective and avoids human friction. All the while with the more positive cheering which is purely about sharing good stuff. When it comes to actual monitoring of productivity, the current rules don't really allow that, because we all know how hard it is to measure dev productivity (e.g., a single commit of 1 line can add as much value as a big commit of 20 files).

Counterpoint: If a 'bad' action is detectable with a simple rules engine, then it would be more productive to prevent the mistake than automatically chastise the dev about it.

If you want people to push to a test branch before master, just set your CI/CD up in a way that enforces this? Build proper infrastructure instead of reinventing the Stasi with more Black Mirror.

This is like counting LOC all over again, but worse. As soon as you introduce a metric, (some) people will do anything to win. Make a clique, cheer each other on an hourly base. Introduce a bunch of typos on the about page, tank the penality, fix each one as a separate bug. My points triple whenever I hit 10 green commits? Brb, setting up a background task that checks whether my commit was green and if so deploys it 9 more times. Good use of dev time and resources!

Who looses? Your silent wizard dev who could not care less about social gratification and (used to) work on the big picture instead of fixing an endless stream of trivial bugs.

I also disagree with the notion that you can/should outsource manager-dev interaction to such a program. If an engine can trivially measure a dev faux pas, it can also just prevent it in the first place. If something unforeseeable goes wrong, you need the "human friction" as you call it. Why? Because you want to actually unroot the root cause (call it 5 Why's or whatever) and not just finger-point someone, and you certainly don't want to tank someone's social score for it.

Please look at a database of engineering/software disasters. People die because engineers are dis-incentivised to speak up, challenge security assumptions or break things. Sometimes that includes testing stuff a whole week w/o pushing anything (which you punish) or breaking something (which you punish).

Sorry - the idea is well presented and your landing page is nice - but IMO this software somewhere between useless and harmful...

Agreed. In my comment, I mentioned this was similar to a social score like China.

> this is the stuff of nightmares.

Work gamification -- it's like dystopia, but with a (mandatory) smile!

The idea of rewarding devs from my team for following collaboration best practices first arose when I was managing a team of 6 junior developers, nearly all of them freshly graduated from coding bootcamps. I was losing a lot of energy to remind them about the need to quickly fix bugs, minimise WIP etc. And clearly, rewarding good behaviour with gamification works better than playing the blame game for suboptimal behavior.

As time went I got the chance to work with and manage more senior and incredibly talented devs - but still, some issues remained around sticking to our commonly agreed best practices.

Then came COVID and the full-remote setup and it also became increasingly important to keep regular interactions within the team, even micro-interactions when some folks don't get the opportunity to work together but still want to connect.

So I ended up building Karma initially as a side-project to learn Go during my paternity leave (oops). I've had a lot of fun building that little CLI with the Cobra framework (same one as the one that powers Github CLI). The front-end is built using Tailwind UI and Vue 2.

I hope you'll have good fun trying this out, and that like me you will also discover what a cool TUI looks like :) Go spread the good karma, looking forward to getting feedback.

This is really cute and well designed -- both the website and CLI tool!! Some feedback:

* I might be worried about businesses using this as an actual metric of developer productivity, rather than as just a fun game.

* the readme.md in the linux tarball is pretty useless, since it just contains instructions for building the CLI from source.

* the first time setup flow (where you run ./karma and the site knows it instantly) is slick as hell, I'm blown away!

* I can't use arrow keys to navigate or edit in the "any comment?" prompt, but I guess it's supposed to be short anyway!

Thanks so much for your feedback, indeed the project is still quite WIP but you know, shipping fast was the only alternative for me vs continuing to polish it forever ;)

I like the idea but what size dev teams do you imagine this working in? Seems like medium to large size teams in corporate companies with extra time on their hands.

Do you think this is basically a social score like China has?

Typically built for teams of less than 10 people, where everyone knows everyone and no one is hence ever reduced to their metrics :) The comparison with China's social score is a bit harsh IMO, as here there are no consequences for your "bad" behaviour, and on top the positive micro-interactions are fostered. When it comes to time it takes, goal is basically that it takes you less time than cheering via Slack (which you hopefully would do otherwise).

> no consequences

The screenshot on the landing page indicates some penalization for “breaking master” iirc

On the website I see there are ways to lose points for bad behavior “Broken build on master -200pts”, etc. It seems like a social score to me. Perhaps you can just reward good behavior?

So based on what you said, why would I just not message a coworker?: “Hey Dan thanks for pushing that bug fix so fast!” Personal acknowledgment and appreciation goes a long way. I’m not sure this score board really adds much more to that dynamic.

Another thing I’m thinking is...this is a “vitamin” idea, not a “pain killer” idea. Meaning it’s not solving a pain point so you have an uphill battle to convince folks to even spend billable engineering hours to try it out.

Sales advice: Seek to understand, respond less. Try to ask calibrated questions to learn why someone came to their conclusion/objection, over responding directly to it. This is where you learn the stuff that helps you iterate. I know it’s hard, it probably feels like you have to “defend” because it’s an “attack on you”— but it’s not.

Actually.. this same advice applies to people leadership too.

Also...it helps to thank people for their feedback. They took time out of their lives to help. :-)

One suggestion to avoid being a "social score" is to 1) Make the score private 2) Avoid numbers/points

Maybe use thumbs up/down instead and have approximate scores?

Reply on news.ycombinator.com