5 ms·

Obviously, I was talking about the situation when it escalated to that person. And if you are going to claim that you know exactly how your code works after a m

by h91wka 7y ago

Obviously, I was talking about the situation when it escalated to that person. And if you are going to claim that you know exactly how your code works after a month, then I call bs on that. Not to mention that 1) people leave companies sometimes 2) 3rd party code can break too.

lallysingh 7y ago
Not obvious. Look, you've already fucked yourself by needing a 4am custom fix. That isn't a language problem.
- magicalhippo 7y ago
  It's not a language problem that you need a 4am custom fix. It can be a language problem if the person who needs to do a 4am custom fix can't understand what the code is supposed to do. Or to put it another way: I'd much rather be debugging some BASIC code at 4am than some Brainfuck code.
  - lallysingh 7y ago
    I think the same person who writes unreadable code in Haskell would write unreadable code in most any other adult language.
  - bpyne 7y ago
    Only a person from the team who wrote the code to begin with should create an emergency fix. Since any developer from that team already knows Haskell, from having worked on the code base, the criticism is ridiculous.
    - magicalhippo 7y ago
      We're all on the same team at work (there's only the six of us), but that doesn't mean I know all the details of my coworkers work. It's also not uncommon that the dev available at 4am is not the one who wrote the code himself. As I pointed out in my previous post, I do feel the language can be a non-trivial factor in allowing a dev like myself to be confident in developing a fix for my coworkers code at 4am. However I don't know Haskell, so I have no idea how it fares in this regard.
      - bpyne 7y ago
        I can understand not knowing the details of your coworkers' modules. This has been true everywhere I worked. However..... Where I work now, on-call was long ago relegated to nothing more than a routing task. The on-call person takes the initial call, figures out who best can solve it, and contacts the person. The guy on my team who writes only in Javascript and Python would NEVER be in the position to make a critical fix overnight in a Java module. For those of us who work in Java, reading the language is trivial but understanding what the module is supposed to do from a high level is non-trivial. People who work in Haskell daily would be the same. This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. While a Javascript developer should NOT try to issue a critical patch in a language (s)he doesn't work in, regardless if the language is Haskell, Python, etc. Any organization requiring you to do so is poorly managed.
        deleted 7y ago
        [deleted]
        magicalhippo 7y ago
        > This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)? If so, I think it's a valid question to ask about a language. Maybe Haskell is just as easy as Java, maybe it is slightly more difficult, maybe it is slightly easier. For example, you can't really do embedded DSL's in Java, but you can in Haskell. If my coworker had used that and I had not yet had time to study it, could it be I would struggle a bit more with grokking his code? I dunno, at least to me it seems possible, but since I've not really used Haskell it might be entirely different.
        bpyne 7y ago
        "Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)?" I'm in complete agreement with you. My contention is that a person who works with a certain language, even Brainfuck, all day every day is going to be able to read it as easily as a person who works in a more "popular" language like Java: even if it's at 4am. Anyone who doesn't work in the language shouldn't be reading it with the goal of implementing a critical fix at 4am. That person should contact a team member who does work in the language. I'm contending that the 4am scenario, as posed by the parent commenter, is a process issue not a language issue. If a manager requires that whoever answers the phone at 4am fixes the problem, even if the person has no knowledge of the language or requirements of the module, then his/her employees should be running to another job because that manager is bad for your health and livelihood.
- h91wka 7y ago
  You write bug-free code? You verify correctness of distributed and concurrent code on type level? What approach do you use: session types, TLA, separation logic? Sounds super cool, that's some seriously bleeding edge stuff! Does your team have open positions?
  - lallysingh 7y ago
    No. You don't put yourself in that position that you need a fix at 4am. Roll back to a prior version, or shut the service down, or go into a reduced-functionality mode (e.g., readonly) as you can. Give yourself time the next day to actually think about the problem with a clear head. At 4am trying to debug code, you're far more likely to cause more problems than fix things. To me, I read this question the same as "Haskell's not useful when you're stuck in a well with a bomb ticking down." The language isn't the problem. It's the situation that's the problem.
    - h91wka 7y ago
      Ok, I won't argue with that. If you don't work with mission critical systems -- sure, #1 doesn't apply to you. Play with any language you like.
      - gowld 7y ago
        Mission-critical systems use SRE principles so no one is debugging code at 4am. If you can't solve a production issue without looking at the source code, you'veong since failed at building a mission critical-system.
        h91wka 7y ago
        Even if your app is 100% bug free and fault-tolerant, sometimes an external system feeds it invalid data and you need to figure out how to contain and revert the damage. That was my last on-call involving reading a lot of code under time pressure (thankfully, not alone and not at 4 am). All commenters who said "It's your own fault for writing crappy code, duh!" perhaps never worked with anything sufficiently complex and expensive.
