Even if you disagree with the idea that the best way to write engines is to first complete several games, Krohm gave some other very good advice as well that you don't want to overlook. He said:
- Don't over-engineer.
- Use an iterative, explorative approach.
- Over all, don't write a game engine. (I agree with this fully! But better to exclude this one and accept the other four, than to throw all five out)
- Always keep in mind your goal.
- Keep your design documents at hand.
I'll also toss in my personal opinion that for a engine or API to be of practical use in actual projects, it has to strike a balance between being overly general and overly specific. If it's too general, and can be used for any game genre, that's not a feature, that's a flaw! If it can be used for any game genre, than you basically wrapped an API with another layer of abstraction, but without getting any closer to the games that are trying to get made.
The more focused an engine is, the more it's actually practical to use - otherwise the programmer will have to write the real engine for the game over the API that's masquerading as an engine. In my opinion, when making engines, it is better to err on the side of too specific (more features can be added later if needed) than to err on the side of too general.