3 ms·

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

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 :)
sanderjd 3y ago
This particular one (the level where business logic lives) isn't that sort of "poor experience", in my view. (The other example you pulled out about long names, yeah I don't much care either way about that one.) But the phenomenon you're highlighting is also real. Sometimes rules / guidelines / "best practices" are arbitrary and useless. Other times they're extremely helpful. There isn't any hard and fast rule to differentiate between the two cases. The best we can do is have humans run projects using their judgment. Again, using this "should we separate domain logic from routing / controller logic" example: It's true that some projects are never successful enough for this to matter. But what I look for are opportunities to do things that have very little cost, which also scale well if the project is successful and grows. I think this is one of those things. It is trivial to separate concerns. I would even say it makes it easier to write the code that way; I don't want to be thinking about routing and wen service related cruft when I'm trying to implement some business logic correctly. It makes it harder to test and harder to write, in my view. And I think it also scaling into a large project better is also a big bonus. But I certainly don't think my experiences are the only ones that anyone has. I think I'm right about this, but there are also lots of people I respect who disagree with me and they think they're right about the opposite view. Unfortunately there isn't some divine referee to tell us who is actually right :)

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 :)

sanderjd 3y ago

This particular one (the level where business logic lives) isn't that sort of "poor experience", in my view. (The other example you pulled out about long names, yeah I don't much care either way about that one.) But the phenomenon you're highlighting is also real. Sometimes rules / guidelines / "best practices" are arbitrary and useless. Other times they're extremely helpful. There isn't any hard and fast rule to differentiate between the two cases. The best we can do is have humans run projects using their judgment. Again, using this "should we separate domain logic from routing / controller logic" example: It's true that some projects are never successful enough for this to matter. But what I look for are opportunities to do things that have very little cost, which also scale well if the project is successful and grows. I think this is one of those things. It is trivial to separate concerns. I would even say it makes it easier to write the code that way; I don't want to be thinking about routing and wen service related cruft when I'm trying to implement some business logic correctly. It makes it harder to test and harder to write, in my view. And I think it also scaling into a large project better is also a big bonus. But I certainly don't think my experiences are the only ones that anyone has. I think I'm right about this, but there are also lots of people I respect who disagree with me and they think they're right about the opposite view. Unfortunately there isn't some divine referee to tell us who is actually right :)