As is commonly known, naming things are one of the two hardest problems in software engineering. Gallons of virtual ink have been spilled on the topic, and a common issue that comes up is what to name your “manager” class. If you find an orchestrator, administer, or some other blob of coordinating architecture exists, the temptation exists to name it SomethingManager, leading to a codebase that’s exhausting to read.

One common piece of advice is to use the existence of “managers” as a code smell and code away from them. And it’s good advice! I highly recommend trying it first. But I don’t think it works all the time. To give an example: in the game Legend of Zelda, there is an entire state machine to determine what item should be dropped when an enemy is killed. It draws information from multiple locations in the game world’s logic, and arguably makes little sense to break it up. And, yes, it manages item drops from enemies.

But still, “Manager” is a boring name. I have a modest proposal for a better one.

In Terry Pratchett’s Discworld,