20 years ago I thought these agencies were incompetent. Now I know that it was actually their peak. The FCC of prior administrations would document their goals, send out a notice for public comment, write a proposed rule set, hold a hearing, the make a rule. Now they make a rule, and everyone goes "That doesn't even make sense" then they switch it. It's not just the FCC: It's the DOJ, DHS, EPA, etc.

At least some of this will be stress. If you're enjoying something, then you won't be stressed. If you're feeling positive and delighting in what you do, then you won't be stressed in unhealthy ways. This looks similar to the Mozart Effect, which turned out to be that if you liked something, your brain functioned better.

Yes, charging around the stage playing rock music isn't exactly gentle, but it IS extremely good exercise for the heart and the rest of the body. Again, that's going to have positive effects.

(We can ignore Keith Richards in this model, as he's older than the universe and only created it as a place to store his guitars.)

Most posters seem to be assuming it's a scam. I can't possibly think of a reason why they might think that. (A few million, yes, but getting it down to one is hard.)

However, that's almost by the by. It's rated for 5G. 5G is old. 6G is the new standard and WiFi 6 has been around for a while now. If you're actually serious about designing a new phone from scratch, and have not yet released it, you'd almost certainly want it to be 6G-capable. Nobody in their right minds designs for yesterday's standards, when they're going to be competing with tomorrow's products.

This, to me, is far far more important than whether or not it is real. If you're designing a product for a market that's on its way out, you've got a serious problem. If you're clamouring for a product that's designed for a standard that could be phased out by the time you see it, then you're not thinking straight.

Why does this matter, if the product isn't real anyway? First, we don't know it's not real, we shouldn't assume that. But, second, it means that nobody thought it was worth bothering with taking the potential customers seriously. The customers are merely meat with cash. That's not an attitude I can respect. Whichever vendor is making these phones is worthy only of my utmost contempt.

The problem isn't the population. Bedrock can handle more than that. London isn't sinking because of all the people (and London is huge!), it's sinking because the ice sheet that pressed the Highlands deep into the crust has been gone for the last 10,000 years, resulting in the entire island tilting back to where it naturally should be. You could move London's population into the Great Glen and it would not make the slightest difference - London would still be sinking. The ice sheets were a whole lot heavier than a few tens of millions of people.

(Ok, it would make a difference. If the rich people actually lived in Scotland, the transit system and public services would see a thousand percent improvement inside a week. If they were also forced to speak Gaelic, English would vanish in a month.)

Aquifers can be deep. The aquifer that supplies the town of Buxton in England is so deep that it takes rainfall 5,000 years to rech it.

Every place? Fascinating.

There are towns in England and Wales that have been occupied for the past 10,000 years. Manchester isn't the greatest place on Earth, but I'm really not convinced it's going to start sinking into the ground any time in the next thousand years. If "short term" is longer than the remaining lifespan of the human race, I am not convinced "short" is really the right word.

"Short term" is only meaningful if it's shorter than the time needed to take meaningful remedial action, and the time it would take to remediate the problem in Mexico City vastly exceeds the time it will take for the city to crumble into oblivion.

The sun will not explode in 4 billion years. It's far too small. It might well run out of hydrogen by then, but that will simply cause it to swell. If, in four billion years, we can't find a way to drift the Earth outwards to remain within the goldilocks zone, then we're a failure as a species. Of course, we might well have built a Dyson Ring by then. Although, to be honest, if we were going to do that, we'd want to find a gas cloud that was about to form a stellar nursary and head there. If we arrive as the proto star fires up, we've maximum resources in the easiest possible form (a dust cloud, so no mining needed and minimal processing required), can build the Dyson Ring or Dyson Sphere by the time the star really gets going, and have another ten to fifteen billion years.

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

Small teams running the show is the new normal. AI coding assistants mean that software engineers must also be product engineers, well enough to explain how to build features from soup to nuts, to LLMs. I know. this is what I do for a living now.

You can turn off auto-updates, but you'll be sorry in other ways.

When you copy files to your computer, that's after you have clicked 'Install' or whatever (or passed the -y flag on the CLI). That's your consent to install the app, and copy the files that come with it to your computer. There is no additional consent required. What the fuck are they even on about with this clickbait nonsense?