Years ago my co-worker Maurits introduced me to the term "magic" in programming. He also provided the valuable dichotomy of convention and configuration (or in fact, he'd choose configuration over convention...). I think this distinction could be very helpful in psychological research, figuring out why some people prefer framework X over framework Y. One requires the developer to spell out everything they want in elaborate configuration files, the other relies on convention: placing certain files with certain names and certain methods in certain places will make everything work "magically".

And there we are: magic. Often used in code reviews and discussions: "there's too much magic here". Yesterday the word popped up in a Twitter thread as well:

"symfony has too much magic, to its own detriment..." @bazinder

This was answered with:

"I'd say that everything is magic until you start to understand it :D" @iosifch

It made me wonder, what should we consider to be "magic" in programming? Is magic in code okay, or should it be avoided at all cost?

Last year I had a video call with Tomas Votruba, creator of Rector, who kindly took the time to explain a lot of things about this project. We finished the call and I couldn't wait to tell my partner how nice it was. I said to her: we should have recorded it, I'm sure it would be useful for other people too. She replied: this is so typical; millennials having a nice conversation and then they want to let the world know about it.

The one simple trick to do a better job as a programmer is to git commit as if your commit could be accidentally deployed (and it wouldn't break the production environment...)