re "locking notebooks", in case your students never saw it, you can share/import specific versions of a notebook. For example, this notebook's most recent version is 34, so you can share a link to https://observablehq.com/@info474/teaching-reflections@34 , or import with `import {x} from '@info474/teaching-reflections@34'`. If you own the notebook, you can get all the versions with the history feature, but if you don't own the notebook, there isn't a really good way to find what version numbers are available (awesome writeup, btw!)

> Moving forwards, I'll need to think about how to challenge students to write "custom code". I'd love to hear about any strategies you've developed or employed.

I still struggled with this throughout the following quarter -- balancing importing notebooks v.s. forking v.s. copying code from examples (which is how many of us learn...) is something I didn't get much clarity on. I did add this assessment to try and push JavaScript data wrangling confidence, but didn't make too much other progress. https://observablehq.com/@uw-info474/data-wrangling-assessment

> More time spent going over what each part of d3 syntax was doing Since you do a lot of teaching with d3, it might also be a good idea to include it unminified: d3 = import("d3@6") That way cryptic names like "Wn" will stay readable ("Selection"), and you can actively step through and debug code in the developer tools.

Good point! I won't be updating these moving forwards next quarter, as someone else is teaching the course, but I'll pass it along! On reasons to stick with `require` is just so that it matches the examples that they see in other notebook (though I agree that the unminified version would help when debugging)