I find this applies to media production too. When you use something like LaTeX to write a report, it seems kinda obvious that the .tex file is source code and t

I find this applies to media production too. When you use something like LaTeX to write a report, it seems kinda obvious that the .tex file is source code and the generated .pdf is the binary built from that source. You use markdown to write blog posts and then use jekyll, hugo or similar to "compile" it into a static site. But it applies broader too, to images and video for example. If I import an image file into my app, but I don't have access to or control over the source image file that it was scaled and exported from, then I'm essentially building a dependency on a compiled binary that I don't have the source code for. If Apple decides that all iOS apps should now have a @4x high rez version of all images, then I'm not able to create one. There's a lot of lessons from software engineering that can be expanded to other fields with that insight. Best practices for version control of source code applies to anything that can be called a kind of "source". And you need not just to maintain the source, but also the tools with which the source is edited, and the pipeline with which that source is transformed into a shippable product. There's value even in the basic idea that any given "thing" can have multiple distinct representations, with one optimized for editing, versioning and collaboration, while another representation might be optimized for distribution and/or consumption (and you might have intermediate representations optimized for other steps in the pipeline toward distribution). It might be overkill for many use cases, but it's helpful simply to know that it's a sane model to evolve toward as a project grows.