Holy shit...Im Generic-aholic too, and I didnt even know it..

Im not even good at it, but the time I waste trying to think stuff ahead to make code reusable..

Like I was writing a PickupComponent for my engine, its for itens like jewels, lifes etc that the player can get on the level. So logically, it need to be used for anything that can disappear after contact with the player...But only disappears after an "picked" animation is played...or maybe instead of playing an animation, it disappear instantaneously and spawn particles. If its a score item, it needs to contact the HUD to add the points in a fashionable way, but what if its ife itens? hmmm...

Thats why jams are awesome...I wouldnt even blink before have an usable JewelComponent, than Id start creating a LifeCompo, probably realize if its worth or not to have a new compo, and move on

I am right now the lead on a project that is about seven months into a death march. The original developer (who is no longer at my company, BTW) was also a big genericaholic. And it is painful. Very painful. Every bit of the application has been over engineered to the point of being unmaintainable.

One example: There was a requirement to show the user what has been changed on a form. A simple old value, new value situation. Simple enough, right? All you need to do is implement in 1000 lines or less of code a complete change tracking system that can accept any type of object and using reflection, catalogue all the properties, fields and whether those props and fields are themselves containers of other properties. Simply walk the graph and catalogue all changes! Also it'd be cool to serialize this stuff, so let's write a few hundred lines of code so we can serialize the state of the tracked changes.

Awesome! But what about the presentation layer?! Almost forgot! Let's have it integrate with Automapper to automatically track the view models mapped from these tracked objects (again, using reflection and dynamically invoked generic methods to make it super magical). Nifty!

Now because this thing is so awesome, let's make it globally accessible and let every later of the app enjoy it! The data access layer, business logic layer, presentation layer, everyone! Oh! Let's not leave our Razor views out either! Cshtml files feel the love!

Don't do this. For the love of God, don't do it. Your dev team will hate you. Your maintenance developers will resent you. And you will eventually hate yourself when every problem is being escalated to you by the maintenance team because nobody else understands WTF you did (even you).

Thinking in terms of systems is a good thing for mature developers. Systems are big patterns that can cover a wide range of situations, that can be leveraged to do many things.

I agree with the once/twice/three times as discussed above. This is also a good reason to prototype, especially when implementing in systems.

When you know for certain you are going to be building a large system and you are not completely sure where everything fits, use a prototype that jumps directly from one to three, from the "write it directly and specifically" to "write a generic system":

For the initial prototype you build it directly and resist the very strong urge to build a system. Intentionally use lots of switches and if/else trees and intermixed logic of special cases. Copy paste, make it ugly if you need to, but make it work in a way that proves or disproves the system.

Then you review your initial prototype, look at all those bumps where special cases came out, seek out the 'ugly' parts, look at all those common places where many different choices were made. This tells you exactly where specialization needs to take place, where callbacks and virtual functions need to be, and suggests patterns and natural boundaries. Then use that as the basis for your bigger generic system.