It is easy to believe something is over-engineered as a junior. You open a solution and get slapped in the face with a wet fish of many classes, with strange names, doing very little, with everything coming together in ways you don't understand.

My advice is to learn about design patterns, clean code, clean architecture, and model driven design. Until that point I don't think you can make such a distinction. And indeed once knowledgeable of patterns and techniques as well as the domain, the same solution can look obvious, elegant and readable.

In a field where everyone is saying 'dont over-engineer', one must be able to tell if something is actually bad, or just uses techniques you don't recognise.

Telling your senior you think something is over done just because you don't understand it is not good. First learn techniques, understand the code, then form opinions that are at least relevant then.

From someone who committed that crime.

Don't neglect DDD, also. MDA designs don't tend to work well without an understanding of DDD.

Well, if the seniors are any good, they would appreciate the criticism and help educate the new one.

Blind faith that seniors are more skilled is not the best foundation for growing as a developer :)

Sometimes the same code can be both over engineered and follow best practice.

Sometimes the pattern only makes sense if you have lots of developers and is over engineered for a small team.

I have seen this first hand the last year.

Code written by consultants (in this case very competent such, not the HPC type) was written according to all the best principles to solve the problem you face with hundreds of developers in the same code base, something they most likely have experienced.

But we have just over a dozen, for us the solution results in 3 times the amount of code, and the need to use external documentation to know which parts belong where.

A more pragmatic pattern would save lots of time since there are rarely more than one developer tinkering in each part at a time.

We do not really need to consider multiple parallel branched for the same module at s time and do not need as rigorous separation, it only bogs us down, especially since any one diving in the first time need to have someone sitting on the side explaining, which we really cannot afford.

@Voxera It's actually dangerous to only ever have one person tinker on a specific part. In this case parts of the code basis become sort of a single let kingdom were only the one that wrote it knows their way around.
Now this might save time but if some people start to quit or go on sick leave and some work on those parts has to be done, you will lose a considerable amount of time trying to find your way around someoneelses kingdom.
I like to consider the bus index: How many people could be run over by a bus without the project completely failing? The higher this index the better.

@TheSilent I said at the same time.

We are using CR’s and also alternate doing jobs on different modules but most often not in parallel.

Designing the whole logic around avoiding merge conflicts is in that case redundant.

And since the solution to avoid merge conflicts cause not only more code but significantly more complex code we increased the risk of bugs with no real gain to our organization.