- bpyne 7y ago
  I can't upvote your comment enough. The use-case for a developer implementing a fix after being pulled out of sleep should be life-and-death circumstances.

by h91wka 7y ago

lallysingh 7y ago

Not obvious. Look, you've already fucked yourself by needing a 4am custom fix. That isn't a language problem.

magicalhippo 7y ago
It's not a language problem that you need a 4am custom fix. It can be a language problem if the person who needs to do a 4am custom fix can't understand what the code is supposed to do. Or to put it another way: I'd much rather be debugging some BASIC code at 4am than some Brainfuck code.
- lallysingh 7y ago
  I think the same person who writes unreadable code in Haskell would write unreadable code in most any other adult language.
- bpyne 7y ago
  Only a person from the team who wrote the code to begin with should create an emergency fix. Since any developer from that team already knows Haskell, from having worked on the code base, the criticism is ridiculous.
  - magicalhippo 7y ago
    We're all on the same team at work (there's only the six of us), but that doesn't mean I know all the details of my coworkers work. It's also not uncommon that the dev available at 4am is not the one who wrote the code himself. As I pointed out in my previous post, I do feel the language can be a non-trivial factor in allowing a dev like myself to be confident in developing a fix for my coworkers code at 4am. However I don't know Haskell, so I have no idea how it fares in this regard.
    - bpyne 7y ago
      I can understand not knowing the details of your coworkers' modules. This has been true everywhere I worked. However..... Where I work now, on-call was long ago relegated to nothing more than a routing task. The on-call person takes the initial call, figures out who best can solve it, and contacts the person. The guy on my team who writes only in Javascript and Python would NEVER be in the position to make a critical fix overnight in a Java module. For those of us who work in Java, reading the language is trivial but understanding what the module is supposed to do from a high level is non-trivial. People who work in Haskell daily would be the same. This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. While a Javascript developer should NOT try to issue a critical patch in a language (s)he doesn't work in, regardless if the language is Haskell, Python, etc. Any organization requiring you to do so is poorly managed.
      - deleted 7y ago
        [deleted]
      - magicalhippo 7y ago
        > This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)? If so, I think it's a valid question to ask about a language. Maybe Haskell is just as easy as Java, maybe it is slightly more difficult, maybe it is slightly easier. For example, you can't really do embedded DSL's in Java, but you can in Haskell. If my coworker had used that and I had not yet had time to study it, could it be I would struggle a bit more with grokking his code? I dunno, at least to me it seems possible, but since I've not really used Haskell it might be entirely different.
        bpyne 7y ago
        "Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)?" I'm in complete agreement with you. My contention is that a person who works with a certain language, even Brainfuck, all day every day is going to be able to read it as easily as a person who works in a more "popular" language like Java: even if it's at 4am. Anyone who doesn't work in the language shouldn't be reading it with the goal of implementing a critical fix at 4am. That person should contact a team member who does work in the language. I'm contending that the 4am scenario, as posed by the parent commenter, is a process issue not a language issue. If a manager requires that whoever answers the phone at 4am fixes the problem, even if the person has no knowledge of the language or requirements of the module, then his/her employees should be running to another job because that manager is bad for your health and livelihood.
h91wka 7y ago
You write bug-free code? You verify correctness of distributed and concurrent code on type level? What approach do you use: session types, TLA, separation logic? Sounds super cool, that's some seriously bleeding edge stuff! Does your team have open positions?
- lallysingh 7y ago
  No. You don't put yourself in that position that you need a fix at 4am. Roll back to a prior version, or shut the service down, or go into a reduced-functionality mode (e.g., readonly) as you can. Give yourself time the next day to actually think about the problem with a clear head. At 4am trying to debug code, you're far more likely to cause more problems than fix things. To me, I read this question the same as "Haskell's not useful when you're stuck in a well with a bomb ticking down." The language isn't the problem. It's the situation that's the problem.
  - h91wka 7y ago
    Ok, I won't argue with that. If you don't work with mission critical systems -- sure, #1 doesn't apply to you. Play with any language you like.
    - gowld 7y ago
      Mission-critical systems use SRE principles so no one is debugging code at 4am. If you can't solve a production issue without looking at the source code, you'veong since failed at building a mission critical-system.
      - h91wka 7y ago
        Even if your app is 100% bug free and fault-tolerant, sometimes an external system feeds it invalid data and you need to figure out how to contain and revert the damage. That was my last on-call involving reading a lot of code under time pressure (thankfully, not alone and not at 4 am). All commenters who said "It's your own fault for writing crappy code, duh!" perhaps never worked with anything sufficiently complex and expensive.
bpyne 7y ago
I can't upvote your comment enough. The use-case for a developer implementing a fix after being pulled out of sleep should be life-and-death circumstances.