I was tweeting something about having separate "DDD" and "ORM" entities in a project in a project, and that I don't understand this. There were some great comments and questions, thanks a lot for that! To be honest, I understand more about it now. In this article I'll try to provide some more information about this.

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.