I see many programmers who waste their time on:
I know a programmer who says C# is an almost-perfect language. When that person wanted to add a third command-line option, he refactored Main() and added classes (= many LOC) to make the code "beautiful". This took hours and created a conflict against another branch, which does the same thing in 2 lines, using the "if" technology. Meanwhile, this product has serious performance issues and doesn't work at all for the first big customers.
I know a Python programmer who writes everything in Python, and uses frameworks like Django even for simple microservices. He presents himself as a "productivity guru" and talks way too much about productivity and ergonomics. He believes Python is the "best" language, but this person creates so much technical debt and monthly costs, when his microservices misbehave under load and must be scaled both horizontally and vertically. He sits on a comfortable chair at the peak of a pyramid built using high-level "black boxes" and has excuses for everything, while the customers don't understand how to manage the product and wonder why it needs to be restarted often.
I know two C++ fans who waste their time looking for ways to take advantage of new C++%d features, while customers are complaining about crashes and full coredumps with source information are available.
And I know some Rust fans: some of them are busy doing the "x but in Rust" thing, although they don't have any complaints about the existing solution.
I also know a guy who spends hours every day configuring zsh and vim. He believes that makes him "productive", but without measuring the outcome of this time-consuming "optimization". I bet he spends at least 50% of the remaining time in the IDE, and the rest in the browser.
Bugs and security issues are real problems, especially when it's critical infrastructure like OpenSSL. But these days, we have such great tools, even for "bad" languages like C: for example, if you have an old C project with a bug or two, maybe you can just build with -fsanitize=address and let the compiler tell you what the problem is, instead of rewriting everything in Rust. IMHO, software engineers should focus on real-world problems and make the world a better place using technology. Good programmers should spend most of their time thinking, planning, researching, discussing and listening: all the things that make a programmer worthy of the title "engineer". Customers don't care about elegant syntax and people with old computers don't care if the application they want to use runs slowly or needs too much memory because the garbage collector is slow. IMHO, the biggest threat to programmer productivity is all this "shiny new thing", "let's replace α with β" and "α must go away because it's old" culture: good programmers look for the most minimal way to fix a problem, and that problem can be a "real problem" (for example, a feature requested by a customer) or a bug. Most programming languages, IDEs, text editors, etc', are not THAT bad, especially if you don't measure your success in LOC.
At the same time, I think resistance to change is dangerous, too, and it's always a good idea to dedicate some of your time to learning, reflection and optimization of your workflow. Sometimes, old ways of doing things need to go away, to make room for new, more efficient methods: some technlogies are simply bad and cost you every time you use them. I think Gophermaps are a good example: they're a pain to write, and Gemini is a huge improvement over Gopher, in many ways. Go and Rust are good examples, too, especially for new projects. And sometimes, a big and urgent problem needs a radical solution: last week, I had to rewrite a microservice written by a C# fan with very little C++ knowledge: I migrated it to the latest .NET version, embedded a small chunk of PowerShell in it and made it multi-process, to work around memory leaks and a denial of service bug in some "native" Microsoft DLL, which happens often but only at the massive scale of a real customer environment. Principles are nice, but sometimes you don't have the time for them and must use bubble wrap.
Although I still lean towards blaming the programmers and not their dance floor, the truth is probably closer to the middle: I think it's a 60-40 or 70-30 split. Methods have their limits and have their time and place, but you can't do your job if you waste all your time on finding good ways to do your job. I'll end this post with a quote of Feyerabend, one of my favorite philosophers:
The only principle that does not inhibit progress is: anything goes.