Are software engineering “best practices” just developer preferences?

Sure, so who defines which parts are highly technical? We can all be in agreement that things like cryptography should use well known and vetted libraries, whereas something like a REST API interface can be a little more relaxed with adherence to a standard, but where do we draw the line?

I do not want to live in a world where my code must conform to a Java Bean factory class. I align more with the skunkworks style of development.

I once work on contract on a project where everything was abstracted to hell and back. We spent 90% of our time trying to figure out where references pointed to in the code. Never again.

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc.

Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to ask why or whether. I think we'll automate away much of software engineering (likely with very poor, inefficient, and buggy implementations) before it matures enough as an industry to be actual engineering. Engineering (and the science behind it for that matter) advances from curiosity and a healthy skepticism, not the rampant ego-driven self-promotion that runs through SE.

Yes and no.

Given the context of the authors ( and this also includes employment context, socioeconomic and personality factors for everyone involved ), the best practice is something that has been "proved" to work well.

So no, it's not just a preference, but in practical terms many times it's a preference that some people agree it worked ( in their context ).

And let's not even talk about the "best practices" and technologies created just to sell you something. I think by now it's not a secret that most "developer evangelists" or even "famous" developers are just people doing sales and marketing, some of them don't even realize it such is their ego trip.

I usually agree but sometimes you want to reduce the exposure of the public methods of the concrete class even if there's only one concrete implementer.

For example, you might want to pass around a class and only expose the getters and not the setters.

Right now I am working on converting a front end application written in angualar/typescript using a monorepo technology called nx.dev into a micro-frontend architecture. All the teams that have been contributing code to the project never bothered to use nx in the way that it was intended and disabled linting for the entire project. The thing is if people had followed the linting rules it would have made my life 1000x times easier because now I have to take a scalpel to the monolith they've made and break it down into smaller parts. Linting rules would have told them to respect module boundaries and warned about circular dependencies. Now I have to clean up the mess.