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

71–80 of 218 posts

Re: Against Best Practices

#71

Post by [deleted] »

javcasas wrote: post #59
agentultra wrote: post #55

I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge . There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE. The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree. However they shouldn’t be rejected ou…

I'm one of the devs not aware of the SWEBOK. Searching the internet all I can find is links to "the guide to SWEBOK". https://ieeecs-media.computer.org/media/education/swebok/swe... But, you know, I want the whole ordeal. I want the SWEBOK, not the "how to read the SWEBOK". Where can I find it?

[deleted]

Re: Against Best Practices

#72

Post by convolvatron »

gspencley wrote: post #66

> but because they’re mostly pounded by either 1) various types of zealots, idiots, and assholes who abuse these kind of “best practices” as an argument from authority, or 2) inexperienced programmers who lack the ability to judge the applicability, The author might go on to make other points that are worth discussing, but lays out his supporting arguments clearly in the opening paragraph. Best practices do not neces…

we don't have to give undue value to 'best practices', nor do we need to judge an idea based on its presenter. we just need to have a reasonable discussion about the idea in the context in which its being applied. this simple approach has been largely eclipsed in the industry by the fetishization tools, and the absurd notion that whole classes of approaches can be dismissed as being 'antipattern'.

It's not very hard to weigh a suggestion. speculate about its costs, benefits and risks.

Re: Against Best Practices

#73

Post by binary132 »

I can sense the hackles rising. The arcane magi of the Guidance Council have scried a rebel wizard in their orb. Every cantrip and charm must be uttered at once, with maximal urgency! Invoke the spirits of the tomes!!!

Re: Against Best Practices

#74

Post by TehShrike »

agentultra wrote: post #55

I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge . There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE. The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree. However they shouldn’t be rejected ou…

I think it is best to strongly reject the idea "best practices will always benefit you".

Most best practices that I have been told about were low local maxima at best, and very harmful at worst.

If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.

It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).

Re: Against Best Practices

#75

Post by 0xbadcafebee »

TehShrike wrote: post #74
agentultra wrote: post #55

I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge . There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE. The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree. However they shouldn’t be rejected ou…

I think it is best to strongly reject the idea "best practices will always benefit you". Most best practices that I have been told about were low local maxima at best, and very harmful at worst. If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it. It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason…

I don't think anyone has ever thought that best practices will always benefit you. Nothing always works every single time in every single case.

This whole thing is really silly and obvious.

Of course you shouldn't blindly follow advice without thinking. But not following advice just because it might not always be right is also a bad idea.

My advice: In general, you should follow good advice from experienced people. If enough experts say this is the best way to do something, you should probably do that, most of the time.

But that advice will never trend on HN because it isn't clickbait or extreme, and requires using your noggin.

Re: Against Best Practices

#76

Post by jsbg »

The author sounds like even though they have read extensively about various "best" practices, they did not really gain an understanding of the tradeoffs involved with each one.

> “Don’t Repeat Yourself” (DRY) is basically good advice, but sometimes just copy/pasting things is just the more pragmatic thing to do, and not really a big deal.

Duplicating code on purpose is not about being pragmatic, it's about recognizing when DRY would violate the single responsibility principle.

The ability to weigh tradeoffs in context is what makes some engineers better than others.

Re: Against Best Practices

#77

Post by TehShrike »

0xbadcafebee wrote: post #75
TehShrike wrote: post #74

Earlier quoted context omitted.

I think it is best to strongly reject the idea "best practices will always benefit you". Most best practices that I have been told about were low local maxima at best, and very harmful at worst. If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it. It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason…

I don't think anyone has ever thought that best practices will always benefit you. Nothing always works every single time in every single case. This whole thing is really silly and obvious. Of course you shouldn't blindly follow advice without thinking. But not following advice just because it might not always be right is also a bad idea. My advice: In general , you should follow good advice from experienced people .…

> I don't think anyone has ever thought that best practices will always benefit you.

Whenever a "best practice" or "convention" has been presented to me, that is how it has been framed. (...it is best practice, therefore, it will definitely benefit you to follow it)

Re: Against Best Practices

#78

Post by eapriv »

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.

The name “best practices” kind of implies that they actually are practiced somewhere. So it’s different from theoretical abstract ideas “how we should write software”, which maybe nobody follows.

Re: Against Best Practices

#79

Post by [deleted] »

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…

[deleted]

Re: Against Best Practices

#80

Post by lkrubner »

Dan Morena, CTO at Upright.com, made the point that every startup was unique and therefore every startup had to find out what was best for it, while ignoring whatever was considered "best practice." I wrote what he told me here:

https://respectfulleadership.substack.com/p/dan-morena-is-a-...

My summary of his idea:

No army has ever conquered a country. An army conquers this muddy ditch over here, that open wheat field over there and then the adjoining farm buildings. It conquers that copse of lush oak trees next to the large outcropping of granite rocks. An army seizes that grassy hill top, it digs in on the west side of this particular fast flowing river, it gains control over the 12 story gray and red brick downtown office building, fighting room to room. If you are watching from a great distance, you might think that an army has conquered a country, but if you listen to the people who are involved in the struggle, then you are aware how much "a country" is an abstraction. The real work is made up of specifics: buildings, roads, trees, ditches, rivers, bushes, rocks, fields, houses. When a person talks in abstractions, it only shows how little they know. The people who have meaningful information talk about specifics.

Likewise, no one builds a startup. Instead, you build your startup, and your startup is completely unique, and possesses features that no other startup will ever have. Your success will depend on adapting to those attributes that make it unique.

Post reply on HN