4 ms·

Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job l

Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job long enough, but which requires spilling a bunch of ink to describe why, which won't even work, because you just haven't been burned by it yet. And that's fine, this is just what accumulating experience is about. (And to make it worse, everyone's accumulated experience is different.)

SebastianKra 3y ago
If you find a way to share what I should watch out for, I'd appreciate it :)
- sanderjd 3y ago
  I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.
vorpalhex 3y ago
This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.
- SebastianKra 3y ago
  This cannot be understated. I still remember the Java class where my teacher just couldn't explain to me the reason for getters and setters. It took me multiple years before I finally understood why they used to be so important. In my last year of university, I had a course, that primarily and uncritically discussed GOF Design Patterns without even mentioning how they relate to the improvements in programming languages since then.
  - sanderjd 3y ago
    Yep. But there are a few separate things: 1. I can't explain this because I have no idea why it is a thing and have just cargo culted it. 2. I came to this view through hard-won personal experience, but I don't really remember exactly the underlying situation. 3. I have good reasons for this, which I could explain, but I'm not going to invest the time in that, because it would be time consuming and I've had this same discussion a bunch of times before and I know I'm unlikely to sway you until you just get burned yourself. Unfortunately these are largely indistinguishable, leading many people to conclude that it's always #1.
    - SebastianKra 3y ago
      #3 I can begrudgingly accept. #1 and #2 are indistinguishable, even to yourself. If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I believe, as you get older, you tend to rely on these assumptions more and more, which is why it's us youngsters' job to question them. Ideally, both sides learn something :)
      - sanderjd 3y ago
        Respectfully disagree. I absolutely can distinguish between "I'm just parroting stuff I've read" vs. "I have this opinion for a good reason but I would have to spend time reminding myself what that is". I do both things all the time! Sometimes it's efficient to cargo cult from stuff you've read, even if you come back later with more experience and think "that was sure stupid". > If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I agree that you're less likely to be right in this situation, but it's still a good starting point in the solution space. In general, the key is always to be willing to notice when you made the wrong call and update your priors. But that's doesn't require approaching every question with a blank slate. It's a good thing to lean on experience. Even when you're wrong. You youngsters should absolutely question things. But you also shouldn't think you're right just because nobody has yet convinced you that you're wrong. I'm neither young nor old, which means I can remember when I questioned everything and thought I was right about all of it, and the truth is that I was an idiot :)

SebastianKra 3y ago

If you find a way to share what I should watch out for, I'd appreciate it :)

sanderjd 3y ago
I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.

vorpalhex 3y ago

This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.

SebastianKra 3y ago
This cannot be understated. I still remember the Java class where my teacher just couldn't explain to me the reason for getters and setters. It took me multiple years before I finally understood why they used to be so important. In my last year of university, I had a course, that primarily and uncritically discussed GOF Design Patterns without even mentioning how they relate to the improvements in programming languages since then.
- sanderjd 3y ago
  Yep. But there are a few separate things: 1. I can't explain this because I have no idea why it is a thing and have just cargo culted it. 2. I came to this view through hard-won personal experience, but I don't really remember exactly the underlying situation. 3. I have good reasons for this, which I could explain, but I'm not going to invest the time in that, because it would be time consuming and I've had this same discussion a bunch of times before and I know I'm unlikely to sway you until you just get burned yourself. Unfortunately these are largely indistinguishable, leading many people to conclude that it's always #1.
  - SebastianKra 3y ago
    #3 I can begrudgingly accept. #1 and #2 are indistinguishable, even to yourself. If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I believe, as you get older, you tend to rely on these assumptions more and more, which is why it's us youngsters' job to question them. Ideally, both sides learn something :)
    - sanderjd 3y ago
      Respectfully disagree. I absolutely can distinguish between "I'm just parroting stuff I've read" vs. "I have this opinion for a good reason but I would have to spend time reminding myself what that is". I do both things all the time! Sometimes it's efficient to cargo cult from stuff you've read, even if you come back later with more experience and think "that was sure stupid". > If you don't remember the conditions that made you chose a solution, how can you be sure that they still apply now? I agree that you're less likely to be right in this situation, but it's still a good starting point in the solution space. In general, the key is always to be willing to notice when you made the wrong call and update your priors. But that's doesn't require approaching every question with a blank slate. It's a good thing to lean on experience. Even when you're wrong. You youngsters should absolutely question things. But you also shouldn't think you're right just because nobody has yet convinced you that you're wrong. I'm neither young nor old, which means I can remember when I questioned everything and thought I was right about all of it, and the truth is that I was an idiot :)