This would necessarily presume applying the same attitude towards the happy path—you're describing something short of that.
Or to put it a different way: defensive programming necessarily implies a skepticism that you even are sure what the happy/error paths are!
I realize that this is a different person from you, but that's the attitude I am replying to.
"extra vigilant ... [compared to my level of vigilance on the happy path]",
but rather
"extra vigilant ... [compared to other people I work or have worked with]"
The latter is how I read it, because I have definitely worked on teams where the happy path was heavily scrutinised, but error handling was treated as an afterthought, and rarely inspected too closely, leading to anything from error strings copied from another part of the application with names not updated to match the new location to throwing XException but only handling YException, so the XException bubbles up to a much less useful handler.
Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do!
> Hell, I'm free now! Everyone I've ever worked with sucks donkey-dick for not coding how I do!
I read it as "extra vigilant ... [because it's natural for people, including me, to focus on the happy path]".
I didn't read it as putting down other people you've worked with, holding yourself up as some paragon, OR potentially exposing yourself as incompetent (I'm really not sure how it would do that anyway?).
People tend to focus on the happy path. It's good to be aware of that and try to correct it. It doesn't require or imply thinking poorly of other people.
My experience definitely counters your own!
In my experience, these metaphors are introduced to meet time constraints and produce shitty software.
It's fine to talk about these metaphors as efficiency-accelerants, but they don't produce quality software. Not that there are many companies trying to do that these days.
I have no idea what you mean by quality software, so I can't answer that. Can you give an example? I also have no idea what your alternative framing is. It seems like fundamentally not how people think of software.
> The "primary goal" as you state is often characterized by others as "bias"
...yes, that's the point of I (and I believe the others) have been making. People are generally biased to focus on the happy path.
I'm honestly having trouble figuring out your line of argument from your various comments. Maybe I misunderstood what you said earlier about your experience contradicting mine. Were you actually saying that you really did believe everyone else was worse at programming?
What? I'm surely just as vulnerable to giving a shit about the happy path as everyone else. I'm just saying this leads to bad software, and anywhere you see good software produced you see people giving inspection to the code paths they suspected were error-free. The conception that giving extra attention to the error path leads to better software seems to entirely confuse the concept of a flawed program with some kind of finite bulk work that needs to be done.
There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.)
The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny.
Such is the reality of working on complex systems (or simple object-oriented programs ;))
But I insist the "unknown unknowns" are handled extremely simple, predictable and decoupled. Because those happy paths will fail. And then the exception-path must take over and this must be able to handle it predictable.
So no third party error services that I have to call over HTTP (HTTP will fail). No complex logging libraries (dependencies will become outdated). No difficult tracing middleware that has to be configured "just right" (configs will break). And certainly no flows that require a spaghetti-wrangler to follow along.