Hacker News Reader

Comment by rimunroe | Hacker News Reader

> I don't tend towards expressing personal comparisons "in public" since they seem both inevitable regardless of the situation and disrespectful to bring up as a topic of interest—not to mention potentially exposing you as incompetent yourself. I guess not everyone else feels the same way.

> 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.

View on HN

> I don't think it's putting down other people you've worked with, holding yourself up as some paragon, OR belittling your own abilities. 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!

Could you elaborate? I've seen this tendency (or an acknowledgement of it) in even the best people I've worked with, ones who are far better programmers than me. I've spent a lot of my career primarily pair programming, so I've had ample opportunity to talk with them about stuff like this explicitly.

What matters is the structure of the program per se. The entire concept of the happy or error path is a cultural phenomenon that requires explicit acknowledgment and rejection to solve (excepting languages that demand error-handling to function)

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 think you're wrong on this. How often does software get created without the creator having a primary goal in mind? How often is the main goal handling things going wrong? If I write something to build a chart out of some logs, the first, most basic thing I'm going to evaluate it on is "can it make the chart?", not "how does it handle a malformed log entry?". I will think about these things, but they're inarguably not the first thing (the happy path) I think about when I think about the purpose of the code as a whole.

I mean, how often is quality software made? I agree with you, but I'd argue most software is compromised by shitty incentives. Humans mostly write buggy and incoherent software—this is solved by consensus across disparate incentives. The "primary goal" as you state is often characterized by others as "bias"

> I mean, how often is quality software made?

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?

> 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.

Reply on news.ycombinator.com