This. As a senior dev and a team lead I much prefer a developer that will make some unoptimal code than someone who will try to be clever and write something that's really hard to understand, let alone maintain.
The problem with abstraction is that the better it is, the higher is the risk of failure.
Why? Because when abstraction is valuable, we want to use it everywhere, so we extend the range of situations where it might fail.
That's true, but I'd argue that there's a solution : Test your abstractions. If you have some reliable unit tests making sure that your abstractions keep doing the same thing (and you don't change the tests to suit your needs of the day...) things shouldn't break.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This. As a senior dev and a team lead I much prefer a developer that will make some unoptimal code than someone who will try to be clever and write something that's really hard to understand, let alone maintain.
That's true, but I'd argue that there's a solution : Test your abstractions. If you have some reliable unit tests making sure that your abstractions keep doing the same thing (and you don't change the tests to suit your needs of the day...) things shouldn't break.