OK, so you invent an animation format AWESOMEANIM, you get it hooked up and working, you can see a character being animated in a window... how do you know if this is any good for a game to use?
This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something.
In other words the only people who actually run off and code an engine without any clue what-so-ever as to how it will be used are people such as myself who intend to make a middleware company, yet even I have 2 ideas for upcoming games I want to make, meaning that even I am initially building my engine based on some idea of how it is going to be used.
Without experience you may not make the best animation system. Without experience you won’t make the best anything. But you know you’ll need one so you have to give it your best shot anyway, and there is no reason not to mentally organize it as being part of the engine.
The only time I write engine code without actually putting it into the engine library is when it is highly experimental for me and I basically consider that I am not sure how it is going to turn out so I don’t want to commit it to the engine yet. For example my first physics engine. The components and bits of math/intersection tests/collision detections/etc. were directly implemented into the engine because they are easy to prove correct, but the overall “engine” part of the physics engine was created between the game project and the engine project until proved to be working, efficient, and a satisfactory solid base (note I didn’t want to create a whole separate project for it so it was actually part of the game project but so isolated from the rest of the game code that all that would be necessary to move it to the engine would be to copy the folder and add the files to the engine).
Writing games and then trying to stockpile all the reusable bits—I don’t imagine that really works out most of the time. Your reusable bits go from project-to-project and get mangled and cluttered over time. It is easy for you to just keep copying the files to your new game project so you end up with a ton of copies of it and never really take the time to make a proper framework out of it. When you finally do you realize, “Oh, this file was supposed to be reusable but now I remember I was really excited to get results on X project and I threw in some illogical dependencies thinking they would just be for that project, then forget and it grew.”
“Hmm, this file relies heavily on my implementation of X feature, but for Y reasons that code needs to be rewritten so I can’t really move any of this ‘reusable’ file over to the engine.” (This case might actually improve your end results though assuming it forces you to rewrite that code.)
The only way to gain success is to be thinking fairly strictly about what is engine code and what is not, and if you are doing that anyway it is better to actually do it too.
Besides, if you aren’t able to identify what is or could be reusable, you wouldn’t be able to make “make games, not engines” work for you either.