He actually said it: âoe What is the empirical evidence that programming, broadly speaking, is inherently hard, or harder than possible analogs such as calculus in mathematics?â What article were you reading?

As a former Appler who didn't break 6-figures while working there... Apple doesn't like the whole "remote work" thing, not one bit. They relocated me to Maiden, NC to work in the data center where I had no hosts... And had no coworkers... In fact, all my coworkers were in CA, and they too were required to come into the office daily, and by all reports from my former coworkers and friends, they still have to (as soon as the recent call back to the office hits). It would appear to me they would have a significant windfall by hiring remote employees, and NOT having to build even more facilities. Put your money into your employees, and not into your buildings and your own real estate holdings. They could get the benefit of marginally cheaper labor, paying less per headcount when factoring in new builds, but realizing a higher than average pay that the employee would see, thus benefiting both parties without all the clutter of new Apple buildings all over the country. Come to the 21st century, Apple You allow support to work remotely, now extend that to your engineering staff for a happier, more productive workforce.

Now hold on a minute. That's how the nanny state gets their money to pay for $president's pet projects. Any of them. Without taxes, you get nothing. None of the green new deal, none of the free college, no free healthcare... on and on. I thought taxes were good on the rich?

Those characteristics can be a result of poor personal management and planning.
Working with other people to manage their finances (Dave Ramsey classes), I find that individuals on the lower end of the income scale do not have resources and savings due to their inability to discipline themselves in their own spending. Eating out instead of eating in, frivolous spending on entertainment and multiple data streams into the home, multiple car notes simultaneously, and so forth are the result of bad decisions, not that of poor station in life.
I've seen those making in the 20's to 30's with 4 children who were living paycheck to paycheck begin to discipline themselves and start to rise out of this poverty mentality. By denying their instincts to "pleasure now", they are able to rise above their station and plan for "pleasure later" all due to self discipline.
It can be done and is being done in large scale simply by beginning to discipline yourself, stop borrowing money you don't have, live within your means, and taking care of business before pleasure.

Couldn't read the article if I wanted to. It was paywalled. And I'll be DAMNED if I'm going to sign up for content that is otherwise free.

Atlanta suburbs here... 3 story home on an acre in an HOA neighborhood with 4 pools, courts, exercise facilities, etc. 300k out the door. Granted, Atlanta is taking on roughly 75k people every year, but the tech market is doing extremely well, and the salaries are on par with PHX/AUS/SJC/SFO for IC level roles. Yes, I'll eventually leave due to crowding, but for the time being, it's a great place to live and raise a family.

I want it reverse order chronologically. Nothing else. Unfortunately, they not only make "relevant" the default, they prevent you from setting it chronological permanently, changing it back when they damn well feel like it. STOP telling me how I should interact with my social circle. If I want to see what happened the MOST recent in time, that's what I want to see. Now, Facebag is just a way to hear from old friends and extended family. If I want to chat with actual friends, I text them or hit them up on Instagram.

I'm not the only one who'd never heard of them. *whew*

Yes, and ISIS has been "contained"... Oh brother...

Papers are completely unnecessary to do the job, and years in the business with a successful track record ALWAYS trumps a sheet of paper.

