j4k0bfr

Gadzooks! I must launch my homelab into LEO, stat!! Quick <local LLM>, start me a space program!

> Surprisingly, I haven’t found a solid answer.

God, what a good pun.

I agree, organisational creep can kneecap a lot of different projects.

However it's my (mostly vibes-based) opinion that it impacts software more than most. Imo, disciplines with more stability benefit from knowing how many people are needed for specific roles, and probably don't step on each other's toes so much. Software projects often end up sharing so many interface points between devs. I can't imagine the amount of headaches a 100 strong org would generate when someone breaks CI, lol.

Coupled with the speed at which our industry changes (game engine updates, hardware evolution, new language hotness etc etc), it feels like there's no time to find the 'best' organisational strategy yet.

Unfortunately, it's impossible for us to verify what parts of the demo are 'realistic'. Did they use assisting technologies (e.g. a wire rig)? Is anything repeatable, or are the components one-and-done?

The software industry has taught me how sneaky a demo can be ;). That's without considering Tesla's history of bonkers claims and sus demos (anyone else remember the bulletproof windows?).

Edit: Removed a rhetorical question about the demo. Apparently there was a live audience, so they couldn't have just made a very tiny Roadster haha.

It's only incredible engineering once it performs in the hands of buyers. It's an incredible demo until then.

I feel like it's also crazy irresponsible to sell this deathtrap to the public, since it's pretty much guaranteed buyers will joyride this on public roads.

- The cold-gas only version will shotgun debris into onlookers, and possibly yeet anyone behind it.

- Active suction is very cool until a rock punches through your intakes.

- Lithium batteries and pressurised tanks in the same package, yippee!

Thank god it'll take them years to manufacture this thing.

Very cool stuff but all the "extra-terrestrial" stuff is complete bunk. This thing wouldn't survive Max-Q, let alone any kind of landing that isn't on a clean slab of concrete. It's a cool rich person toy, no other notes.

I'm happy to admit I don't really know what I'm talking about with this bug, however the ability to leak memory is pretty demonstrable, no? The OP's example of using a global cache with Drop seems a bit gross... but that hasn't ever stopped C devs lol (as a proud C dev myself).

I guess my take is that I'd rather assume this is exploitable in the wild until sufficient time has passed. Would be cool to see clippy pick up on this bug in older versions!

Took me a good couple minutes to wrap my head around. Man, what a nasty bug. I guess this specific use-case is rare. Time to see if any of the big libs are affected...

I wouldn't be surprised if many of the motorsport software engineers you mention come from mechatronic/electronic/aero backgrounds. Don't get me wrong, I've seen an analog electronic engineer perform software wonders; 10,000+ lines of bash, custom C macro libraries, and a PHP runtime older than I am have taught me that programming can be closer to art than science. But relying on that cursed bundle of chaos felt deeply violating and unsafe lol.

Nowadays, I mentally place any engineer without production software experience into a 'research' box. Any resulting code may break the laws of physics, and should be tested as such ;).

Edit: It's also a minor crime to look down on automotive software engineering! The stakes of mass-manufacturing have forged some seriously awesome software. Top-of-mind for me is CAN support in Linux and safety-critical contributions going into ROS2.

With something safety-critical like an ECU, I'd be surprised if they left formal proof out of their software design and testing. This would make unexpected hardware behaviour much more likely imo. I guess I'd get around it by setting up automated hardware-in-the-loop simulators for testing every possible environment and input. Surely the cost would be worth it for F1 as a whole.

At a startup I worked at, we jerry-rigged Pi 5's with commercial of-the-shelf environmental sim software to achieve this. Very cost effective, lol.

I agree with your first paragraph, a majority of corporate programming jobs probably suck. However I'm not convinced that AI will reduce demand for these positions to in a major way. It will instead change the required workflow. I've got a couple of industrial revolution points I'd like to share; The Jevons Paradox addresses demand concerns. Software is now theoretically faster and cheaper. More projects are now financially viable, since total unit costs are down! The other side is the Automation Paradox, where now even more specialised knowledge is required to fix and maintain AI systems.

Your disenfranchisement is valid, however fortunately (or unfortunately?) do-nothing soulless corporate programming jobs have a good chance of sticking around, if in a changed way.

Comparing programmers to farriers is definitely strange on the surface. However I think it's quite unfair to reject the authors premise due to the ephemeral nature of some software. And I think it's downright arrogant to assume moving from horses to cars wasn't seriously challenging for his ancestor. But yeah, I would love to chat with the old man about what that transition looked like.

Also, AI adoption might look like it's moving fast for individuals, however I see many companies struggling to actually utilise it effectively. Business processes are slow moving political machines. Sure a large part of the software industry is ephemeral, indirectly providing capital value. However many jobs are still very tangible; embedded, backend web systems, networking etc etc. Instability in these systems absolutely results in tangible loss of value.

It will absolutely take decades before we figure out 'correct' AI usage at an industry scale. Heck, even frontier labs are still undecided about best practices.

P.S. ty for the article link, will read!