Notebooks as a Learning Space

Ok, Jupyter notebooks are INCREDIBLY handy. Where have they been my whole life?

The answer is likely: behind the wall of academia. At your local community college’s Data Science Master’s program. And while I technically have used them before, tinkering around at my old university library back in… 2012? I had never seen them used like this, organized in a progressive way around PROJECTS. Which has been really pedagogically helpful. I cannot overstate that.

They are however, exactly for academics. Definitely not production code environments with plenty of flaws running code on their own: state leaks between cells, output rots, variables persisting across runs you no longer remember running, etc. But as the kind of software engineer that’s both: a) a learn-best-by-doing type and b) kind of a state management control-freak, I have found them a great fit.

So today on this beautiful 1st of May, I’m gonna yap about how much I love Jupyter Notebooks.

What a notebook is good at

A notebook is the read–evaluate–print loop made vertical. You write a small thing, run it, see the result, scroll, write the next thing. It’s organized by tidy little code execution blocks fenced in cells. The history scrolls. The state stays. You can backtrack three cells and rewrite. You can keep two competing approaches side by side. You can print an intermediate value, look at it, decide it’s wrong, and try a different one — without ever committing to the structure the “wrongness” was hiding inside.

The lesson is in the mistake

This is the part I keep coming back to. I know myself well enough to know how I learn: I have to let myself make mistakes. The cells you delete are a record of the path you took to the answer. Not all of it survives — but the idea of the path survives, because you took the path with your hands. You ran the wrong query and saw the wrong-shaped output. You wrote the loop the long way and saw it work, and then you wrote it the short way and saw it work the same. And being wrong was a part of the learning process that took you to get there. It’s great! You learned the difference by writing both.

So when do we leave the training grounds?

Well, when the question stops being “what is this” and starts being “this works, where does it live.” When you’ve got proof in the eval. That’s the moment to lift the cells into a python module — to commit to the function signatures, the imports, the structure. Make the production code contract. The notebook was the negotiation that produced it, but when we want software good enough to ship, we have to land on a single path of execution.