Why is it so common for people to insist on following particular patterns at PR when they have no concept of why the pattern originated or when and why it should apply?

i mean to be fair, you dont need to know the patterns history to be allowed to use it. But it definitely makes sense to know, where it is a good idea to use it, and by extension even more important where to not use it.

I would argue that patterns should be followed for consistency to make collbaration easier. Ofcourse if you are using a hammer to kill a fly just because you can then its a problem.

Becuase using a tradition is easier then using thier brain.

If they cannot explain why the pattern is used, they should not do a CR.

Depends.

Pattern as in design patterns?

Makes sense. As long as it is a discussion, where you can talk about _why_ this makes sense, it's fine.

If the sentence starts like "You must"...

Go rim your own arse and die from a broken neck.

@IntrusionCM exactly. There was a conversation at PR that went "Rename this to something more generic" -> "that doesn't make any sense: this is a model specific to a particular external service: there is no potential for reuse or suggestion we could swap this out for another implementation: we are pretending something isn't tightly coupled but it is, which is mislead and thus degrades the quality and readability of the code, which is the opposite of what you are supposed to be getting by doing this" -> "Yes, you're right, but follow the pattern anyway".

This person doesn't have seniority but they know since the team lead is on holiday and there is no-one else to approve it they can camp the PR to get their way even when they have themselves excepted the reasoning doesn't make sense 😡. Just seems like a power grab rather than any legitimate technical thing at this point

@PeterDCarter Just follow what he says and cover your ass - in the future if someone is unhappy about some naming or solution, they can track it down to comments in your PR.

@PeterDCarter I fully agree with your example: when a function is just used in one place for a very specific purpose - it's counterproductive to make it generic.

If someone in the future finds that this function can be useful in more scenarios, it's easy to rewrite it into a more generic thing at that time.

I find that it's common for junior devs to become overly reliant on stric rules and patterns. Especially common in code reviews, because it's easier to measure code by some objective rules, than case-by-case, if you're not senior.

I find it's a journey most programmers go through. At level 1 we're all over the place, at level 2 we get into patterns and sometimes want everything and everything to use these patterns, at level 3 we learn a balance.

(Now, that being said, if you're developing a public API, enforcing some standards and patterns is necessary. But for most internal repos, you can be more flexible)

@jiraTicket Yeah, I need to remember that it's hard enough to see your own patterns at that level and other people's patterns adds more cognitive load than you can deal with. I see how I was at error in expecting too much too soon, though I feel there is a lot more complexity to the point that directly talking about that wouldn't help. Your input is really useful tho. Feel seen