No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.

Now if you're imagining some alternate world where programmers an be moved at will- then we're already one big team instead of multiple small teams.

And no, a smaller team doesn't win every time. If it did, then then smallest team possible is teams of 1 and we'd all do that. There are sweet spots, which depend on the organization, the work to be done, and the importance of that work. For some that's bigger, for some smaller. I've definitely worked on teams that were both too small for the work, and that were too big.

They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.

They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.

In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.

There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown to low technical knowledge customers frequently (in other words anything that actually needs weeks or months of backend work, algorithm writing, or infrastructure to be written).

The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.

There are a couple of ways to solve this problem:

1)Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.

2)Each manager managing multiple independent teams. This can work if it doesn't overload the manager. The biggest problem is when the manager decides one team is more important and doesn't support the other(s) enough. This works better the closer the teams are, as it requires the manager to know fewer sets of collaborators and politics

I get sick after 10 minutes last time I tried it (a few years ago). It's not anywhere near solved. Of course I have no desire to try the new versions, because even if it was solved it doesn't actually make anything useful better.

Side mirrors almost always leave a large blind spot directly behind and close to the vehicle. There's a reason that when firefighters are reversing their appliances they always have at least one of the crew physically get out and watch the area behind the vehicle.

Even a rear window and rear view mirror almost always leave a significant blind spot low and close behind the vehicle, which is why reversing cameras became a thing. When they're done well, they really are significantly safer, as well as sometimes making it a lot more reliable for most people to park the vehicle in difficult spaces.

One of the modern innovations I really would like to have is full AR on my windscreen. I want unexpected hazards highlighted in real time, particularly those that are more easily detectable by non-visual sensors, like big potholes or animals obscured by vegetation near the side of a country road. I want the actual driving line I need to take to follow my planned route through complex junctions overlaid slightly on my view of the road ahead. I want light amplification for night driving, ideally combined with some other technology that can reduce the glare from oncoming headlights to prevent dazzle.

Although I only want all of this if (a) it's implemented well and (b) any additional data it uses is reliably up-to-date and (c) there's an emergency shut-off that instantly clears everything off the windscreen in case anything goes wrong.

Don't worry. You probably have funky modern door handles that don't work when the power goes out anyway. Not that the power in an EV is likely to go out if it's underwater or on fire or anything.

Oh, don't be silly. Next you'll be making even more absurd claims, like that car theft was already a solved problem 20 years ago thanks to immobilisers, or that having separate physical controls for essential functions that you can find and use without taking your eyes off the road for several seconds to mess around with a touchscreen is safer, or that no-one ever hacked 100,000 cars at once from 1,000 miles away back when they didn't have always-on remote connectivity and allow OTA updates to their essential control systems.

Yes, as long as you're the one in the big, heavy car, it's great. Shame if you're the kid it's reversing over though.

Do you ever use reverse gear? What's behind you is pretty important when you're going backwards...

Yes, Apple's shared RAM model really works for them in the context of running LLMs locally. It's a huge advantage. As you say, not much use for those running other platforms, though.

I'm impressed that anyone can afford a new development PC in 2026. I'd need a second mortgage with the price of the RAM, SSD and GPU these days!

Back in the day lots of people did. Because there was no built in browser to use before IE came out. And pirating it would require getting a cd from someone else, and cd burners weren't a thing yet. Your options were use AOL with whatever they had built in on their cds, or use Netscape which you'd need to buy.