I saw some code in a job I was just starting where they had added several abstractions that I …

There is also the fact it’s much easier to write something when you know where you are going. When you start you often just make lots of items general in nature to improve later on.

As someone in leadership, my ‘strong opinion held loosely’ on this, is that there’s absolutely no way to meaningfully build this skill in people, in a theoretical setting. You can, at best, make them aware that there is such thing as “too much”, and “the right tool for the job”, and keep reminding them. But nothing, nothing, comes remotely close to the real-world experience of needing to work with over-engineered spaghetti, and getting frustrated by it. Especially if it’s code that you wrote 6 months prior. Juniors will always do this. It’ll always be the senior’s job to…let it happen, so the junior learns, but to still reduce the blast radius to a manageable amount, and, at the right moment, nudge the junior toward seeing the errors in their ways.

> I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine. £3.50p says it was the Generic Repository pattern implemented over Entity Framework dbContext, right? -------- Speaking of design-patterns, I subscribe to the opinon that _Design-patterns are idioms to work-around missing features in your programmign language_, which explains why Java has no end of them, and why us jaded folk find happiness in modern languages that adopt more multi-paradigm and FP (the post-Java cool-kids' club: Kotlin, Rust, Swift, TypeScript, (can C# join?)) - so my hope is that eventually we'll have a cohort of fresh-faced CS grads entering industry who only know-of Facades/Decorator/Adapter as something a language designer does to spite their users because any reasonable compiler should handle interface-mapping for …