I had a very similar experience. I stick to a 10 keyless keyboard (no numpad) but I gave up on the trackball. I use a wireless trackpad now because I ended up with pains in my thumb after a couple years of the trackball. I could probably have used a better quality trackball but the selection is/was limited.
vim support in IntelliJ is pretty good these days so that's a huge help too. I had to abandon emacs and my claw movements early in life...
I think the point was that users implicitly want content from these labels based on the music they look for. Not that they're looking for music from those labels or are aware of which labels produce which music.
I'm pretty sure as long as you drove around in the right car and lived in the right house while you neglected your family, society would still see you as successful.
I wish it weren't the case but it seems to be reality.
Sorry for being a bit vague but I didn't mean to imply there were tests. I meant test in the sense of "do whatever you did to check correctness" in the first place. You change the code, you should do that process again or at least some approximation of it. Automated tests make it pretty easy, manual testing makes it doable, stepping through with a debugger or dumping printing statements makes it painful and error prone.
Many codebases don't have tests at all, most have terrible tests, and under no circumstances do I think they magically prevent all bugs. But I do think obnoxious coders who assume they can just merge and move on without checking the correctness have a special place in hell.
Life sucks sometimes but it doesn't matter whether you merge or rebase in the scenario you describe, you need to test the combined version of the code. You can't just assume it is still working and whoever comes second needs to shoulder that responsibility.
I'm not sure about Clash but there are often game mechanics that kick in to heavily multiply your rewards. Spending $X gets you Y in game value but spending $2X gets you 5Y. And then it can compound with follow up offers targeted at the player/whale which may not be generally available.
So I don't doubt your figures but there's probably a "one week whale" trajectory that's built into it to give quick gratification for something like $250,000. Still seems outrageous but they can discount digital goods differently than retailers can.
Which just raises the question for me, why have the macros at all? I did C++ development for years (on low level and performance sensitive applications) but 95% of the macros I saw were there to reduce lines of code or "eliminate boilerplate." Almost all of those could be eliminated by refactoring within C++, without resorting to the preprocessor, but developers love using macros...
I learned Ruby before learning anything about Rails. I've used it off and on professionally for 7 or 8 years for production services, testing, and random glue/batch code.
It felt super powerful and refreshing when I was doing C++ daily. And after Perl it seemed like a nice improvement in syntax and readability to me.
But... Time has not been kind to my views on Ruby. All that promise turned to ashes in my day to day.
All that flexibility and expressiveness led to subjective code reviews and inconsistent styles across files, let alone projects, being worked on by the same team.
All that metaprogramming goodness lead to very robust, extendable classes and modules.. that were never extended. They were copy-pasta'd to a new codebase instead because testing the metaprogramming to support both variants was too risky for the project. And once there were two deployed forks no one ever approved time to consolidate them so then the third one was forked...
Working with Rails for some internal sites a couple years ago was like my whole Ruby experience in miniature. Started happy and very productive (ahh, generators! I'll just get my boilerplate started.. Rails guides! Actual documentation...) Then it was a little bumpy.. (Ok sure, convention over configuration. But where are the conventions listed? What options are there?).. And then magically working for almost everything. Then I spent three times as much work fixing the last 5% of my issues because they were poorly supported/unusual features, impossible to configure within the default Rails knobs, or basically just growing pains in moving from development to deployment environments.
I don't consider Ruby as a hipster language and I formed my opinions of it based on the core language not Rails. Not saying there aren't people who match your description, just offering a different view. I'd summarize it more as Ruby-fatigue.
Ruby "in the large" is pretty tedious and working with larger teams has lead to friction (even with good teams trying to be proactive with linting, style guides, code reviews, automation). So I still use it, but it's a "better Perl" for me now. If it's a one file script it's in bash/Perl/Ruby/whatever, if it's a couple files for a utility it's probably in Ruby, but if it's something new and I expect it to be more than that I'll pick something else.
I didn't really grasp this until I moved to the US... They don't fucking care what makes sense around some issues like this. I've asked seemingly rational colleagues, who work as professional developers, about SSN and national IDs. They've all been completely opposed. Even if they otherwise offer solid opinions on security.
Something something, Nazis, something, Hitler would've been even more successful if the Germans had national IDs. Can't trust the federal government to do it.
But then they tell me to keep my SSN secret, forever, except that I need to give it to people all the time, and they use the last four digits of it as verification all the time.
So you've got a shitty defacto system with zero integrity, basically mandatory use, and that can't be changed. They even print it on paper cards to discourage its use as an id. There is a US national ID. It just sucks and they won't admit how they use it in practice. Sigh..