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

91–100 of 218 posts

Re: Against Best Practices

#91

Post by uludag »

> “Don’t use globals” is obviously good, but “never use globals under any circumstances” is just silly

I'm actually not even convinced that this is a good rule. When it's explained it makes sense on the surface. I also think that since beginners to programming use global variables, they come to the conclusion that it must be universally bad since that's what their beginner self did.

Having work on codebases with most state being being stored as global variables (in a single namespace at that) is manageable at worst and easy to develop on at best, assuming certain conventions are followed.

Re: Against Best Practices

#92

Post by kthejoker2 »

IME "best practices" is a demand problem, not a supply problem. IE far more people want best practices than there are actual best practices.

Prospects and customers desperately want to know our "best practices" and then complain when we say "it depends" or something experimentation is required, as if we are hiding secret teachings from them.

For me this is more a personality test: people who just want solutions on a silver platter vs DIYers who want to tinker and distrust black boxes.

Re: Against Best Practices

#93

Post by marcosdumay »

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?

The books that encode some standardized Xbok are always named "The guide to the Xbok".

The actual BOK isn't supposed to have a concrete representation. It's not supposed to be standardized either, but standard organizations always ignore that part.

Re: Against Best Practices

#95

Post by antirez »

I agree with the sentiment of the article, but Postel law is a good idea that has very little to do with the context. Of course the real problem is that it's a very small advice that needs to be put into context each time, and here is the failure of all the types of advices: they are not substitutes for intelligence and good design tastes.

Re: Against Best Practices

#96

Post by davorak »

betenoire wrote: post #87

Only software engineers pretend best practices exist outside of any useful context. - small localized team vs big distributed team - bug fixes and incremental improvements vs green field poc - saas vs system scripts Context matters, and if people aren't giving you the context in which they deem practices to be "best", they are myopically wrong

So outside of coworkers that have a hard time collaborating in general, is it a problem for others that their coworkers will not apply context? That has not been my experience.

Re: Against Best Practices

#97

Post by agentultra »

davorak wrote: post #90
TehShrike wrote: post #77

Earlier quoted context omitted.

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

I do not know what context this happened to you in, but in the context of building something quickly, learning, while not being an expert in an area, best practice are a common crutch. In many work places either they do not have time or at least think they do have time to think things through 100% for themselves from first principles so they depend on best practices instead. That makes sense to me and I would expect…

100%… a best practice in other traditional engineering practices help us work within the state of the art. They’re the accumulated wisdom and experience of engineers that came before us.

There are plenty of them that help us write concurrent code that avoids common deadlock situations without having to resort to writing proofs every time. Someone already did the work and condensed it down into a rule to follow. Even if you don’t understand the underlying proof you can follow the rule and hope that everything will shake out.

What I find we struggle most with is knowing when we actually need to write the proof. Sometimes we bias ourselves towards best practices and intuition when working it out formally would be more prudent.

Re: Against Best Practices

#98

Post by agentultra »

marcosdumay wrote: post #93
javcasas wrote: post #59

Earlier quoted context omitted.

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?

The books that encode some standardized Xbok are always named "The guide to the Xbok". The actual BOK isn't supposed to have a concrete representation. It's not supposed to be standardized either, but standard organizations always ignore that part.

This. They’re supposed to represent the state of the art which is constantly evolving.

Re: Against Best Practices

#99

Post by HelloNurse »

grey-area wrote: post #4
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…

Other engineering disciplines have certification, codes and regulations for specific domains, which are enforced by law. DRY is a perfect example though of something which in moderation is a good idea but as the article says is vulnerable to ‘inexperienced programmers who lack the ability to judge the applicability’ and if over-eagerly applied leads to over-abstraction and premature abstraction which does more harm t…

Before regulations, other engineering disciplines have far more objective decisions and calculations than software engineering. Consider a mechanical analogue of DRY: choosing between reusing identical parts to make design, assembly and repairs simpler or designing similar but different parts because they are worth optimizing (e.g. a whole IKEA cabinet with interchangeable screws or with short and long ones). Unlike next month's shifting software requirements the cost and performance of this kind of alternative can be predicted easily and accurately, without involving gut feelings or authority.

Re: Against Best Practices

#100

Post by dambi0 »

lolinder wrote: post #47
Angostura wrote: post #23

Earlier quoted context omitted.

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-c…

I’m a bit confused with the analogy here. Would the non NEMA outlets work with my existing things or is the implication that they wouldn’t?
Post reply on HN