I did not know what creative coding was and would have appreciated some context-setting in the blog post. If anyone else is unclear on what creative coding is:

I did not know what creative coding was and would have appreciated some context-setting in the blog post. If anyone else is unclear on what creative coding is: https://en.wikipedia.org/wiki/Creative_coding https://en.wikipedia.org/wiki/Creative_coding Whenever I have done anything similar to creative coding (e.g. art generation with neural networks) there are three kinds of information that I need to store - code, parameters, and results. Results could be anything from utility function values to S3 prefixes under which generated images were stored. They aren't always suitable to commit to git - do you really want to commit large, generated images/videos to your git repo? Git commits are a great way to refer to different points of the code base, but I like to have parameters and (corresponding results) stored somewhat orthogonally to git commits. Because the same commit of the code base might apply to multiple different runs. The solution I've converged on is to commit a CSV file alongside the code with the following structure for its rows: <git_commit>,<parameter_1>,...,<parameter_m>,<result_1>,...,<result_n> The only tricky part is running "CSV migrations" when you add new parameters. But if your rerun script only uses parameter names (specified in first row of CSV), this isn't a real problem.