A basic gamedev engineering truth I've found (of course disputable, as all experiences are) :

Engine is nothing without content.

The engine is the writing pen, but the content is the written word. The combination is what players fall in love with, myself included. To an engine guy like myself this means a few things. Firstly, that no matter how much energy I pour into engine and performance, without content it's all purely academic. Secondly, that presenting content is the primary function of an engine. Thirdly, the engine directly informs the content a game can display, or, flipped on its head, the demands of the content directly informs the requirements of the engine.

I'll simplify a bit, so bear with me. Making an engine is not "hard". Displaying graphics is not "hard", playing sound is not "hard", collecting input is not "hard". The trick is in the pipeline. The point where an author can have an idea, and the journey that idea must undertake before it is on display. 

I think this is probably the single most exciting thing about something like Unity, in that it allows almost anyone to fit together a functioning prototype with a minimum of forethought (though bizarrely much easier in 3D than in 2D). The engineer in me sneers at the product from an authorial point of view, which is odd. Behind the scenes, a component based architecture is a modern and pragmatic approach, so there is no sensible reason to consider Unity games "less good". Heck, my own engine uses a degree of component based architecture. The problem for me, I think, is that Unity presents me, the developer, with a frontend that invites a cobbled-together clip-art approach that runs directly counter to how I imagine Unity itself was written. It's "drunk and disorderly" engineering, so as an engineer, it's hard for me to engineer in it. It feels dirty.

But for content creators, it must be hugely liberating. Such freedom!

Over the years, I've come to think of myself a decade ago as an idiot of sorts, in the greek sense. Utterly visually oriented at heart, I could barely work the idea of an array into my head, much less 3d mathematics, physics or parallelism. 

But what a blissful state of idiocy it was! I put out more game prototypes in my idiocy than I do now, forever bumping into the politics of engineering en route to the idea. Even the super early days of figuring out Basic, writing short text adventures on intuition alone rather than tracking some bread crumb trail of established principle. In music, too, I became too enamored with the principles, losing my quick iteration times to laborious, overthought projects.

Lovecraft quote time (because I'm that guy, apparently):

"There are not many persons who know what wonders are opened to them in the stories and visions of their youth; for when as children we listen and dream, we think but half-formed thoughts, and when as men we try to remember, we are dulled and prosaic with the poison of life"

It's both fun and terrifying to see the young overtake the old. My ambitions of programming were always formed by my childhood heroes. Of figuring out the hard stuff. In game design terms, those challenges are sorely lacking in relevance today, beyond, again, the purely academic. They lack the playfulness and freedom of the current.

I think, today, to leverage the benefit of my experience, I need new "childhood heroes". I grow to think the strength and stability of the old must be augmented and focused through a younger prism, or it simply stagnates and boils away in endless thought. 

So I've found myself feeling like my role for the future should perhaps be as an enabler, rather than a controlling entity. The idea of the experienced, guiding hand is applicable to the sciences, but in art the best a teacher can hope for, I think, is to enrich and enable, not steer and shape. There is unbelievable joy in seeing others apply the tools you create in ways you couldn't conceive. To see an engine built for bullet hell, used for a children's storybook. With tools, I'm again poking at the world and seeing it ripple.