Fun story, while at FAANG I was once tasked with making a parameter configurable via flag. This wasn't super easy for various reasons, but I pointed out that it was configurable already: all you had to do was submit a PR to change the hardcoded value in the code and it would update everywhere and that wasn't much different from how we already configured runtime parameters by submitting a PR that updated the config file.
I got a good chuckle out of my coworkers but as I've gotten more experienced there's a grain of truth in that. Actually the main non-joking objection was that deployments are slow so if we needed to, reconfiguring runtime flags was a good amount faster. But that made me think: if deployments and builds are super fast, would we still need configuration in the conventional yaml and friends sense? It could save a lot of foot guns from misconfiguration and practically speaking, we essentially never restarted the server to reconfigure it. From the article,
> Unless you have really good reason to, you probably should not do this for normal options - it makes your library much more rigid by requiring that the user of your library know the options at comptime.
I got a good chuckle out of my coworkers but as I've gotten more experienced there's a grain of truth in that. Actually the main non-joking objection was that deployments are slow so if we needed to, reconfiguring runtime flags was a good amount faster. But that made me think: if deployments and builds are super fast, would we still need configuration in the conventional yaml and friends sense? It could save a lot of foot guns from misconfiguration and practically speaking, we essentially never restarted the server to reconfigure it. From the article,
> Unless you have really good reason to, you probably should not do this for normal options - it makes your library much more rigid by requiring that the user of your library know the options at comptime.
I dunno, actually that sounds really great to me.