The Future of Notebooks: Lessons from JupyterCon
I don&#x27;t get the people here saying don&#x27;t use Jupyter notebooks, or they are bad software engineering.<p>So much Python development is trying snippets of code in a REPL as you introspect live objects, then once they&#x27;re right pasting them into the IDE.<p>All my Jupyter notebooks are like that, where my code starts as cells of a line or two, as I check each output. Then I  coalesce them into a function (which avoid the problem of execution order that some people here mention). Then I may move those functions into a normal Python module and build up complex classes, add unit tests. Or if the goal is communicating with other people the results of running that code, I&#x27;ll add explanatory text and mathematical formulas, break it up into sections, include references to papers and web links.<p>I think what people miss here is many software development tasks, especially in data science and machine learning, are essentially exploratory data analysis. And the outputs are graphs, tables of data etc, designed to be read by humans. Jupyter&#x27;s ease of use for iteration, and the ability to interleave documentation, formulas, graphs and tables with the code is a big win.<p>In my daily work, I have my IDE and Jupyter open side by side. The Jupyter notebooks are version controlled like my .py modules.<p>Over time, I expect editors like VSCode to edit Jupyter notebooks natively. And also more code editing to move from IDEs into the Jupyter (via integrating the Monaco editor). We will all benefit from that crosspollination, whether we are principally software engineers or data scientists.