It saves some money with some jobs, but it raises costs in other areas in ways that aren't immediately obvious to middle managment (or IT management who often don't care about the other departments). Slower service, slower development time, prices that rise because the initial tier of cloud service wasn't sufficient, higher prices for expanded network bandwidth needed for the cloud, etc.

You still need local IT people for basic support needs. And those numbers dwindle when the cloud is used and they decide they want outsourced IT as well. Operating on a shoestring budget is fine, but you also get shoestring service.

Downtimes are often completely out of your control. In-house, you can still use servers even when the internet isn't accessible to the outside world. I have seen more downtime with Microsoft Azure DevOps than I have with the previous in-house environment. An outage at a major cloud supplier affects you, but probably hundreds of other companies. at the same time. You also still want local backups, or backups at a third location - don't trust your cloud provider to do it properly or to restore in a timely manner (no matter how important you think you are, the cloud provider doesn't care). At times latency is just awful as well.

Sometimes bare metal is needed - not often, but when it's needed it should not be dismissed merely because the cloud won't do it cheaply. If you've got overallocated usage of the real hardware, some tasks won't work well in either a container or VM. Ie, a simulation that could run reliably on a PC with 32or 64 GB but bogs everything down in a VM. Cloud services are not very flexible, you don't get custom solutions.

I have seen that with IT abandoning their own ownership of servers, that departments and divisions sometimes create their own internal IT teams to run and manage servers (with hardware security modules, or for building, testing, etc). I don't know how common this is, since cloud services are designed around the common case. Having separate IT teams is expensive, but when the central guys are 100% Microsoft toadies who are 8 time zones away...

For some jobs, I can see this, if there are no rules. I want 20 year olds as my ditch diggers, not 65 year olds. But the law says no you can't do this. It seems like perhaps these Chinese bosses are treating their workers like manual labor. Long term job prospects are probably better as a factory worker than as a software engineer... For engineering, software or otherwise, I agree with your view that diversity is important - if you're going to create excellent products. But that's a long term viewpoint, for those with short term get-rich-quick viewpoints they probably just want a workforce to work long hours and produce mediocre crap as fast as possible.

There ARE rules against the age discrimination in China. But just like US companies, the Chinese companies often ignore the rules. They often get away with ignoring the rules until a kindergarten collapses and token executions take place.

But, it's China. It may promote the idea of being a socialist country but it regularly ignores worker welfare and safety. Outwardly, China seems like a country that rigidly controls its population with a tight fist with a very strong central government, but in practice the central government is weak and provincial bosses are often corrupt. Just like the US, the lure of money makes officials look the other way.

Off-site, though not really off-shore. The concept is the same - don't deal with the problem locally with local experts, let someone else deal with it.

Also, when there has been UN action that wasn't vetoed, the UN forces mostly did nothing. Certainly they didn't protect the peace in Rwanda.

Well, you're assumign these incremental changes are advances. Very often they are not advances. When they are advances they're often just rediscovered ideas from the past.

The reason old folks with experience are seen as negatives naysayers is because we see the same old problems being reinvented and rediscovered. Learn from history before repeating it. The younger generation would not be able to even use computers if people before then had not invented them!

This sort of leads to a bit of a style of thinking that is sometimes common: the assumption that there is an elite cabal out there that invents new stuff and improves old stuff, but they're super advanced beyond our capabiltiies therefore we must only be followers. Ie, the mantra to never write new code because there might be existing code that does what you want somewhere out there for re-use. I see this in interviews - I ask a linked list question and the candidate says "just use a library". I respond that we need to debug that library and the candidate responds with a blank look of incomprehension.

Yes, old farts like me will say "that's a badly thought out idea", but that doesn't mean we're just always negative, it means that experience tells us that some things are not good ideas. We've seen the "cloud" before they called it the cloud. We've seen ten thousand frameworks that all claimed to be the silver bullet to solve all problems, so when someone who's voice is still changing tells us that we should try framework ten thousand and one we are rightfully dubious.

I've been at many companies where the twenty year old product is what earns 90% of the revenue. All the newer products never really caught on, or had endless cycles of refactoring and never got off the ground, the Project X to rewrite the original product using an outsourced team of highly motivated people is bogged down in refactoring, or the product that actually got going and is working but isn't selling because the designer deliberately rejected backwards compatibility with the old product... The bread and butter of most companies, at least in my experience, are the older products that the younger engineers dont want to work on.

Instead of offshoring workers to save a buck, the cloud is offshoring hardware to save a buck.

but before 35, the employee has very little experience. A workforce of 25s is just fine, if you're willing to reinvent the wheel a thousand times, but be utterly baffled at the first flat tire.

I thought it was dark humour genre. Unless someone is taking it seriously?

The Perl in many linux instances I've used often do not have all the pieces needed if a script relies on a third party module. Sometimes these modules are pre-installed in some distros, sometimes they require an optional package, sometimes they just aren't there unless you grab them yourself. Though I find it vastly more common to have a stand-alone Perl script that has no additional requirements on packages or modules than with Python.

Bourne Shell (to be pedantic as it's more portable), and Make are two tools that are quite often written by people who don't understand how they work. It kind of drives me crazy, but I see how it happens. You learn a little bit, then write a small script. Then you make it bigger. Then you change job and the noob that replaced you makes it even bigger. Then you've got an ungodly abomination that is now critical for production and nobody dares to touch it.

I see people attempting to write shell scripts in csh! I thought it was common knowledge to never attempt such a dangerous act, but apparently not. "But it's what I use for the command line!" is not a good excuse.

Make is very powerful, very SIMPLE rules, and yet it gets abused and molested by people who never bothered learning more about it. Ie, they use Make to do things that a shell script would do more easily. Then you get those so fed up with shitty Makefiles that they demand everyone use CMake which has difficult rules and requires even more training to be good at.

But... Bourne Shell and Make are already there on the vast majority of systems by default (even Windows if you use wsl). They're portable, they work, they do the job well. Perl is nice, but Perl is not pre-installed everywhere. You have a Perl script you want others in the organization to use means that you will not become Perl support person for the organization, fixing up broken installs, making sure everyone has the right version, etc. Ugh. Python is great, but Python is fundamentally incompatible with itself, if broke backwards compatibility in a bad way. The mantra to always upgrade is flawed, because the day job is not to continually tweak the Python so that you can get back to the real work. Even worse if those scripts were written assuming the pre-installation of optional modules from third parties. Overall, I've found production Bash scripts to be much easier to maintain than Perl or Python scripts.

To the other points, "script" to me means replicating an automated process. Taking what you would normally type, add a few other things, and now it can be effectively repeated and reused. Although I normally type things like "for f in *.txt; do", although I never normally type a command line for Perl or Python or Lua or whatever. (whenever I do accidentally type "python" and end up with a prompt and I type "quit", "exit", an explative laden sequence of Ctrl-Cs and so forth, I clearly see the difference between script and language)

I'd be happy with a 75% salary after being laid off. If the company feels that non competes are so important that they can hire a large team of lawyers and be willing to pay court costs to retaliate against past workers, they can afford to pay something to the workers directly as a carrot rather than a stick.

They're not prosecuting every single one of them.

I find Amazon deliveries inevitably annoying. Made an order, deliberately chose the slooow delivery option (cheapest), they claimed delivery on Saturday, which was fine with me, I would be home. Instead it was delivered on Tuesday, while I was at work, with many many hours of it sitting on the welcome mat in a busy condo complex with lots of people walking past. Similar things happened in the past; their estimated delivery date is unreliable.

Amazon probably thinks to themselves "We delivered early! Kif, pat us on the back."

AI: Student's name is Aaronson, therefore correlating with grades on the internet by similarly named people means I must assign an A. Student Xi also gets a grade of X because that tickles my neural feedback loops.

He became president because the competition was substantially worse. The competition also claimed he was smart because he had a very smart uncle, so apparently the competition also slept through the class on genetics.