I've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.

I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.

"They only coded the happy path" is software engineer for "they coded it as if nothing would ever go wrong". It is definitely not good design to do that.

There's an engineering trap/fallacy I like to call "how hard could it be". How hard could it be to build a [whatever] clone? If you find yourself thinking that, stop what you're doing, because the answer is almost always "at least an order of magnitude harder than you think."

What I meant is that most commercial software has a large number of code paths. Because it’s built incrementally, not holistically. This creates complexity and cost.

If you’ve only worked on that kind of software it’s hard to know the alternative which is to aggressively prune code paths and rework your main code.

And open source example is Quake. I rarely come across software whose inherent complexity is more than quake.

Yeah, that's not what the person you were replying to is talking about. I was explaining the jargon.

Complexity and LoC has nothing to do with "only coding for the happy path". Both complex and simple software can be written this way.

A great example is the moltbook hilarity. They slapped together something that looked good and did function -- in the happy case only. They put together an "authorization" flow but exposed their entire database because they didn't know how to secure Supabase. They had no rate limiting on account creation -- so one dude created 1M in an hour.

Even putting aside adversarial usage, you have to code for, like, normal stuff going wrong or your app will lose data, crash, leak information, fall over, etc, etc.

I think you are not considering what I’m saying.

I’ll put you in the “it’s impossible to make software” camp.