There's an excellent HN thread that talks about this very question (that comes up on HN every now and then - what _does_ company X do that needs so many engineering resources?): https://news.ycombinator.com/item?id=25375921
TL;DR: Managing a taxi service (that's what Uber is in my mind, not whatever "ride share" means) that spans cities and states, never mind countries, is extremely complicated. To their credit, Uber manages to make it look simple to the end user, prompting such comments as "meh it's just a few screens how hard could it be", which is triumph of product engineering as far as I am concerned.
I, for one, found reading the text under the News section quite difficult to read. The combination of the font color and the spacing/kerning made it all appear like a character soup to me. It's possible this is something that has variable impact across populations though.
Generally speaking though, I do think trying to paint 90s websites as some sort of utopian ideal of function and design is purely an exercise in nostalgia and nothing else. It is entirely possible to make fast, responsive, accessible, well-designed rich websites today, all without writing a word of JavaScript (not that including JS by itself is bad or anything). Do not mistake anti-user functions like heavy weight analytics and user tracking libraries, or poorly optimized and ill-architected code bundles as the current "state of the art".
Only tangential, but I recently discovered that VS Code also picks up paths in `.ignore` to decided whether to include paths in search. I knew that `.gitignore` is automatically picked up, but was surprised when all of a sudden directories that weren't supposed to show up in file search started showing up -- it's because I had unignored them in `.ignore` for ripgrep. Makes sense I suppose.
It can be quite useful to check in project-wide shared editor settings so that everyone in the team is using the same linter/formatter editor settings. We do that in my team for VS Code settings and extensions, even tasks.
I haven't checked if there's a way to maintain a project-scoped _personal_ `.vscode` for those idiosyncratic settings or extensions you want applied to only this project but wouldn't be appropriate to foist on everyone else. I hope there is.
You're crazy if you think the target demo of "business leaders" and "thought leaders" aren't going to dump it into their favorite LLM first thing and prompt their way into a summary.
Why is so much of generated AI art so... literal? The cover art of this PDF literally spells out what the graphics are supposed to represent. The vast majority of AI visuals on LinkedIn are the same way. If this is what's in store as the future of art, at least commercial art -- feels like a huge step backwards if I'm being honest.
And anyway, what's the point of generating a massive tome like this on a topic evolving as fast as agentic software? Sure it will be outdated within months, if not weeks...
In this case, as a solo dev, it's probably quite justified to be honest. I doubt ConcernedApe would have really been able to continue solo-ing it with this level of success if he also had to maintain distribution channels, sales/returns, marketing, legal stuff on a global scale.
It's probably the big name studios who already have entire departments to do that kind of stuff that feel they're being ripped off.
I bought :( Loved the thing, but yeah batter life wasn't the best. Also noticed that app developers would sometimes not take into account the smaller viewport on the Mini, and so app views would sometimes look too squished or out of place. That 's a minor grouse though compared to the subpar batter life.
That's not always the right way to go either. A professional using a particular device on the daily will be proficient in its usage regardless of how terrible the user interface, simply on the basis of how often they use the thing. On the other hand, how quickly an amateur can pick up a device and start using it will be heavily dependent on how intuitive and instructive the interface is. These two can often be conflicting, though not always. For a product that has a lot of "amateur" users (many home appliances), a touch screen can often be the right paradigm to choose.
A classic example of this is the situation where an experienced cashier on an "analog" system can just fly through the buttons and complete transactions in no time, while at the same time a rookie would take that much more time to ramp up, figure out, and internalize the various button mappings. A darker interpretation of this would be that the system is optimization for fungible workers, where swapping out one cashier at will for another has negligible impact on productivity.
It's not really cooking, but I find it useful to defrost frozen meat in the microwave if I have forgotten to leave it out of the freezer overnight. Defrosting in a microwave usually means letting it run at low power for a long time (> 10 minutes depending on the type of meat and weight). Of course, I use the presets that come with my microwave to figure out the right time/power combination, so I definitely find that feature useful.
It's interesting (to me) that Model S/X units are only about 1% of all vehicles produced/delivered. Makes sense since those cars are much more expensive than Model 3/Y, but still.
TL;DR: Managing a taxi service (that's what Uber is in my mind, not whatever "ride share" means) that spans cities and states, never mind countries, is extremely complicated. To their credit, Uber manages to make it look simple to the end user, prompting such comments as "meh it's just a few screens how hard could it be", which is triumph of product engineering as far as I am concerned.
Related: this blog from Uber talks about the problem of serving market-specific configuration data at scale: https://www.uber.com/us/en/blog/how-we-unified-configuration...