the example I like to always use is when EA kept abandoning Madden (especially online franchise mode and gameplay) for like 10+ years straight (while making money hand over fist on MUT).
One time there was this new mode, for like 1-2 years, of 3v3 online. it was probably the most fun mode madden has ever had. it just needed a few tweaks. sensible stuff. But it would've been amazing!
but no. because it was difficult to get to in the menu system, fewer people used it and few people knew about it. so of course telemetry is going to say few people used it. but it had a TON of potential! a product owner made the wrong decision to cut that feature, and guaranteed they used misleading telemetry to justify it.
the docs/paper for roaring bitmap says it's to be used for large datasets, but I must have missed where "large" is defined. In practice, how large does a set have to be to take advantage of roaring bitmaps?
The essential consideration is that roaring bitmaps are compressed — trading increased CPU overhead per read/write, for lower size-on-disk => more rows fetched per IOP + better cache-coherency. So think of the point where the CPU overhead of compression/decompression for every read/write becomes worth those gains.
Most developers make this kind of judgement every day: when deciding whether to e.g. gzip a file before SCPing it somewhere; or whether to apply e.g. lz4 to the data being written to a KV store like Redis. IMHO that same intuition applies here.
Mind you, the compression in roaring bitmaps is very efficient, has extremely low start-up costs, and is effectively "random access" rather than streaming; these low costs are why roaring bitmaps are preferred over other compressed-bitmap approaches.
And also, it not like, at small data sizes, even a "large" (hundreds/thousands of ops) CPU penalty would really be much of a penalty, either — because, with small data, you wouldn't be paying it very often! And within a "heavyweight" RDBMS like Postgres, that does a bunch of things when you make a request to it, these sorts of small CPU costs usually get lost entirely under the static overhead of query planning. (Postgres takes advantage of this property in a lot of other ways as well.)
It's only when you're trying to do something at scale, but where dataset size isn't the scaling factor (example: running a core DNS server — trillions of queries, but against only a small amount of data) that a roaring bitmap would be an explicit "wrong choice" vs. a sorted-list or b-tree or hashtable-backed presence set.
Not a good idea if you're frequently sending things that are already compressed, though. Which many formats today are.
(Also, I was using `scp` as a general abstraction; personally, I'm not often pushing things around between VMs directly, but rather between VMs and object storage; where part of the question is not just about the transport encoding, but rather whether it's worth it to have the data be compressed-at-rest in the object store. Usually depends on how many times you're going to be downloading it.)
in an organization that large, the 10 managers in your scenario would have to be some of the most selfless and honest humans, all able to communicate freely and openly without envy or ulterior motives.
In most companies those 10 managers are not a team, unfortunately. It's more like there's a "top" manager who has 10 separate sub managers of 10 teams. But those sub managers are mostly independent. At least that's how it is in most places, communication between middle managers goes up and down, not sideways.
What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.
DONT keep your head down though. That's part of the problem. Get out of your bubble/headspace/etc and talk to other devs. Compare approaches. Reach out to others to see how they're solving problems. Even problems you're not having. Especially those actually, for when the time inevitably comes when you have to deal with those issues.
As a new person you can't possibly know everything. If you dont have someone showing you the ropes then you have to take initiative and talk to others.
much less time wasted in between meetings.
they definitely also get more done