For sure. However most code doesn't require "aha moments"; it requires readable code with tests that cover edge cases, following the same pattern as similar code that does similar things.
The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should.
There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.
> It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.
Unless you’re working on something trivially easy, isn’t this almost always the case? The puzzle does not actually show up as “high cpu utilization”, but seeing process stalling, string handling edge cases, weird packaging based problems or that one issue for that one customer happen on a weekly basis for my teams over the past decade of me programming professionally.
Also, the best puzzle solvers or hackers almost always come up with the simplest solutions that solves problem and are literally the only people I’ve seen being able to take on the toughest bugs.
I could put it another way. Some people who are comfortable with complexity don't actually come up with the simplest solutions, and instead come up with more complex solutions because they themselves find them relatively simple.
It's a pattern I've seen in talented engineers with less experience.
And on your question, I don't think it's the case. If it were, then there would be little excuse to use Ruby over Java, or Java over C++ / Rust / etc. In the same way as we pay a performance penalty in return for productivity when we use an expressive, high-level language, we pay a performance penalty for maintainable code with clear abstraction boundaries. Efficiencies, when they must be found, often come through vertical integration that burrows through abstraction layers.
Ideally we build our architectures so that we can scale out rather than up, for both hardware (easy) but also the team (the much tighter constraint - aiming for fungibility and elasticity of labour). If we get to the size of a Google or FB, then we can worry about squeezing out more profit, but first comes growth, and that means product, which means features.
The worry around puzzle orientation is when someone e.g. takes advantage of an obscure feature or does something unusual for a performance gain at the cost of readibility or maintenance. I've seen several repeated instances of clever people writing complex code because they could, and spending too little time thinking about whether they should.
There's a place for that kind of thinking. It's usually when non-functional requirements are limiting factors; minimizing memory, CPU time, network round trips, etc.