after you've written some games, you already have an engine in hand: the code you copied over from game A to game B to game C. there's not more to it.
Actually, there is. The difference between writing things to be used by the specific game you're working on and "writing an engine" is that the later is about making those things generic and modular, whereas if you're in a "make games not engines" mindset you're not going to try to abstract the stuff you make from the specific game you're making, which will make it hard to reuse for a different game.
In my experience when you reuse code that wasn't designed to be reused it becomes increasingly painful because you are compelled to hack your way around the problems it causes, which will make it even harder to reuse it again for the next project etc.
However I do agree that doing that is probably a necessary experience to have before setting out to write "an engine" (aka a bunch of things you know you'll need in almost any game and designed to be reusable and generic), because it's the best way to know what you're going to need and also which pitfalls to avoid (because you have previously fallen in them).
Um, I think it's true when you are a sloppy programmer (I'm not calling you that!). If you are not a sloppy one, then the code you produce should be reusable (or easily modifiable to be reusable) by default even without the intention. If you properly use the "single responsibility" principle, your code is not flooded with globals, functions are small functions etc. Most reuse-candidate functions should be quite general ones anyway (setting up stuff, initializing common stuff, loading stuff, rendering common stuff and setting up common environments, input handling, messaging, debug/logging stuff, maths functions and helper functions, whatever).
Okay, I may be totally wrong, because I AM a sloppy programmer (but even I can reuse tons of my stuff with minor or no modifications).