That's not actually the only issue, unfortunately. Steam did in fact accept Bitcoin for a while, but it was dropped in 2017, with Newell stating:
> “We had problems when we started accepting cryptocurrencies as a payment option. 50% of those transactions were fraudulent, which is a mind-boggling number. These were customers we didn’t want to have.” [1]
[1] https://finance.yahoo.com/news/steam-co-founder-reveals-why-...
That's quite interesting, I wonder how they were fraudulent as bitcoin transactions dont have chargebacks etc. In the article they also mention that the price for the game would fluctuate which seems to indicate they actually priced the games in Bitcoin. Normally price would be Euro, USD etc and price conversion to Bitcoin would be done at check out. I guess these were the early days though =)
When I started my career, no one did code review. I'm old.
At some point, my first company grew; we hired new people and started to offshore. Suddenly, you couldn't rely on developers having good judgement... or at least being responsible for fixing their own mess.
Code review was a tool I discovered and made mandatory.
A few years later, everyone converged on GitHub, PRs, and code review. What we were already doing now became the default.
Many, many years layer, I work with a 100% remote team that is mostly experienced and 75% or more of our work is writing code that looks like code we've already written. Most code review is low value. Yes, we do catch issues in review, especially with newer hires, but it's not obviously worth the delay of a review cycle.
Our current policy is to trust the author to opt-in for review. So far, this approach works, but I doubt it will scale.
My point? We have a lot of posts about code review and related tools and not enough about whether to review and how to make reviews useful.
I think its easy to add processes under the good intention of "making the code more robust and clean", but I never heard anyone discuss what is the cost of this process to the team's efficiency.