I've made diagrams for my talks in both style (with code and with Inkscape or, these days, Lucidchart). Writing code to generate diagrams had a much larger setu

I've made diagrams for my talks in both style (with code and with Inkscape or, these days, Lucidchart). Writing code to generate diagrams had a much larger setup cost but once I had it going, iterating on the diagrams became much easier. I had a talk about radix trees[1] where I wrote some Haskell code that could take trees and generate diagrams from them. Getting the code right in the first place took a few hours but in this case it was clearly worth it in hindsight for two reasons: 1. I ended up with a lot of tree diagrams. Once the code was working, the marginal cost of adding an extra diagram went way down and I think that improved the talk as a whole. 2. Code made it much easier to iterate on my examples. I had an extended example[2] that I changed several times; if I had had to manually redo the diagrams for it each time, I would not have bothered. These days, this trade-off (up-front vs ongoing costs) makes the decision reasonably easy. If I'm going to be making a single diagram and I don't expect to change it much, I'll do it manually; if I'm going to be making a series of similar or related diagrams or if I expect to iterate on the diagrams a lot, I'll write some code for them. So far, I haven't regretted following this approach in either case :). [1]: https://jelv.is/talks/lambda-world-2018/slides.html#/sec-title-slide https://jelv.is/talks/lambda-world-2018/slides.html#/sec-tit... [2]: https://jelv.is/talks/lambda-world-2018/slides.html#/slide-org36e08b7 https://jelv.is/talks/lambda-world-2018/slides.html#/slide-o...