Like others have noted, it is actually harder to read and grok the code when your function is able to do literally anything. Before, you got what you saw. After

Like others have noted, it is actually harder to read and grok the code when your function is able to do literally anything. Before, you got what you saw. After, the callback might as well set off WW3 for all you know. This fits poorly with the philosophy of doing one thing well, and ironically makes it much harder to create an admin user - you have to know what the correct callback is, as opposed to noticing an enum type or a bool type. I would probably create two functions, createAdmin and createCustomer, then as the post briefly does, factor out commonalities where it makes sense. Note that factoring out ALL commonalities is often a red herring, some duplication may be preferable to strangely factored code (eg the callbacks…)