Notebooks Are McDonalds of Code
Code “notebooks” like Jupyter and Google Colab polarize programmers, data scientists, and researchers: some see them as indispensable tools for rapid experimentation, rich visualization, and teaching, while others view them as enablers of opaque, fragile, and hard-to-reproduce code. Many argue notebooks are ideal as interactive lab books or presentation artifacts but should be backed by proper modules, testing, and review—and rarely, if ever, used as production infrastructure. A recurring theme is that problems blamed on notebooks often stem from misuse, missing abstractions, or lack of software engineering training, rather than the format itself.
What people use notebooks for
- Widely used for data science, statistics, ML, and scientific/engineering work.
- Seen as digital lab notebooks: experiments, parameter sweeps, plots, and narrative in one place.
- Popular for teaching, documentation, reproducible reports, and sharing investigations.
- Sometimes used for debugging and incident response by attaching to live systems.
- A few mention serious production workflows and even mission‑critical systems built around notebooks.
Perceived advantages
- Fast feedback loop: tweak code or parameters and rerun a cell without restarting everything.
- Acts like a REPL plus documentation: code + markdown + rich media in one linear narrative.
- Inline tables/plots and layout near the code that produced them aid intuition and “feel” for data.
- In‑memory “caching” of expensive steps (large datasets, slow APIs, big models) avoids repeated load.
- Easy access to remote/cloud compute and data; many orgs expose only a Jupyter-like interface.
- Low barrier to entry for non‑software engineers and beginners.
Major criticisms
- Non‑linear, mutable state: hard to know what actually ran; easy to get irreproducible results.
- Encourages “spaghetti” and throwaway code that accidentally ends up in long‑lived use.
- Browser-based UX can feel sluggish and less interactive than native tools; plotting backends limited.
- Poor fit for long‑running, large‑scale pipelines; Makefiles/scripts seen as more robust.
- JSON format and saved outputs complicate version control and reviews.
- Some argue they’re misused for exploration; better to explore in an editor + REPL, and use notebooks only to present final analyses.
Production vs exploratory use
- Many insist notebooks should never be deployed to production; at most they prototype or document.
- Others report that real production systems and complex ML workflows are built on notebooks and can be maintained with discipline.
- Tension between software‑engineering ideals (tests, modularity, review) and scientists’ need for rapid, informal experimentation.
Alternatives and hybrids
- Scripts plus editor “cells” (
# %%style) sent to a REPL to mimic notebook ergonomics while keeping plain text. - Literate programming tools (org‑mode, RMarkdown/Quarto, similar systems) to combine narrative and code.
- Practice of moving stable logic into modules/packages and keeping notebooks as a thin exploratory or presentation layer.