Hacker News Reader

Comment by SomeCallMeTim | Hacker News Reader

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

After taking an extra long time to understand what the code actually did, 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.

After deleting all of that code and refactoring it to use completely different abstractions, everything was suddenly much easier to read and to extend.

Design is a hard skill to learn, and junior developers profoundly haven't learned that skill yet. But that's what we need to teach them as senior engineers, right?

Not that I could teach the author of the code I changed, since I think it was written by an intern that no longer worked for the company. But you do what you can.

View on HN

> 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 you - and the Visitor-pattern as a great way to get RSI.

Nah, it was something unrelated to databases.

I can't even remember the details. It's like trying to remember nonsense sentences; they don't stick because they don't really make sense.

To the best I can remember, it was something like the use of an adapter pattern in a class that was never going to have more than one implementation? And it was buried a couple layers deep for no particularly good reason. Or something.

And yes, modern languages like the ones you list make many of the original GoF Design Patterns either absolutely trivial (reducing them to idioms rather than patterns) or completely obsolete.

FP has design patterns too, just different ones, and they don't all have tidy names.

Also some GoF design patterns map pretty closely to FP equivalents... pattern-matching on ADTs + traverse/fold + ReaderT ends up looking a lot like the visitor pattern.

> pattern-matching on ADTs + traverse/fold + ReaderT ends up looking a lot like the visitor pattern.

...that sounds like hand-written tedium; isn't `replicate` meant to avoid that?

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.

It's easier to know where you're going when you've gone to similar places a hundred times.

I just think about a problem for two seconds and then have the entire path mapped out.

I mean... some do, some don't. With experience comes appreciation for simplicity and flexibility.

yep. good judgment comes from experience. experience comes from bad judgment.

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.

>nudge the junior toward seeing the errors in their ways.

At least plant a seed of doubt early on.

Reply on news.ycombinator.com