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

191–200 of 218 posts

Re: Against Best Practices

#191

Post by lmm »

cpill wrote: post #134
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…

I think the problem is that a lot of computer nerds are a bit OCD and like to apply one solution to everything. You see this with how they get crazy about strictly typed versus not strictly typed, one particular language for every application, or spaces vs tabs. I was like that when I was younger but as I get older I realized the world is the complex place and has programs have to deal with the real world there is no…

Funny, my experience is the opposite. When I was younger I thought there was a time and place for everything, a right tool for the job, a need to carefully consider the circumstances. As I got older I realised that actually a lot of libraries, languages, and communities are simply bad, and an experienced programmer is better served by having a deep knowledge of a handful of good tools and applying them to everything.

Re: Against Best Practices

#193

Post by bitwize »

I've found that "best practice" generally means "what you will not get fired for doing". Sometimes it is a good practice. Sometimes it's something the higher-ups read about in CTO magazine and decided that everybody now must do. I'd say use your individual judgement, but depending on your role and the company, using your own judgement may be beyond your pay grade.

Re: Against Best Practices

#194

Post by srkiNZ »

Great article! I feel like I am dealing with so much of this behaviour at my job recently. It feels like most of the people espousing Best Practice never learned that "appeal to authority" was not a reasonable argument.

Re: Against Best Practices

#195

Post by chthonicdaemon »

michael1999 wrote: post #131
chthonicdaemon wrote: post #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 thro…

Who drove that standardization in chemical engineering? I ask, because the intra-organizational dynamics of software have been ugly for standardization. Vendor lock-in, submarine patents, embrace-and-extend, etc. have meant naive adoption of "best practices" meant a one-way ticket to an expensive, obsolete system, with an eventually insolvent vendor.

That's an interesting question. I guess it's partly the fact that chemical industry is very large-scale, often with one company in charge (think Shell or Total). The realities of having one organisation in charge of many large operations across many countries probably gives higher reward on standardisation. This is a bit like coding to "Google style guidelines" or whatever. The big organisation has more incentive to fund standardisation, but the small people can benefit from that effort, too.

The magnitude of impact also means that many industrial plants fall under government regulation, and in the safety field specifically there is a lot of knowledge sharing.

I think there is also a component about the inflexibility of real matter that factors into this. It's much harder to attach two incorrectly sized pipes together than it is to write a software shim, so the standardisation of pipe sizes and gets pushed up to the original manufacturers, where it also happens to be more economical to produce lots of exact copies than individually crafted parts.

Re: Against Best Practices

#196

Post by 0xbadcafebee »

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

Earlier quoted context omitted.

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)

I could tell you the moon is made of cheese. If I'm wrong about it being made of cheese, does that mean the moon doesn't exist?

Re: Against Best Practices

#197

Post by deathanatos »

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.

I think it's the same thing, but I usually postulate DRY as semantically identical code, not merely syntactically identical.

"Byte for byte equivalent" doesn't necessarily mean it's a copy, if the semantics of it are different.

Re: Against Best Practices

#198

Post by akvadrako »

worik wrote: post #122

No. I've worked too often with people who think they know better They do not Straw men do not change the fact that "best practices" , especially the ones quoted, are very good. No sensible person is saying "never use globals". We caution you to think very carefully before you do, only for truly global state. I am suffering from inherited code, written by a very good programmer, who got lazy with globals and comments.…

I've been on a team where most comments I added where deleted because they believed it was best practice to avoid them getting out of sync with the code.

So even your comment disagrees with your claim that "best practices" are very good.

Re: Against Best Practices

#199

Post by kybernetikos »

lkrubner wrote: post #80

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

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

Most things of any value are abstractions. You take a country by persuading everyone you've taken a country, the implementation details of that argument might involve some grassy hill tops, some fields and farm buildings, but its absolutely not the case that an army needs to control every field and every grassy hill top that makes up "a country" in order to take it. The abstraction is different to the sum of its specific parts.

If you try to invade a country by invading every concrete bit of it, you'll either fail to take it or have nothing of value at the end (i.e fail in your objective). The only reason it has ever been useful or even possible to invade countries is because countries are abstractions and it's the abstraction that is important.

> The real work is made up of specifics: buildings, roads, trees, ditches, rivers, bushes, rocks, fields, houses.

Specifics are important - failing to execute on specifics dooms any steps you might make to help achieve your objective, but if all you see is specifics you won't be able to come up with a coherent objective or choose a path that would stand a chance of getting you there.

Re: Against Best Practices

#200

Post by yazantapuz »

Teaching threads on a operating systems course, i have witnessed some of the more convoluted code ever by students so afraid on global variables that they turned simple exercises into monstrosities. So yes, f*ck the rigid rules. They have to unlearn best practices guidelines, to which they were "blood-written sacred rules".
Post reply on HN