sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering to its logical, generalized conclusion... or at least die trying.
"see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)
right, but my point is thats what we call a bad software developer. and most software developers are warned, because real abstraction is beyond their capability. a world class software engineer knows that maxim, but also is capable of building an abstraction that lasts.
"see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)