Hacker News Reader

Comment by vorpalhex | Hacker News Reader

It's a sign of significant inexperience to be locked into a singular way of doing things and to have such hard rules.

The goal is to achieve the end, not enforce a particular style. If long descriptive variable names work for your project, use them. If they don't work, don't use them.

If you have to live by such fixed rules, you won't be a very useful developer.

View on HN

Agree with your general point, but I think this specific set of rules (maybe besides the function name length thing) read like experience rather than inexperience. I think this is a list of stuff that all seems fine at first, but has eventually burned anyone who has been doing the job long enough.

Assuming you only maintain a single API, why is domain logic in http controllers so bad?

- you have twice as many signatures to maintain, which will become inconsistent with each other

- introducing a new layer when you eventually need it, isn't more work than maintaining it now

- Unlike other IO, REST frameworks are easy to test in memory

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

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

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.

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.

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.

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.

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

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

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

I thought it was clear, but perhaps my English is not at that level yet. All the bullet points except the last one were more or less tongue in cheek. Sure, long names are required some times, just like super short names have their place as well.

This is true if you get pull requests from people since there is a certain limit to how many of those you can get.

However if you get pull requests from robots then you might eventually want to set down some rigid rules. Who has time to argue with the 36ths LLM contributor of the day? As eloquent as they might be. ;)

Reply on news.ycombinator.com