Integrator/Architect here... I travel all over the country (USA) for $CFGMGMT software company doing implementations and training in said package. Further, I do professional services engagements to implement and deploy devops workflows and integration paths for both operational and development workflows. I can say with great confidence that after reading the 150-ish comments here that I've only seen one or two commenters that come close to "getting" modern devops.
As for the RTFA implications, many people saw right through his silliness. Developer in an ivory tower thinking his world is grand and majestic and lauded above all other disciplines. I guess that explains some of the crap in Python (but I digress).
I've been in this business since before the bubble. I have done systems work dating all the way back to the 80's. At that time there were many silos with few bridges between. The first iteration of "devops" I remember seeing can be quantified as developers seeking root access. Even to this day, the answer is continually a resounding "no". Why? Are devs automatically rejected due to what specific tower they are residing in? Are they rejected because of the "separation of powers" or because of "politics"? Are ops folks just dicks with a chip on their shoulder?
I think a number of things have happened and if you'll indulge me, perhaps we can break this conversation out more to see what's going on today.
Back in the day, we had an operations team, systems team, qa team, and dev team. Loosely defined, these were the folks in the NOC monitoring everything and pushing ticket events to the right teams via triage, doing prints and getting them ready for the requestor, managing backups and access to the computer room, etc... general "operational" tasks. Day to day "operations" of the center of computing for your facility. At some point, this title got applied to anything that smacked of someone whose fingers touched anything made of metal. When this seemed to change? Late 90's-ish. I don't have specifics, but that's my recollection. Remember also that different sections of the country progress at different rates, so YMMV.
Then there was the "systems team". Different sites had different monikers for this team from "engineering" (which PEs got pissed about) to "architecture" to "Systems Admins" to... well, whatever title HR thought was appropriate and met their organizational/talent distribution goals, but the work was generally the same. Storage, systems (mid range, intel, mainframe, etc.), capacity planning, backup systems and strategies, disaster recovery, and a myriad of other specializations within systems work. This is the specific "field" of systems work that breeds organizations like SAGE/LOPSA, etc. Those in these organizations dig into the very nuts and bolts of admin as a career and a field of expertise, following current research and methodologies and bettering themselves each and every day. I would offer that while dev folks can be quite competent in various systems tasks, they're just not a sysadmin (much less an engineer or architect). They really have no place in this area REGARDLESS of their quality at it.
Many times I've heard dev get bent out of shape because "ops is being a blocker" or "we can't get anything done because ops is saying 'no'". It's unfortunate to be that myopic and that selfish. What many devs don't understand is the ops person they're dealing with is supporting sometimes as many as 10 different DEV teams operating on the exact same hosts or clusters of hosts and one or two of those environments is the pet project of VP #13 that agreed to a bunch of junk on the golf course that isn't in the statement of work, but is being offered "on the sly". They don't understand that dev #22, who has relationship with VP #11 and can essentially get what they want has forced you to introduce "whiz bang package or library 1.2.3.4" while the safe, researched, CERT recommended package is 1.2.2.2 (and, incidentally is the one all the other dev teams are using) but because this high-horse, ivory-towered, "connected" dev has enforced his will, all the other devs are screwed because those two packages are incompatible and cannot coexist on the same hosts. Now, all the work that was being done on the systems has to cow-tow to other requirements. Now, ops guy is stuck between two warring factions and has to figure out who to please 1) to keep his job and 2) to make working with everyone involved pleasant (at the very least). "Only approved packages" implemented as per ops, anyone?
Development is a wonderful career. I always say "I am not a developer and I don't play one on TV"... It's a specialization, a craft. I am not a craftsman in this field. I don't even pretend to be. I count on the development teams to know how best to execute their craft. However, they need to reciprocate. I have been fortunate to be in this precise same situation and am grateful for it. They count on me to "do my thing" and I count on them to "do their thing" and we have a pleasant, amicable relationship. I think this is how it should be.
On the subject of "devops"... this depends on your environment. Some folks mean one thing and others mean something else. Point is, even the "devops software" people don't really agree 100% and it all comes down to workflow. What workflow MOST keeps security, stability, and repeatability in place for systems while providing speed, iteration, and flexibility for software development? That's it. And it's specific to you, your culture, and your environment. This simple structure to conform your particular workflow around works in each and every environment I've ever been in. Fitting a company's culture around this sort of workflow WILL make things better. Politics and religious arguments should be set aside when building this. Devs shouldn't be quick to gallop away toward 'give us full root everywhere" and systems should not be quick to impose their view of the world on development and actually *listen* to what they're trying to accomplish. Many times, a little extra work by YOU on the front end can make for happy, fulfilled devs that are excited that they can concentrate on the thing they REALLY excel at: writing great code. If you take the time to implement your infrastructure in code, you get to spend much more time on considerably more interesting things, not the least of which is concentrating on refactoring and making your own code better (whether scripts, recipes, manifests, or whatever). Everyone wins in this scenario and everyone gets better.
I'm certain I'll have a lot of disagreement here, but I've seen it work, it works well, and devs & systems folks really actually find out they like each other to some degree. (shudder!)

I Googled "History of the 5th Amendment" and got a crap=ton of hits. Not the least of which is this:

"The Fifth Amendment to the U.S. Constitution provides that "no person ... shall be compelled in any criminal case to be a witness against himself." The right was created in reaction to the excesses of the Courts of Star Chamber and High Commission—British courts of equity that operated from 1487-1641. These courts utilized the inquisitorial method of truth-seeking as opposed to the prosecutorial, meaning that prosecutors did not bear the burden of proving a case, but that sufficient "proof" came from browbeating confessions out of the accused. These courts required the accused to answer any question put to him, without advance notice of his accusers, the charges against him, or the evidence amassed. With the abolition of the Courts of Star Chamber and High Commission, the common law courts of England incorporated this principle of nemo tenetur—that no man should be bound to accuse himself. By the 18th century, English law provided that neither confessions coerced during the trial nor pretrial confessions obtained through torture could be used. This was based on the belief that coerced confessions were inherently unreliable. The right to be free from self-incrimination was established in nine state constitutions and was a tenet of the common law throughout most of the colonies before it appeared in the U.S. Constitution. Since then, the U.S. Supreme Court has expanded the Fifth Amendment to apply not only to criminal proceedings and pretrial proceedings in criminal matters, including police-station interrogations, but also to "any other proceeding, civil or criminal, formal or informal, where his answers might incriminate him in future criminal proceedings." The law also prohibits prosecutors from making reference to a defendant's refusal to take the stand as probative of guilt. So long as the government is compelling potentially incriminating speech—either before a jury or a Senate Committee—the right can be invoked."

Seems plausible.

So many smart people on Slashdot. Why they no use their "Google-Fu"? http://www.teacherportal.com/teacher-salaries-by-state/

>Distance/video learning can help to enlighten. It can even help to educate people who genuinely want to learn (typically, this works better with adults).
I have to agree here. I'm in a distance-learning theology coursework, and I'm doing 10X the work I ever did while I was in college, and learning and retaining more.

The problem here is one of relegating your own hiring practices to the realm of the very employee you are trying to avoid. Let me explain... I helped a local University (the one I attended) install a pretty massive software package. I trained their entire team on how to use it, and how to bring in what they knew about UNIX scripting to make the thing even more powerful. Six months later, one of the basic admin gigs came open, and I applied for it. I was well qualified for the position, and my experience outweighed everyone else in the department. I was perfect for the job. The screener was the department head, who was a good friend of mine as well. He was painfully sorry he couldn't hire me because the University had a "college degrees only" policy for hiring, and would have no one in these positions that didn't have a degree. Best part: a girl with a degree in Kinesiology got the gig in the computing services department doing that job. I had to train her too.