Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against Best Practices

arp242.net

Post reply on HN
Print view View original

41–50 of 218 posts

Re: Against Best Practices

#41

Post by lolinder »

muro wrote: post #28
f1shy wrote: post #8

Earlier quoted context omitted.

Basically if you know exactly why the best practice/rule is in place, and know for sure it does not apply, just skip it. But not before. https://en.wiktionary.org/wiki/Chesterton%27s_fence

That's very reasonable. ‘The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.’

> Therefore all progress depends on the unreasonable man.

The unfortunate corollary to this is that all retrogression also depends on the unreasonable man. The reasonable person (as defined here) maintains the status quo, for good or ill.

Re: Against Best Practices

#43

Post by begueradj »

cjblomqvist wrote: post #33
vbezhenar wrote: post #2

How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…

A nit; DRY is probably not what you think it is. DRY is basically the same as SRP, framed differently. In SRP, it's totally valid to have the code twice if it has different meaning from a user pov.

Quoted: "You can still not repeat yourself but violate single responsibility"

(https://softwareengineering.stackexchange.com/questions/2207...)

Re: Against Best Practices

#44

Post by resonious »

rileymat2 wrote: post #31
eapriv wrote: post #30

Software around us is quite terrible, so it’s kind of obvious that one shouldn’t follow “best practices” that led to this state of things.

That implies they were created with best practices in the first place.

If not, then what was created with best practices in the first place?

If we can agree that most large, financially successful software projects are of questionable quality, then either

- they used best practices and yet they still suck, OR

- they did not use best practices, but are widely successful anyway.

So no matter how you look at it, software best practices just haven't panned out.

Re: Against Best Practices

#46

Post by auggierose »

larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

> Follow best practices unless you can give a reason not to.

Cargo culting much?

I'd say, follow best practices only if you can say exactly why it is best practice.

Re: Against Best Practices

#47

Post by lolinder »

Angostura wrote: post #23
ohthatsnotright wrote: post #11

Earlier quoted context omitted.

Often what is one developers "best practice" is another's "anti-pattern" because a lot of this is just arbitrary.

If it is arbitrary, it’s “standard practice”.

Which still has immense value.

It's standard practice to install outlets with NEMA connectors in North American buildings. Sure, you could technically swap those out with a more optimal connector that is "better" (one that prevents electricity from flowing while the plug is partially exposed, for example), but using the standard practice is best practice for human-shaped reasons that are often not apparent to early-career engineers.

Re: Against Best Practices

#48

Post by nine_k »

throw310822 wrote: post #34
f1shy wrote: post #8

Earlier quoted context omitted.

Basically if you know exactly why the best practice/rule is in place, and know for sure it does not apply, just skip it. But not before. https://en.wiktionary.org/wiki/Chesterton%27s_fence

I would reverse this: if you can explain to me exactly why your so called "best practice" applies here and now, good. Otherwise it's a nice input to have in the discussion, but nothing more.

It depends on your risk appetite. A best practice likely keeps you away from pitfalls known to the community of the practice but not to you. It also may keep you away from crafting a solution that is optimal for your specific circumstances not known or applicable more widely.

In high-reward / low-risk environment, such as building an indie turn-based retro-style game, go with your gut feeling unless you have a good reason not to.

In a high-risk / dubious-reward environment, such as implementing cryptography, follow the best practices to a t, unless you know intimately how things work and maybe codified some of the practices.

There is a wide gamut between these two extremes.

Re: Against Best Practices

#49

Post by vbezhenar »

cjblomqvist wrote: post #33
vbezhenar wrote: post #2

How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…

A nit; DRY is probably not what you think it is. DRY is basically the same as SRP, framed differently. In SRP, it's totally valid to have the code twice if it has different meaning from a user pov.

The problem with definition is that it's subjective and cannot be checked automatically. So my definition was about mechanistic DRY, which is objective and checked by linter.

Re: Against Best Practices

#50

Post by bayindirh »

auggierose wrote: post #46
larsrc wrote: post #6

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

> Follow best practices unless you can give a reason not to. Cargo culting much? I'd say, follow best practices only if you can say exactly why it is best practice.

I don't think so. For example, If I'm writing something in a programming language I don't know by heart, I start by following the best practices recommended by the language authors, then start to flex them when they become less useful, until I hit a nice pitfall which these best practices are designed to avoid.

This allows me to start faster, and be in a better shape in short term. Then I can flex advice more and more as I understand how a language works under the hood.

Post reply on HN