4 ms·

Perhaps the implication is not "extra vigilant ... [compared to my level of vigilance on the happy path]", but rather "extra vigilant ... [compared to other

by hnrhn 3y ago

Perhaps the implication is not "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.

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
JeffSnazz 3y ago
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!
- rimunroe 3y ago
  > 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.
  - JeffSnazz 3y ago
    > 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!
    - rimunroe 3y ago
      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.
      - JeffSnazz 3y ago
        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.
        rimunroe 3y ago
        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.

by hnrhn 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

JeffSnazz 3y ago

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!

rimunroe 3y ago
> 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.
- JeffSnazz 3y ago
  > 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!
  - rimunroe 3y ago
    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.
    - JeffSnazz 3y ago
      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.
      - rimunroe 3y ago
        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.