Dr. Dhavide Aruliah is the Director of Education at Quansight LLC. He holds BSc & MSc degrees in Mathematics from Simon Fraser University & a PhD. in Computer Science from the University of British Columbia. After completing postdoctoral work at the Fields Institute for Research in Mathematical Sciences and Western University, he served as a professor in the Faculty of Science at Ontario Tech University. In 2015, he left his academic career to work as Director of Training at Anaconda, Inc. and later as an independent consultant. His principal area of research is scientific computing, specifically in computational inverse problems. He is more broadly interested in numerical linear algebra, partial differential equations, optimization, scientific software development, and in high-performance computing.
Teaching & learning with Jupyter notebooks ought to be straightforward, right? Unfortunately, no, not exactly; my experience—both in developing content & in live instruction—suggests otherwise. I'm drawing on a decade of teaching efforts for undergraduate/postgraduate university courses, for Software Carpentry bootcamps, and for corporate or government training engagements.
I've personally wrestled with numerous nuts-and-bolts technological obstacles to promoting computational thinking in learners with Jupyter:
- deploying robust, "99% invisible" computational environments so learners can start quickly (i.e., without painful software installation or configuration);
- accessing data smoothly (especially when balancing privacy/security concerns with teaching goals); and
- managing notebook versions for collaborating instructors.
I'll describe a few technological (and non-technlogical) ways to address the above. These include Nebari (an open-source JupyterHub distribution platform), RISE (a Reveal.js Jupyter slideshow extension), Anaconda Project (for supporting reproducible, shareable data science projects), and EtherPad (for live interactive group collaboration in a text-editor interface). By design, Jupyter notebooks enable immediate learner feedback. That is, learners can modify code interactively to improve their internal mental models of what's going on and do so autonomously—this is ultimately what I want when teaching.
While tooling is critical for designing & maintaining content, I'll steadfastly reinforce my central priority: getting tools out of the way. Ideally, learners should focus on building the knowledge and skills they need to solve their own problems. By design, Jupyter notebooks enable immediate learner feedback. That is, learners can modify code interactively to improve their internal mental models of what's going on and do so autonomously—this is ultimately what I want when teaching.
Finally, I'll discuss pedagogical considerations unrelated to Jupyter itself that play a large role in designing for the goals and culture appropriate to the audience (e.g., academic vs. corporate vs. government). These logistical choices invariably get entangled with planning & execution: synchronous (live, instructor-led) delivery vs. asynchronous (recorded), remote instruction vs. in-person, spaced vs. contiguous delivery, full-length college/university courses (i.e., measured in semesters or quarters) vs. condensed workshops/bootcamps (i.e., measured in hours or days), and so on.
I’m aiming this presentation at folks from both industry & academia who are primarily interested in teaching & learning. Ideally, they are intrigued by the pedagogical opportunities that Jupyter affords. This intended audience ought to have some experience teaching a class or workshop in front of free-range learners. Prior exposure to Jupyter (ideally in instructional contexts but, if not, in their own projects) is useful but not mandatory. This audience includes practitioners from disciplines outside computer science and engineering (e.g., Finance, BioTechnology, Geology, etc.). I also hope that experienced developers—ones who frequently struggle to convey programming concepts to novices—might appreciate some of the insights I'll share.