They can work, but they have major issues.

1)For at least the first 6 months, if not the first several years, it will take more time and money to teach them than they generate. Why would any company do this?

2)As a hiring manager at company B, I see you apprenticed at company A. I have no idea if that means you're qualified. I can't trust company A to tell me, they're a competitor. Schools stand as a neutral 3rd party telling me that they've completed a set curriculum and should know that much. It's not perfect, but it's a start.

3)Some fields just have a huge amount of up front learning before you can be useful at all. Apprentice plumber? You can run and fetch tools and hold things in place while you watch and learn. Apprentice electrical engineer? You have no idea what inductance is on day one. There's literally nothing you can do. So basically at this point you're hoping the company sets up a school.

I suspect GP's point is that every malware blocker in every browser is likely to treat this kind of script as hostile, except for Chrome because Google are currently nerfing the ability for blockers to intercept hostile scripts in one of the most blatantly user-hostile changes they've ever made.

If Apple play along with Safari then every other browser and its malware blocking plugins are about to be toast in a huge retrograde step for Internet privacy. But not even Cloudflare is going to get away with blocking every iOS device if Apple continues to allow blockers to intercept this kind of script.

Did anyone mention recently that simultaneously controlling both the most popular web browser and several of the most popular ad-supported web properties might be a little anticompetitive, and that it's about time that Google was broken up? It's probably time for that drum to start beating a bit louder again.

Can we add "surprise and delight" to that list of firing reasons?

Probably some of

E) Users are purposefully using privacy blockers that don't leak details of their computer

  as well. Why should a website know my OS? It's serving HTML, it shouldn't make a difference to it.

Central banks do a lot of useful things, but they don't give currency a value (they can, however manipulate the value others give it by printing it, destroying it, changing interest rates, changing the amount of reserve banks need and the multiple they can lend, etc). What gives a currency value is supply and demand- the fact other people want that currency. Which is also what sets international exchange rates.

There's also the fact you need it to pay taxes, which sets a base amount of demand. But beyond that it's all supply and demand when deciding how much value it has against other currencies or physical objects.

WHich is different from crypto how? You print it from doing large amounts of useless work on a computer that provides no value and is immediately thrown out. Or the new proof of stake algorithms, in which you print it by having previously printed it. I'll take cash, thanks.

Why would you do that? If you're using it for non-strings, you'd never have used strncpy, you'd have used memcpy. Which is the same thing without the null termination rules of strncpy. You'd never use the str versions unless actually working on strings.

That might be why a feature exists, or maybe even why a particular paid library was chosen instead of another. That doesn't explain why the code is written the way it was, which is the point of documentation. Why the feature exists is the realm of the PRD, not the design doc.

Of course if those aren't securities, then the entire site is illegal as it's operating as a securities exchange. That's their legal argument for why they aren't gambling sites, and shouldn't be regulated by state gaming commissions. So expect the full might of all those prediction market sites to be lining up against that argument and for finding him guilty.

Scalping isn't, and shouldn't be, illegal. You own the ticket, you should be able to do what you want with it, including reselling it.

And no, getting rid of scalpers wouldn't make ticket prices higher. Scalpers exist because the concert ticket prices are lower than what the market will actually bear. If a theater full of people are willing to pay 1K for a concert and they sell the ticket for 500, a scalper can make a profit via arbitrage. The only actual way to get rid of scalpers is to raise the prices to the sky (like 2-5x current prices) and slowly bring down prices over time until they're all sold. But my guess is you probably wouldn't like that any better, as the end price would likely be higher than the current scalpers price.

What the hell does a rocket need NINE MEGAWATTS of electrical power for? That's powering-a-midsize-town amounts of electricity.

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).