Oh, Zed is eminently mockable, especially due to his absurd supermacho asshole persona, but his stuff is a pretty good antidote to three different classes of toxicity around programming:

1. "Programming is easy; what's hard is working together with other people." No, they're both sometimes really easy and sometimes really hard. For a lot of objectives you might have, you have to learn to do the hard parts of both of them. The hard parts of programming include design, analysis, testing, debugging, and verification. You aren't going to learn how to write a compiler in 21 days. (Most programmers don't learn how to write a compiler in 2100 days, although that's probably more because they aren't trying because they're intimidated.)

2. "Software is in a crisis because we don't know how to program, and the solution is to manage software projects as if they were construction sites, using misguided metaphors about bridges invented by people who have no idea what happens when you actually try to build a bridge." No, in fact you have to understand both management and programming (motherfucker!) to manage a programming project effectively. When programming is being done effectively, you automate all the repetitive parts, which dramatically reduces costs and timeframe, but dramatically inflates the unpredictability.

Instead of managing software projects like construction sites, we're going to be managing construction sites like software projects, using proven libraries, mathematical models, repeated simulations, iterative exploration of unknowns to reduce risks, and pervasive automation. This is all in Engelbart's papers from the 1960s. Doing things that way (applying software techniques to hardware) is how we became able to build hardware with billions of transistors in the first place. It might be 2020 or 2035 when most of the effort in building a house is done by people using computers to manipulate models of the house, and only the last step involves (fully automated) machines rolling onto the construction site to materialize your carefully debugged plans, but it's going to happen. (I don't know if being able to deploy a new iteration of your house every week in order to fix bugs and roll out new features is going to happen before or after that.)

Now, it's true that we don't know how to program (although developments like seL4, coqasm, Excel, NaCl, and PHP seem to be making some progress on that front). But the "software crisis" isn't about that. Rather, it's about how Moore's Law has reduced the cost of computers so much that programming is suddenly the limiting reagent in nearly everything in the economy. You can get a 48MHz ARM processor with 64kB of program Flash for US$1.76 and burn ten thousand lines of C into it, then use it to run a string of Christmas lights. For US$6.46 you can get a 48MHz ARM processor with 1MB of program Flash and burn a hundred thousand lines of C into it. Or you can put a Lua interpreter into 20% of that memory and fill the other 80% with eighty thousand lines of Lua. The "crisis" is that it costs literally a million times more to write the code than it does to make the processor. (Prices from Digi-Key, unit price for quantity 1000.) The "crisis" started in 1968 when the price of hardware at last fell below the cost of writing the software to take advantage of it, and it's been "worsening" ever since. And that's the origin of "software engineering".

3. "Programming is super hard and you have to be a wizard to do it at all." No, anybody can learn how to program. We have Excel, JS, and PHP. If you have a computer and already know how to read, you can learn how to program a little bit in a few days, and usefully in a month. There are still going to be a lot of things that are beyond your capacity, but you'll be able to do some things. It might take you years of work to learn how to write like Dean R. Koontz, but you don't have to be a Dean R. Koontz to write a shopping list, a YouTube comment, or a love letter. Programming's the same way.