I feel like we're talking past each other. I tend to agree with you, I don't like having a "bible" and "celebration of design patterns as a catalogue of general wisdom".

But formalising concepts with words makes sense. If your company maintains a catalogue of their patterns, and someone happens to know that this specific pattern is usually called a "singleton", I would find it weird to call it a tomato.

Some patterns have different names in different contexts or languages, and that's fine. I don't find it weird to have a discussion around "in this language there is this pattern that they call X, does that ring a bell for you working on that other language? The idea is [...]", and maybe the answer is "yep we have it too" or "oh, we call that Y, but that's pretty similar".

▲

Yokohiii 4 days ago | parent [-]

Well I guess I am not clear enough. Naming stuff is a normal human habit, maybe even why we have language? So we can agree on that, it's helpful. But you say it yourself, a thing is called different in another language, so the thing is bigger then the word. But everyone can handle it better in his own head and in communication with a word for it. I guess my usual grief is that any kind of excessive celebration and ceremony comes down to some kind of brainwash. Which mostly affects newbies and cultists. The article for example isn't overtly critical on singletons, while past design pattern writings often heavily disregarded the use of it. So we don't just always reiterate the good, but also the bad.

▲

palata 4 days ago | parent [-]

I don't mind the celebration and ceremony as long as they don't bother me personally. I wouldn't fight against the existance of a PatternConf, I just wouldn't go :-).

I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their newly-learned concept and the hierarchy doesn't allow me to prevent them from doing it, anyway they will do it. So instead of fighting I just let them, and if it turns out to be a waste of time in the end... well that's not my problem: I was not in a position to prevent it in the first place.

It's not only patterns though: some juniors have a way to try to use every exciting framework or library or tool they just discovered.

▲

Yokohiii 3 days ago | parent [-]

The silly thing is that I've been the same when I started. A high energy kid playing around and celebrating everything fresh and new, with a big ego.

Probably a bad habit trying to stop them, they need to learn walking before they can sprint. The question is always how to put limits on them? I say it's overengineered, they say it's modern code and I am old. So what do you do if they send you a PR that is just plain wrong? I mean it seems like you delay the conflict from upfront design/planning to pull requests.

	▲	palata 3 days ago \| parent [-]
		I have been in two different situations: * Functional teams (established companies): enough seniors are here to tell the juniors when they are wrong, and the juniors naturally accept the criticism because it's expected in that environment. * Dysfunctional teams (startups): most devs are juniors anyway, there is no clear hierarchy, managers are still at their first job so they have never seen a functioning team or had a competent manager themselves. In the second case, there was absolutely no way I could win an argument: the "high energy kids with big egos" never believed me, I was the "old guy" as you mention. I remember an example where the "kid" failed and gave up with their "right" way after 3 months and I solved it in 3 days, exactly how I had suggested they did it in the first place. Next discussion, nothing had changed, they still knew better. I can't really blame them, because the whole environment was like this. Everybody was always right, knew better, etc, even though it was their first job. What I've learned is to protect myself and move away from that. Either by changing job, or by changing project. In startups I have been pretty successful at saying "I can help with this project if we do it this way, but if we do it that way, I can't help and I will work on something else". Of course it meant that I could not work on the most exciting project, but they made a mess out of them, so all in all I feel it was better working on my boring, stable, maintainable components.