No ethos is better than all others. But some are clearly worse.

Can you give some examples? I can't say I have a particular ethos as such, but I can't really think of a "distinctive spirit" (see dict.org) that people have in regards to programming that I would consider bad. Even not having any particular approach isn't such a bad thing IMHO; it just means you haven't formed a general view as such yet.

Use the second definition.

A few examples I have seen.

1. Documenting every line of production code with a mechanical description of what the command does. See Code Complete or The Pragmatic Programmer for an explanation of why this leads to bugs.
2. Having every program in a system create and destroy block files. The programs in question never did run synchronously, but the block files meant that if anything unexpectedly crashed, there was a good chance that the system would refuse to run again. (Most of the programs should have been function calls, but I digress.)
3. How about writing long programs in straightline code rather than breaking out functions. For programs of several hundred lines it is faster end to end to produce it breaking out some functions.
4. How about using goto in preference to function calls, looping constructs, etc? People used to do that at one time. (Not that goto is uniformly bad. I use it from time to time...)

Says tilly:

A few examples I have seen.

But none of those are examples of what I thought the original poster was asking about.

I was not saying that no engineering is better than any other engineering. The original question did not seem to me to be about implementation details.