The future is wireless. From cellular phones, to Bluetooth earpieces, all the way to AirPods: the allure of these products is created by the magic of freedom from wires.
The experience is magical–when it works. But sometimes it doesn’t work, because creating such magic requires additional complexity. And since the complexity is intended to be invisible, the inevitable failures end up invisible too.
In contrast, consider a wire. A wire trades being magical for being understandable when something doesn’t work. Is the output device connected to the audio source? Understandable. Is it a bad wire? Understandable.
But my point has nothing to do with consumer electronics. (I own and enjoy both wired and wireless headphones, for the record.)
When writing source code, are you pursuing magical or understandable?
Using esoteric constructs or features of a language, applying a design pattern that doesn’t quite fit, oversimplifying an API because incorporating the required error handling would compromise its elegance—practices that lead to invisible failure are created in the hunt for something magical.
Magical code is usually not great code. Great code is code that you can understand and debug years from now. Actually, great code is code that someone else can understand and debug years from now.
The basics are difficult enough. More often than not you will be better served by just using a wire. When things inevitably don’t work you want understanding, not magic.