3 ms·

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

by d3nj4l 6y ago

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.

purplecats 6y ago
yup. all these companies trying to build crap that just builds drama and increases unnecessary competition and bickering amongst coworkers.
- kyle_martin1 6y ago
  Yes.
thomas-vds 6y ago
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).
- cmeacham98 6y ago
  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.
- blackbrokkoli 6y ago
  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...
kyle_martin1 6y ago
Agreed. In my comment, I mentioned this was similar to a social score like China.
Viliam1234 6y ago
> this is the stuff of nightmares. Work gamification -- it's like dystopia, but with a (mandatory) smile!

by d3nj4l 6y ago

purplecats 6y ago

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

kyle_martin1 6y ago
Yes.

thomas-vds 6y ago

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).

cmeacham98 6y ago
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.
blackbrokkoli 6y ago
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...

kyle_martin1 6y ago

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

Viliam1234 6y ago

> this is the stuff of nightmares. Work gamification -- it's like dystopia, but with a (mandatory) smile!