Part of the problem here is the way you're using the vocabulary to describe different things.
It is true that you need to write some piece of code to run the logic that actually executes on a computer that would, as a whole, constitute some sort of interactive game. This code is often referred to as the "engine", but it's really pretty broad and somewhat difficult to come with a concise definition of what an engine really is. However, when someone talks about "engine programming", they typically mean working on core infrastructure that lets the entire game be built on top of. Core engine systems typically don't require huge changes from game to game if an engine is reused. But, the engine isn't particularly useful to developers if it isn't tailored towards some design goals.
There's a reason why the vast majority of games developed with the Unreal Engine tend to be shooters; that engine was designed to handle those kinds of cases. If you're talking about engine programming in the sense of creating and working on core infrastructure, you could work on that forever. There's always something you can improve. But you won't ever finish a game. You'll just end up having some piece of code that can draw and update stuff but there probably won't be anything fun to do.
But if you're going to aim to finish a game, you'll still have to do some of the same things an engine programmer would do, since you need that code. But the subtle difference here is that you're going to only work on the infrastructure you need up to the point that it satisfies the needs of your game. Once you're there, you should stop working on that and work on getting the actually gameplay stuff interesting and fun.
In summary, the typical image of an engine programmer is someone who works solely on core software systems that let a game be possible to be built/run. They might work on graphics, physics, audio, asset loading/management, memory systems, debugging tools, gameplay scripting systems. But if you took all these systems together and ran that software, you still won't have a game. And each of those systems could be worked on and improved indefinitely. All games need some subset of these things, there's no question. The point is, if you don't have a full blown team behind you where you can dedicate an entire person to each of these systems, you need to prioritize your efforts.
This is why large companies like Valve, Epic, Crytek, and Unity are even able to sell their software (engine) at all. The engine isn't a game, it's just a piece of software that runs that can simulate an interactive system. The actual game part people write themselves within whatever framework the engine provides. Most small teams aren't able to invest the time and energy to build a piece of software that can be that modular. You might be writing some code right now that could be reusable in another project, but that's very different from the kind of modularity and reusability that can be offered by engines like Unreal.