In the land of web dev, the number of files you need for a "modern" project that are boilerplate configs or boilerplate placeholders is pretty absurd.
.browserslistrc, .babelrc, .editorconfig, .eslintrc, .prettierrc, .stylelintrc, jsconfig.json, package.json, src/index.html... and this is with a "zero config" Parcel setup. And that's not counting the src/vendor/ folder of two dozen files that only exist to work around old AngularJS libs expecting everything to happen in a global context and there still being no bundled that can handle those properly.
Reinventing wheels and justifying it by straw man arguments when in reality it's just generational churn. Building up needless towers of abstractions. Going all-in on cloud and fashion stacks without assessment of requirements for a given task aka resume-driven development.
For example, agile vs waterfall (when there is no such thing as a "waterfall"; there is such a thing as cluelessness, though).
It's most readily observed in Web dev, where every five years or so the entire landscape is changing because a new generation can't be bothered to understand what came before (or, in fact, where the de facto mainstream stack has grown too many idiosyncrasies). For example, I'm expecting a back-to-basic-Ajax movement at the end of the React hype cycle, similar in spirit to motherfuckingwebsite.com.
Because "worse is better". Social human issues (like the job market or committees) give a boost to not so great or "good enough" softwares. People can emancipate themselves from that but they need to admit it first and find satisfying explanations.
Curtis Yarvin (urbit), Terry Davis (TempleOS), Alan Kay and Niklaus Wirth are people who don't follow the others.
For the likes of Google, Microsoft, Amazon, and the like, I think it's a great way to narrow the list down. If they get hundreds of thousands of applications a year, there's probably a good percentage of that group that "could" do the job, so they need to be more selective. I guess the next best way to do that in an efficient way is to go down the CS route, even if it means you'll miss out on some fantastic developers.
Where I take offence to it is in how it's used in shitty consultancies, startups and agencies. If you're asking me to build a linked list in an interview where all I'll be doing is maintaining some shitty CRUD app in procedural PHP then it's a sure-fire sign that the company is a terrible place to work, and the people in charge have no business being there.
Project planning? I don't think I've ever seen a software engineering project where the costs don't overrun and the tasks don't take longer than they're 'meant' to. Waterfall, agile, anything else... they all seem to fall apart in everyday life with development related tasks.
Similarly, feature/scope creep seems to be a big problem in this field too. It's not as common as projects taking too long/costing more than expected, but still pretty common none the less. Usually because someone didn't actually ask the customer what they needed before building it, or feel like telling someone that they can't just 'have extras thrown in for free midway through development'.
Documentation too. We desperately need more people to willing to write/update that stuff, especially where free software is concerned.
I'm frustrated that so much work is duplicated. Every new programming language seems like it requires another new universe of packages around it. Often there's not even an attempt at interoperation, except maybe for C.
But even just between projects I feel like I lose a lot, rewriting things that I've done before, but slightly different. It's maddening.
Knowing what tools to use and how to put them together. How many times have you seen posts about what blogging frameworks to use? So many of these stacks have out-dated documentation on the hosting service too (i.e. one click install Pelican blog on Digital Ocean)
I think the process or best practices of writing requirements and specs is not well understood by the business side in many industries. This is my opinion would greatly benefit the engineering side.
.browserslistrc, .babelrc, .editorconfig, .eslintrc, .prettierrc, .stylelintrc, jsconfig.json, package.json, src/index.html... and this is with a "zero config" Parcel setup. And that's not counting the src/vendor/ folder of two dozen files that only exist to work around old AngularJS libs expecting everything to happen in a global context and there still being no bundled that can handle those properly.