Maybe he worked abroad at some point?

Being able to quickly execute arithmetic is a basic skill that everyone should be pushed to master.

However it has jack all to do with algebra II.

You're mistaking correlation with causation. Inability to quickly add and subtract doesn't really prevent one from understanding algebra. It's just that your students who never truly mastered basic arithmetic are not really truly mastering any of the math they're encountering.

Speed has little to do with it. It's a red herring for most areas of math. Better grasp does typically result in faster execution for the individual, but that does not imply that the slower individuals you encounter do not have a good grasp.

The kooky part is rejecting documentation of same.

This is kind of a miss.

There's a pretty able transit system that goes from San Francisco to Mountain View. It's called Caltrain. It's not perfect, and at off-hours it has more headway between trains than is highly desirable but it's extremely energy efficient and quite affordable as far as rail systems go.

The real reason that the existing transport systems don't serve Google workers well is that Google HQ is over 3 miles away from the nearest train station.

The inefficiency is all down in the suburb, not in the city.

It's not a "bus line". It's a point to point service that causes parts of SF to become artificially more desirable to Google employees than they would be otherwise, whose wealth is propped up by Wall Street investment patterns.

This causes those particular neighborhoods to have housing costs move out-of-reach of median incomes.

Whether or not you see this as unjust is a matter of debate, but it's not equivalent to a city bus route, which is a resource for everyone.

The taste would be far more palatable if the Google workers were working in SF, and thus Google was paying taxes on the work of these employees in SF. That would bring proportional funds into the city to cover infrastructure costs. Unfortunately, Google can pay lower office costs in the south bay because of the sprawl pattern.

Hiding the information is a management error.

Programmers want and appreciate transparency for its own sake and will be happier still with the thank you bosues AND clearly understanding what's going on.

However if the engingeers are a small minority of employees, that might no work because that kind of transparency does not work for all employee types.

Corporate speak is full of nonsense code words use to mean things other than what they mean. Job postings are nearly the thickest.

"Need Passionate Self-Starter who is a rock-star team-player who wants to change the world!"

This stuff has been nonsense since before I was born.

Or, looking at it from another perspective:

You can get a full workday with less time wasted. If you stand up for yourself this means you can live in a city you want to live in, and have a rewarding job, and not have many hours a day spent driving a car.

Seriously, no one likes driving hours a day in commute-traffic. Avoiding that is something any sane person wants.

People who work for Google is not a race.

It's a class thing.

Also you used the incorrect "your", it should have been "you're".

TO SOLITARY WITH YOU!

Well, to be fair, in the broad view, we have more than enough people.

I'm not sure the current situation is great, but some incentive against reproducing isn't all bad.

I'd expect a systems admin to be able to diagnose a problem like that -- not that ours can. But most programmers I meet can't. They'll be trying to fix their code all day long when their system has bad ram.

Our customers have the same problem. They'll be asking why our software is slow on "just this one node". Telling us to "fix the bug".

I have to look through system call timings, application logs, kernel messages, kernel dev tools blah blah to give them evidence of what I already know. "it's a hardware problem. It seems this is a known failure pattern in the linux kernel for cache coherency errors betwen SMP cpus".. or whatever. We're an application vendor. I guess these companies spend enough money with us that it's worth it to my employer for me to play tinker-toy remote systems admin for them via proxy of systems debugging.

I get roped into these problems because no one else on my team can figure them out.

It pays.

Those things are true, but IMO the real issue is:

  Can they find the same talent offshore?

I'm sure there are developers in eastern europe, china, India, and other popular offshoring locations with all the talent of a 50 year old american or western european engineer who is looking to work remotely. Good luck finding them through typical offshoring channels.

The real issue, IMO, is that modern management has NO idea how to measure competence and turn it into a number, and therefore doesn't believe it's important.

Some open plans are awful.
Some are fine.

If you hate open plans, then skip them.
But don't write them off if you don't know that you hate it already.

I do a lot of evaluation of special purpose tools.

Performance analyzers
Flowchart editors
Outline editors
Callgraph generators

I don't do this until I actually need a thing. Then I want it within a week or less. I often try out several multi-hundred dollar packages. Inevitably almost all of them fail.

The last thing I needed to do was generate a callgraph to document a subsystem I'd spent around 30 hours understanding. I didn't want to ever do that again. I went through a few ~1000 dollar packages that sucked. I ended up writing the callgraph myself in DOT.

Most commercial programs are too full of features, dialog boxes and other crap to really work for anyone except someone who uses them all day long. And there is a very short list of sotftware categories that deserve this type of complexity and learning curve.

Most apps are just NOT the center of attention, and the important thing is to remove everything obscuring the core utility.