When your programs are configuration driven and used by PM/PO/Scientists etc you have to think slightly differently about how configuration files are used in your projects. For example, users may want to change/create configs on the fly and they may want to see all settings in one file without having to go through layers of indirection and library “configs” to see what their experiment/program will do.

Rather than discussing config file formats (I’ll assume toml but it’s applicable for other formats), this talk will focus more on my ideas/tips on: how to structure config files, how to allow non technical people to contribute to config files, how to minimise potentially explosive number of config files, how to expose more control in config files, tools for testing these configs and checking if values are actually used, hints for good practices to make debugging problems easier.