On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it.
Users should be everywhere, in and out of engineering.
There are many leaders that use information as a tool that serves their own needs.
They may have the context, but they are either too focused on their own job to share it, or actively manage dissemination so they can manipulate the organization.
In my experience, this is the typical operating mode, though I do not think it is sinister or malicious - just natural.
The whole point of micro-services is to manage dependencies independently across service boundaries, using the API as the contract, not the internal libraries.
Then you can implement a service in Java, Python, Rust, C++, etc, and it doesn't matter.
Coupling your postgres db to your elasticsearch cluster via a hard library dependency impossibly heavy. The same insight applies to your bespoke services.
In practice, there are a number of factors which make using Kelly more difficult than in toy examples.
What is your bankroll? Cash on hand? Total net worth? Liquid net work? Future earned income?
Depending on the size of your bankroll, a number of factors come in to play. For example, if your bankroll is $100 and you lose it all it's typically not a big deal. If you have a $1 million bankroll, then you are likely more adverse to risking it.
What is the expected value? Is it known? Is it stationary? Is the game honest?
Depending on the statistical profile of your expected value, you are going to have to make significant adjustments to how you approach bet sizing. In domains where you can only estimate your EV, and which are rife with cheats (e.g. poker), you need to size your wagers under significant uncertainty.
What bet sizes are available?
In practice, you won't have a continuous range of bet sizes you can make. You will typically have discrete bet sizes within a fixed range, say $5-$500 in increments of $5 or $25. If your bankroll falls to low you will be shut out of the game. If your bankroll gets too high, you will no longer be able to maximize your returns.
At the end of the day, professional gamblers are often wagering at half-kelly, or even at quarter-kelly, due in large part to all these complexities and others.
Run valgrind on any large successful code base and you will find tons of memory corruption. It just happens to occur in places where it does not matter.
If you pay a lot for parking or don't use the car much this tracks. But if you have the volume, then owning a car is cheaper.
An affordable mid size car costs roughly $6k per year total cost for a new car, and about 2/3 that for a used car.
If you commute daily to work, that is 500 trips per year. Two weekend trips adds another 100 per year. Now we are talking about ~$10/trip if you own your car.
When you add the premium value you get from flexibility, then it's an even better deal. If you only drive 50x a year then yeah, just use services.
This does highlight the gap between SOTA and business production. Google search is very often a low quality, even user hostile experience. If Google has all this fantastic technology, but when the rubber hits the road they have no constructive (business supporting) use cases for their search interface, we are a ways away from getting something broadly useful.
It will be interesting to see how this percolates through the existing systems.
There's not much to elaborate, tons of practical use cases for search, sort and storage rely on alphabetization. If you move through an analog world of organized data, you'll find and develop many practical approaches to interacting with data based on knowing the key and the alphabetic ordering. Whether it's a phone book, a map, a dictionary, or filing systems, alphabets were always used as an indexing mechanism.
It might be better to ask the inverse. Which "AI Safety" experts are worth listening too. I have found very few, and the ones that I've found worth listening to are much more concerned about practical issues that impact systems today, as opposed to the ones that are just author fiction.
The crazier thing is that most advocates of "AI safety" don't know anything about "AI safety". By and large the term is marketing with very little objective scientific development.
It is essentially a series of op-ed pieces from vested interests masquerading as a legitimate field of inquiry
You should be very skeptical of anyone that claims they have 100% test coverage.
Only under very rare circumstances is 100% test coverage is even possible, let alone done. Typically when people say coverage they mean "code line coverage", as opposed to the more useful "code path coverage". Since it's combinatorially expensive to enumerate all possible code paths, you rarely see 100% code path coverage in a production system. You might see it for testing vary narrow ADTs, for example; booleans or floats. But you'll almost never see it for black boxes which take more than one simply defined input doing cheap work.
Deprecation should not break anything. At some point the code will be removed and the org will have to pin the version until the deprecations are resolved.