Are software engineering “best practices” just developer preferences?

Well, the failure of a satellite would definitely result in harm to property and economic interests, so it sounds like you would still be an engineer in that case.

Skimming all of these comments I think that creating software remains more of a craft than an engineering discipline. Not that that’s a bad thing, in that it permits creativity. And for most cases, engineering-level rigor isn’t worth the effort. As Tom West said in Soul “Not everything worth doing is worth doing well.”

Sadly, this approach seems to have been used in the interface software of my RAV4.

As an oficially qualified computer scientist, I can say that software is grounded in mathematics, but this does not imply what you're thinking. *All* formalisms, including mathematics, are in the end nothing but an incredibly precise language to talk about ideas in your head. Programming languages are created for communication, so this is specially true for them.

The fact that code has an extremely precise semantics comes from it being a formal system. But its close relation with maths and physics, besides that they are all formal systems, is mainly because mathematicians and physicists were the first to create it; it's mostly a matter of tradition. There are ways to create, use and study software that are closer to language studies than they are to math, and those are legitimate comp-sci too. Non-formal aspects of building software, like which style guide to establish in your organization, are part of the discipline even if you don't use math to study them.

Formal proof is a convenient way to check that your detailed, precise assertions are consistent with your initial axioms. This doesn't prove at all that there are no errors in your code, only that there are no contradictions in what you are saying. Your specification could still be wrong, and then you could still be saying the wrong thing in terms of what you intend to say or achieve; and the formalism won't help.

It is not surprising that managers gets to decide how software is built in their department. Software is an explanation of concepts with a particular style, and those who set the tone implant their quirks in it. You're building what the manager tells you to build, and end using the same language.

Exactly, it would've made total sense to pull it out into an interface in other situations, but simply felt like a preference here.

I hate the expression "best practice", it's so, so often used by someone to justify applying cargo cult without actually understanding why.

"Hey why are you having a try-catch there, it seems like it's just gonna break our stack trace and we don't even graciously recover from it" - it's best practice

"Hey why are you using model/view/controller folders?" - it's best practice

"Why are you building microservices?" - best practice.

I got out of a code base with stylecop's settings set to max and treated as errors. Trailing white spaces, mandatory comments on everything, etc. The only exceptions are file size and method size. Files are often in the thousands of lines, and methods can reach that as well. 10 levels of nested if/else. So we're in an unmanageable code base, but at least we don't have trailing white spaces.

Most of the time it could be replaced by "tradition", "pattern", or "the way I've seen others do". If it's a tradition and most people agree to it, fine, might help with readability. If it's pattern, fine, tell me why it's applicable and helpful in our context. If you can't actually explain why you're doing something, maybe rethink it and educate yourself on the topic