[markfsharp]

I don't know about other people's experience, but from mine, I see a lot (most) devs abstracting too early in the name of clean code. I guess engineers gonna engineer when simple boring repetition is sufficient and those premature abstraction are unnecessary.

[zwnow]

Yea lets build a whole docker setup for this little Sudoku app that never will have more than 100 users. I mean, for fun overengineering small projects can be a great learning experience but for work? Keep it simple, stupid.

(In case it wasn't clear, im agreeing with your point and just giving some example)

[zimpenfish]

> lets build a whole docker setup for this little Sudoku app that never will have more than 100 users.

Looks good on the CV though and managers who hire-by-cv-not-sense love that kind of thing. You'd be amazed at how many interviews I've failed by pointing out that following the latest trends and over-engineering isn't always a good plan.

Also means there's a constant supply of work for contractors who can unpick that kind of gibberish back into reliable systems which is nice.

[portaouflop]

If I had a penny for every time I try to dissuade a dev from busing a huge k8s system for a business that does not have a single user yet - I would have a bunch of pennies

[nomonnai]

Yeah but what does simple mean? I struggle with that a lot. In my experience, keeping it simple means not being flexible when requirements change. Adding new features becomes tedious or even a mess. Keeping things simple is an art, certainly not an easy one.

[erik_seaberg]

Boring repetition is a bad fit for the human brain. Working memory is very small. Mistakes per line are frequent. It wants to see patterns that are not quite there. Even when it works out, it's millions of times slower than having the computer fill in grunt work from a more concise and readable spec of the problem.