I can't speak to your office environment, but in all the offices I've worked in, I haven't been "forced" to interact with coworkers more than I want to. Being at the office gives me the option to engage in high-bandwidth IRL communication when necessary, and to not interact/ignore other people when I'm busy with something.
My personal answer to the titular question is something like "there's only so much you can do with our predominant programming paradigm (i.e. plain-text)". Programming languages specifically can only make incremental improvements and/or tradeoffs in that medium.
Tools like IDEs, debuggers, visualizers, etc are more interesting, but I think their effectiveness is also limited (and creativity constrained) by having to work in a plain-text world.
Moving beyond plain-text is mostly a social dynamics/network effects problem, and I wouldn't be surprised if the intersection between people who are good at figuring out that distribution × people are who are deeply interested in how programming happens is actually quite small.
Aesthetics matter to some people. I would be a little more sad if I had to plug in a chunky CCS charger rather than the relatively-small charger Teslas have now.
(To be clear, standardizing on CCS is likely a good thing and I'd support it, but, y'know … I'd be a little sadder)
IMO browsing to the location first, and then creating the thing in that spot, is fuzzy search. The equivalent to "plonking a shovel" would be knowing exactly where a file should go in the hierarchy and touching/creating it with a single invocation from the top-level.
"Create a thing here" is a really powerful interaction. You often start the process of creation by navigating near the relevant bit (path in the file system, module in the codebase, etc), and then realize that you need a new file/class/method/whatever in the specific place you're looking. A consistently-available "New" menu seems like a good primitive in the computing experience.
To me, someone whose gaming experience rounds down to "never", but who's casually interested in maybe playing some games, this looks very appealing. Switch form-factor but it runs PC games? I don't need to carry around a tower with me and sit in front of a desk and disconnect my peripherals from my other computer? Sounds great!
I can't really speak to the first question, but I know of a small handful of people (who are developers or software-adjacent) who are deeply familiar with nuanced GUI details and can consciously talk about them. Plausibly, many people have historically not noticed many of these details, but got them for free when most software was built with native controls … and because they were rarely noticed, they rarely get explicitly specced for UIs built on less-robust primitives.
I'm early in the tinkering/prototyping phase of a developer tool (not a text editor) that is native AppKit, and it'll stay that way if/when I release it.
I actually find myself a lot more productive (i.e. can build a given feature faster) with Xcode+Swift+AppKit than VSCode+Typescript+React+Electron[0], and the near-unanimous disdain for Electron-based apps here gives me a lot of confidence that being a truly native app might actually be its own selling point.
[^0]: I learned to program in the early iOS days, spending 3–4 years tinkering around before moving to web dev for the past ~7 years. This is my first project using Swift.
This line of thinking very likely has the causation backwards — Tesla is a complex-enough business that they can determine how much they're gonna make in regulatory credits, and then turn opex up or down accordingly, with profit being a downstream effect of that decision.
If you also have a direct line to your users, you could try asking them how much they'd be willing to pay for either some new feature that's about to come out, or for the right to early-access. Get maybe 3–5 data points and you should have a pretty solid case to management (either to charge retroactively for existing features, to charge new users for existing features, or to charge all users for upcoming features).
The tone map "flickers" on/off unpredictably and in a non-undoable way (when it's off it appears to just be a flat plain RAW). If I actually try editing a ProRAW file, the whole photo area gets covered in green or red rectangles on every slider tick — looks like a graphics driver bug.
For me, Halide lets me shoot regular RAWs, whereas the stock camera doesn't — I don't like working with ProRAW because it renders buggily in Photos and Lightroom and I don't find it worth the file size.
For my mom, her iPad (Mini) is her only computer, including for taking photos. She much prefers the large screen (vs a phone or camera-sized screen) and wouldn't know how to transfer photos over from a traditional camera.
I imagine my mom is pretty close to the average demographic that goes to theme parks in this way.
It does appear people are willing to pay those costs :)
Also, electricity transmission appears to be much more expensive than generation. On my PG&E bills in California, delivery costs 2.5x as much per kWh as generation for 100% renewable power.
I'd imagine sensor fusion in this context isn't a singular problem right? It seems entirely plausible that for Tesla's system, it's straightforward to integrate cameras where the resolution is known and data is homogenous in a certain way, and that it's hard to integrate and use radar data into that system.
Same reason you have heating units in your house/building rather than at a municipal heating plant … people want to buy self-sufficiency for their house/building, and it's easier than scoping/building large-scale projects and running wires and dealing with municipalities.
I'm not entirely convinced it's a good idea, but one convincing argument I've seen is that sensor fusion is hard and it's not a priori clear which sensor to believe when they provide conflicting information. It's entirely possible that they get better predictive accuracy from vision-only data then in the analogous situations with vision+radar data.
I imagine most people on HN would take the latter, but most people in the broader population aren't that bothered by ads, and most people would probably put up with ads rather than pay e.g. an extra $50 (especially if it's a side-to-side option, like an "ad-free upgrade").
I imagine for many (most?) people, it's not that they want the "internet connected garbage"; it's that they want the big 4k TV and they're wiling to put up with the garbage that comes with it.
Sure, but then you'd have the "config" for a job separate from its implementation. If I'm looking at the code for a job, how do I easily find when it's scheduled to run? If I'm looking at the config database, how do I easily get to the implementation of the job?
Putting aside the feasibility of migrating a large codebase that exists one way or the other, my point here is that these shouldn't be separate tools.
Oh this sounds cool! When I was writing this post I was thinking about ASTs and transforming them into domain-specific semantic graphs.
E.g. that `run_config` example would be a generic "method call" node in an AST, but a domain-specific AST crawler could recognize that a "method call node whose name is `run_config`" should be replaced with a semantically-meaningful `run_config` node.
And maybe that would be an interesting way to build up a conceptual graph of a codebase?