[betenoire]

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

[davorak]

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.

[betenoire]

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.

[davorak]

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

[betenoire]

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

[davorak]

> 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

I would describe this someone who does not know how to collaborate, maybe they don't know the balance they need between give and take, maybe they do not know how to format their ideas so they are understood by the group, maybe there is some fundamental misunderstanding. Since the tool of collaboration is not working for them, they reach for other tools to leverage and achieve their goals, like argument by authority via a convenient best practice.

The best practice/standard was not the issue, lack of context for the best practice was the the issue, the lack of collaboration or ability therein is the issue.