Live data from Hacker News

Against Best Practices

arp242.net

161–170 of 218 posts

Re: Against Best Practices

#161

It took me way too long to realize this, but my experience is that "zealots, idiots, and assholes" (as the author says) are going to abuse something and wield it as a bludgeon against other people. This appears to be a fixed, immutable property of the universe. If you take it as a given that some number of people are going to get an idea lodged in their head, treat it like gospel, and beat as many other people in the…

The one thing that gives me pause, is that I have seen stages of mastery where the base stage is repetition and adherence to rules to internalize them before understanding them and knowing when to break them.

If much of our industry is new, evangelizing these rules as harder and faster than they are makes a lot of sense to bring people to get people ready for the next stage. Then they learn the context and caveats over time.

Re: Against Best Practices

#162

Earlier quoted context omitted.

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

Quoted: "Likewise, you can repeat yourself but classes only have a single (duplicated, but subtly different) responsibility."

Re: Against Best Practices

#163
I see "best practices" as just case studies. Here's one possible way to do it. If it intrigues you, you can do the same.

Most of these "best practices" have valid opposing camps anyway. There's DRY, but there's also "a little copying is better than a little dependency". Both are valid in different contexts.

Re: Against Best Practices

#164
post #96

Earlier quoted context omitted.

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.

I don't understand the question... If someone has a strong opinion, and they have arguments for their opinion, but don't recognize the significance of the context in which they've formed their opinions, they have blind spots they aren't aware of. Is that a problem? I dunno, that's up to you and your environment.

> Only software engineers pretend best practices exist outside of any useful context.

I am not seeing this issue with programmers in general or with my coworkers, with the exception of those who in general have a hard time collaborating with others.

So my question was/is if you discount the above exception are people seeing a problem with programmers/coworkers not taking context in to account? I have not noticed a wide spread issue and I am interested in how prevalent you, and others, perceive the issue to be.

Re: Against Best Practices

#165

Earlier quoted context omitted.

I don't understand the question... If someone has a strong opinion, and they have arguments for their opinion, but don't recognize the significance of the context in which they've formed their opinions, they have blind spots they aren't aware of. Is that a problem? I dunno, that's up to you and your environment.

> Only software engineers pretend best practices exist outside of any useful context. I am not seeing this issue with programmers in general or with my coworkers, with the exception of those who in general have a hard time collaborating with others. So my question was/is if you discount the above exception are people seeing a problem with programmers/coworkers not taking context in to account? I have not noticed a wi…

Aren't these discussions the evidence? The fact that the author wrote a blog post and we are here discussing it. I might be missing the point of your question. This is everywhere around us in the development world. Anytime people compare react to htmx, redis to postgres, TDD vs BDD.

I'd like to point out I never called it a problem. I said that was a judgement call for you to make. We all have harmless biases.

But yeah, it can be a problem. If I have an engineer derailing my team because of his insistence for svelte, and can't read the room: ie can't take any of the context of the business, stack, domain, team, into his consideration, then yeah, it becomes a problem. Time is money

(svelte isn't a good example, it's not a best practice per se. s/svelte/TDD/)

Re: Against Best Practices

#166

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…

> No army has ever conquered a country Napoleon and his army would like to have a word with you… I get the analogy but I think it can be made a lot better, which will decrease people who dismiss it because they got lost in where the wording doesn’t make sense. I’m pretty confident most would agree that country A conquered country B if country B was nothing but fire and rubble. It’s pretty common usage actually. Also,…

> I’m pretty confident most would agree that country A conquered country B if country B was nothing but fire and rubble.

I think we can all agree that if that is the case, you’ve in fact conquered nothing.

Edit: Since we say opposite things, maybe we wouldn’t agree.

Re: Against Best Practices

#167

Earlier quoted context omitted.

The army that is conquering is carrying best practice weapons, wearing best practice boots, best practice fatigues, best practice tanks, trucks, etc. They're best practice aiming, shooting, walking, communicating, hiring (mercs), hiding, etc... The people that are in the weeds are just doing the most simple things for their personal situation as they're taking over that granite rock or "copse of lush oak trees". It's…

This is frequently not true. There’s examples all through history of weaker and poorer armies defeating larger ones. From Zulus, to the American Revolution, to the great Emu wars. Surely the birds were not more advanced than men armed with machine guns. But it’s only when the smaller forces can take advantage and leverage what they have better than others. It’s best practices, but what’s best is not universal, it’s b…

> It’s best practices, but what’s best is not universal, it’s best for who, best for when, best for under what circumstances.

I’m pretty sure building an organization on a free for all principle is anathema to the idea of an organization.

Re: Against Best Practices

#168

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 not sure folklore and handwaving is worse than relying on some sort of bible some mysterious organisation wrote as your source of truth.

Re: Against Best Practices

#169

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…

> Most best practices that I have been told about were low local maxima at best, and very harmful at worst. This matches my experience, though sometimes they indeed will be helpful, at least after some consideration. > If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it. In certain environments this will get you labeled someone who doesn't want to create qualit…

Hmhm, just like “AWS is recommending serverless, so we should serverless everything!”

Never mind that AWS recommends what is good for AWS, not us.

Re: Against Best Practices

#170

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)

In general that is true, I think. Even if it doesn’t apply in all circumstances, it’ll apply in most.

It’d be ideal if you could identify when it doesn’t work. But in the absense of that applying it everywhere is still a net positive.

Post reply on HN