Live data from Hacker News

Against Best Practices

arp242.net

51–60 of 218 posts

Re: Against Best Practices

#51
Rules travel further than reasons.

The problem is that a lot of true things in the world are counter-intuitive. So insisting that all the rules "make sense" in an immediate way is clearly a non-starter. In the safety industry there are many examples of best practices that are bred from experience but end up being counter-intuitive to some. For instance, it might not make intuitive sense that a pilot who has gone through a take-off procedure thousands of times needs a checklist to remember all the steps, but we know that it actually helps.

It's hard because there is usually some information loss in summarisation, but we also have limited memory, so we can't really expect people to remember every case study that led to the distilled advice.

As a chemical engineer by training, though, I have constantly been amazed at how resistant software people are to the idea that their industry could benefit from the kind of standardisation that has improved my industry so much.

Re: Against Best Practices

#52
post #38
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.

What if the "best practice" was invented by a VC funded company (like, just for example, Vercel) desperate to maintain their growth trajectory by any means necessary, including huge marketing pushes to convince everybody the "best practice" is the "best way to do things"? It's downright dangerous to assume a "best practice" in software development somehow automatically means it's some super distilled wisdom juice. A…

I mean, consuming anything without vetting the source of the information is a bad practice in general.

...or,

The best practice of best practices is vetting the source of the best practice to verify its authenticity.

No?

Re: Against Best Practices

#53
post #48

Earlier quoted context omitted.

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

> A best practice likely keeps you away from pitfalls known to the community of the practice but not to you.

In my experience, many "best practices" are the pitfalls you should be wary about, as they can easily translate into hundreds or thousands of lost hours of work and derail and doom entire projects. (The most annoying part of this is that the real causes won't be found, precisely because "best practices have been followed". Therefore the reputation of the best practice will stay untarnished).

Cryptography on the other hand is a well known example of something you should not touch at all unless you are an absolute expert- that's not even a "best practice" but probably the only reasonable practice.

Re: Against Best Practices

#54

Earlier quoted context omitted.

Those approaches do work with programming, but they don't make use of what makes programming different from other disciplines. Software is usually quick to write, update and deploy. And errors usually have pretty low impact. Sure, your website may be down for a day and people will get grumpy, but you can hack together a quick fix and have it online with the push of a button. Compare that to, say, electrical engineeri…

You can destroy rockets, lethally irradiate people, fly planes upside down, or financially ruin a company because of software bugs, so avoid faults can be critical for software as well. It is just that high-velocity low-reliability web and consumer application development is a very large niche. A lot of our best-practices are about attempting to maintain high velocity (often with questionable results), more than incr…

> It is just that high-velocity low-reliability web and consumer application development is a very large niche

And most of them have no care about the user experience of the end user at all.

Almost every piece of software I have to interact with on a daily basis is absolute garbage. Just full of frustrating bugs that makes most of my day when I'm forced to use a computer absolutely miserable. But to each of the devs it's just a small annoyance in their particular app. Not caring to the end user it's one annoyance that leads to a death by a thousand cuts.

Software is just atrocious nowadays.

Re: Against Best Practices

#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 out of hand either and people recommending them aren’t idiots.

Update: one problem with “best practices,” that I think the article might have unwittingly implied is that most software developers aren’t aware of SWEBOK and are repeating maxims and aphorisms they heard from others. Software development is often powered by folklore and hand waving.

Re: Against Best Practices

#57
I hear the phrase "best practices" not from the best practitioners, but from Dunning-Kruger types.

Recently I was told that Hungarian notation was "best practice" and I must use it.

Re: Against Best Practices

#58
post #39

Best practices are a way to avoid building everything up from first principles every time. They are more, “here are rules that are generally applicable so you don’t have to waste time thinking,” vs “here are laws of god which are always applicable.” It is an error to throw out every best practice and reconsider everything just as it is to blindly follow the best practices. IMO it’s best to apply the best practices by…

Maybe "good practice" is a better term.

I've seen (and started using) "current common practices" instead of "best practices" where it makes sense.

In an always-evolving technology landscape, it feels like a better representation of what we're doing, and it helps prevent the kind of dogmatic stubbornness that forms around the word "best".

Re: Against Best Practices

#59

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?

Re: Against Best Practices

#60

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…

> How other engineering industries deal with this phenomena?

They don't. CAD, the "programming languages" of most other engineering disciplines, is as much of a Wild West.

Post reply on HN