It's harder to learn the impact of your design decisions -- Seeing how software evolves to meet changing business goals and how the design choices made play out in the long run helped teach me a lot.
Coming up with a neat API that turns out to be difficult to modify in the future, or limiting in ways you didn't imagine would when writing it is a good learning experience.
Or seeing how long a system can survive growing usage -- Maybe a simple hack works better than anyone expected because you can just pay more for RAM/CPU each year rather than rebuild into a distributed fashion. Or the opposite, maybe there's some scaling factor or threshold you didn't know existed and system performance craters earlier than predicted.
I've thought about this a lot in relation to typescript over the years and had various opinions -- For some time I thought it'd be better if there was an implicit `await` on every line and require `void` or some other keyword to break execution like `go` in Golang.
But, eventually I realized the difference in pre-emption between languages -- Go can (now) preempt your code in many places, so locks and thread-safety are very important.
The javascript runtime only preempts at certain places, `await` being one. This means I can know no other code can be running without explicit locks around all critical sections.
Finally understanding the trade-offs, I no longer am as frustrated when recoloring a bunch of functions. Instead, I can appreciate the areas where I'm not required to lock certain operations that I would in other languages.
There is no preemption in Javascript. It is based on cooperative multitasking[1] (your await statements and non-blocking callback) which is the opposite of preemption.
If every line had an implicit await then it is indistinguishable from pre-emption, which I think is the point the person you're replying to is trying to make.
I'm pretty happy with our setup, though we use flags mostly for feature releases and only have a few long-lived ones.
State kept in a database table indexed on customer. One row per customer/flag name, only there when the flag is set.
We keep active flags names as constants and put into an array for easy looping in our admin ux. This makes it easy to find usage and clean them up after launch.
These are passed to the browser so the frontend can check flags, and via grpc context to any downstream services.
There was one in London I used to walk past all the time. It was a neat experience to shop there once, but the selection was very slim and ocado was even more convenient.
I'd always peek through the windows and it never had any shoppers.
> I'd always peek through the windows and it never had any shoppers.
My experience using these locations is that I entered, grabbed the items I wanted and just left. Because they were closer to convenience stores, I was basically speedrunning it. A drink and a sandwich? Maybe 30 seconds tops. There wasn't any point in lingering. I wonder how much of that changed the dynamics of how many people were inside?
My experience with London, Canary Wharf - I'm hungry but the darn Amazon app has auto offloaded. Spend 3 minutes re downloading with bad data signal. Buy sandwich. Meh - it was ok but normal check out easier for me.
Chancery lane Tesco who also had one - darn I don't even have the Tesco app, I guess I'll wait for a normal shop.
For me the system would be better if you could just tap your card like everywhere else rather than needing an app.
Coming up with a neat API that turns out to be difficult to modify in the future, or limiting in ways you didn't imagine would when writing it is a good learning experience.
Or seeing how long a system can survive growing usage -- Maybe a simple hack works better than anyone expected because you can just pay more for RAM/CPU each year rather than rebuild into a distributed fashion. Or the opposite, maybe there's some scaling factor or threshold you didn't know existed and system performance craters earlier than predicted.