This past Saturday I attended my first SQLSaturday event, hosted by the Portland, Oregon chapter. Which also happened to be their first virtual SQLSaturday.

Lots of wonderful presentations, across many topics, but one topic in particular really resonated with me.

Notebooks 101 for SQL People Speaker: Julie Koesmarno.
Are you a database developer, a DBA or a data analyst? Do you find spending quite a bit of time trying to reproduce analysis or reproduce issues and the troubleshooting techniques? This Notebooks 101 session is for you!

Jupyter Notebooks for DBAs Speaker: Rob Sewell.
Jupyter Notebooks were once the realm of Data Scientists. New releases of Azure Data Studio, Visual Studio Code, and .NET interactive tooling have brought this tooling into the Operational team’s area. The biggest benefit of using Jupyter Notebooks is that you have your documentation, your code and your results in the same source controllable document.

Currently I use Quiver to store my snippets and documentation on troubleshooting or adhoc queries. Prior to this, I was using apps like OneNote and Evernote. Quiver has the same concept of cell blocks that you can add to the document. You can set the programming language on the code cells and it will provide syntax highlighting. But what Quiver doesn’t have is actual code execution and a result snapshot.

These two presentations triggered a lightbulb above my head, with ideas for notebooks flying around it, like birds swarming around a dizzy character’s head in cartoons. This is not the first time I heard of Jupyter Notebooks, but having been the only SQL person in my company, since I started more than 7yrs ago, I only thought they were good for sharing scripts with the team. And as a team of 1, didn’t see much point in it.

Can’t wait to start converting my notes!

Cover Photo by Francesca Tirico on Unsplash