"People matter"...Simon Sinek's observations concur with this.

I think what he is saying alludes to the price of the headset.

He's saying, and several 30+ yrs software engineers are saying, at Meta the dev teams are inefficient at how they develop the software. On Lex Fridman's podcast he stated that developers don't even use debuggers (they consider it cheating), which is mind blowing. However, not unusual. When I worked at Oracle in '98 a couple of developers didn't understand buffer overflow in C, and were adding print statements to their C code and wondering why the stack trace kept changing. I had to explain to them what was going on, and have them launch the debugger to prove it. These guys spent two days trying to figure it out using print statement. That's the practice and inefficiencies that carmack is talking about. Which means the cost to develop a product increases.

It doesn't surprise me. If you're hiring practice is essentially someone asking a question from a spreadsheet and writing the candidate off when they don't answer exactly as written in the spreadsheet (and the interviewer doesn't have the background to decipher the answer), you're essentially going to hire people that have studied to pass the interview "test". Not problem solvers who understand software engineering. This vid states this quite well...

https://youtu.be/odhQ_B_x658

begin RANT...

Divisions being run by managers who can't program, therefore don't appreciate the difficulties. Developers who don't understand test design, product owners who have yet to realize they are the gatekeepers of quality. Salesperson in an engineering management position (e.g. all the AT&T DTV's CTO weren't CTO's) making decisions from a saleperson perspective. Management letting marketing people set deadlines. Developers who become jaded because they're always working on defects and not new code. Coaches that are useless at understanding the cause of poor development practices...the list goes on. End result...Large numbers of developers post '98 don't have the tools, nor the desire to learn those tools, to produce a quality body of work.

To undestand my POV...Go back to the beginning of the SE as a career path (around late 1960's). Programming was expensive, HARD, and expensive! Did I mention expense? The people that were doing it were incredibly smart in that regards, and if you met any of them today you would be taken aback by how smart methinks. It's been going downhill ever since from my POV. I felt like a knucklehead compared to some of the older guys I had the privilege to work with.

Languages evolved to make it easier and more cost friendly.

FORTRAN/COBOL on punch cards?
APL using symbols and requiring special keyboards.
C with its buffer overflow issues that few understood well. Pointers anyone?
Few (if any) debuggers. And definitely no GUI's. All debugging was command line.

Late '70's saw the emergence of the personal computer. Those of us that had access to whatever model began to see it as a viable career path. Schools had computer SCIENCE courses that actual taught it as a SCIENCE. My curriculum included language parsers, compilers, database design (not tables, that actual DB). We were taught everything from ASM, C, PASCAL, FORTRAN, APL etc... Even machine language was part of one course. They still didn't teach test design however (not sure why that went under the radar).

By the late '80's there was an influx of software engineers that loved the craft aspect of it and wanted to understand the cause of defects getting through. The gang of four released their Design Patterns book in the early '90's which, by then, introduced C++ and other object oriented languages to the younger crowd. The CMM and other bodies conveying how a well established company could ensure some semblance of quality for their products. Source control, the beginning of build pipelines that included the running of unit tests to ensure no breakages (later evolved to CI), design reviews, code reviews, test design/code reviews etc... became the norm in well established teams. QA was their to measure the quality as it pertained to the customer POV. They were not the enemy but a collaborating division.

  I know I certainly began to feel like software development was finally enjoying the rigor and precision that other engineering disciplines had.

And then the explosion of the .COM around '98. And the influx of cheap programmers from other parts of the world who hadn't evolved with the same knowledge, and the use of non-software engineers as their managers all trying to launch an online presence ASAP.

o do so they threw out design/code/test reviews, unit testing (hell wells fargo's online banking system was develop w/o unit tests because their development manager was convinced by the developers that QA did the testing). This saw the explosion of the "QA engineer" who did manual testing. And then along came the SilkTest, winrunner's etc... that promised managers that their manual testers could write tests (they couldn't) that would increase the cost savings (it didn't). This then lead to managers blaming QA for releasing a shit product. Those non-engineers as managers didn't understand the difference between preventive tests and tests used to measure the quality.

Hell in 2004 Google had to invent the term Software Developer In Test (SDET) to compensate. Why wouldn't a developer know how to test their component???

So from '98-(I think it's still ongoing) developers were treated like gods, and didn't understand test design, nor design patterns and coding for the person who will take over their code 6-months from now. "Standard indentation inhibit my ability to be creative" read as "Job security if the new guy can't figure out my code."

All the advances we had made as a whole up until '98 was washed away with two years.

What I see today is a continuation of this. People with master's degrees that don't understand OOD, only the syntax of JAVA. Job interviews that doin't focus on problem solving questions, but more the language constructs and some basic design patterns (languages are just tools).

Product Owners signing off on stories w/o verifying that the unit tests demonstrate the AC is correct simply because they trust their engineers (trust, but verify). PO's not even realising they are the gatekeepers of quality within their teams.

Software engineering is HARD. However, with the appropriate checks and balances coupled with the use of sound design patterns and test design kept honest by using the basic understanding that uncertainty is a given and the modern time management techniques (scrum/kanban - forget SaFE as it doesn't work) factor that in (that's why sprints are 2-3wks tops). And have a static set of rules for Definition of Done that includes demonstrating all AC's via unit tests, eventually a teams velocity will stabilize. The number of defects escaping will diminish, and the developers will begin to enjoy the realization that they aren't having to go back to older code to fix defects. They'll be working on new code, enjoying the felling of creating something new.

Managers need to understand that in today's climate, releasing bugging code within their time schedule does more harm to your company that they realize (not just from a customer POV but from an employee POV). And retro-fitting unit tests at the end will push the cost up beyond what the company can bear.

Programmers make mistakes because they haven't seen that their are techniques that can help them build better solutions. They make mistakes because poorly chosen managers will scream "But the deadline" every deadline that passes, rather than admit that scream we have to meet the deadline when the company has never met a deadline doesn't help you meet the deadline and simply puts more pressure on the developer, thus causing more mistakes.

In closing. I prefer "missed opportunity" to "mistakes". The missed opportunity we in the software development community need to acknowledge, is that at some point developers did actually produce software with low defects. They understood "mission critical" and developed techniques to make life easier and more enjoyable as they worked on coding products. Those lessons are still valid today. Unfortunately, if most of the leaders of teams have never developed software, nor have the aptitude, they will never accept that in order to go faster, you have to first slow down and relearn how to do it better. Spotify did it, and they had over 600 people on board at that time. The rewrote their entire app using better techniques. If they hadn't, we'd all be listening to Pandora now!

end RANT.