Posted on Dec 22, 2022
Over the past year, I had the opportunity to teach as an adjunct lecturer at Northeastern University. It was my first time teaching in a formal setting and I learned a lot from the experience—about visualization, pedagogy, learning, and ultimately about myself. Looking back on the experience, I wanted to document some of the themes that I ran into again and again during class. Maybe it will be useful to others teaching programming and data visualization classes.
For context, I taught two classes this year: [Visualization Technologies 1](https://searchneu.com/NEU/202310/search/Visualization%20Technologies%201%3A%20Fundamentals) and [Visualization Technologies 2](https://searchneu.com/NEU/202310/search/Visualization%20Technologies%202). Both of them focused on using code as the primary mechanism for translating, interpreting, and ultimately visualizing information and data. Both classes were available to any Masters-level students at Northeastern, no prerequisites required. On a practical level, these were data visualization classes but I use "visualization" interchangeably.
## Visualization is inherently multi-disciplinary
This is something I have experienced personally as a primarily self-taught visualization (vis) person. But it became even more apparent when I started teaching vis.
If you teach a student how to write D3 code that creates a scatter plot, they will do it. But it will likely be a bad scatter plot.
To create high-quality visualizations, you should learn much more than just code. You also need to know about storytelling, design, color contrast, accessibility, statistics. Good data visualization *expects* knowledge of these other disciplines. It also requires knowledge of other tools: tools for shaping/re-shaping data, tools for sketching, tools for debugging code.
As a teacher, this was a difficult task. I had a whole syllabus of lessons to get through, and most of them focused on how to use Javscript to create visualizations (more on choosing JS for is later). Many of my students in Vis Tech 1 had never written code before.
*But should I at least teach the basics of information design? That would require a few extra lessons...I would also need to introduce some color theory. Something on Gestalt groupings would also be good.*
And so on and so forth. There is never enough time!
For Vis Tech 1, I had a few students who were majoring in the information design program. Those students had a significant advantage over the others, and their work proved it. They already had a good grasp of visual encodings and grammars. They were only missing some of the technical skills required to build their designs.
In the end, I decided to focus on teaching a skill (code) rather than teaching an entire discipline (information design and visualization). I chose to stay highly focused on the skills required to *program* visualizations and hoped that the truly interested students would put in time outside of class to learn more about theory and design. It is unrealistic to expect a crash-course in an entire discpline in 14 weeks.
## Teaching code is mostly teaching how to read documentation
This takeaway is very much in the vein of "give a person a fish, eat for a day; teach a person to fish, they eat for life."
Unfortunately, software writing is rarely friendly to newcomers. My first two weeks of class were spent convinvcing people: "Yes, you can do this! Code doesn't have to be scary!"
I discovered which students would excel in the class by how quickly they started looking at the documentation to find answers. During in-class excercises, my first response to a student who was struggling to add a feature or find a bug in their code was: "did you check the docs?"
Teaching students to find the answer in a well-structured set of documentation equips them to *solve problems on their own*, a crucial skill in programming (and arguably, in life).
In the past, lecturers for this course have used Processing (Java flavor) to teach programming visualizations. The benefit of this is you get a dedicated code editor and you only need to learn one language. The downside is the interactivity can be limited for beginners, and it doesn't run in the browser.
But it's also just a weird language. It's not inuitive or human readable, in the way that Python is. And it requires knowing *other* technologies too (again, multi-disciplinary!).
I would like to thank my students publicly for their patience with some of my less-than-satisfactory explanations for why certain coding languages are the way they are. I didn't write them and I know, it can feel unnecessarily confusing. But I promise, it gets better with practice and time!
And for students who maybe were not so interested continuing to code after this class, at least they were exposed to a semester's worth of practicing a new technical skill, which is good for the brain. And they also know how code works on a conceptual (semi-practical) level.
## On using Glitch
Finally, I wanted to document my experience using [Glitch](https://glitch.com/) as the primary tool in class for writing and teaching code. I chose to teach using Glitch because it is beginner-friendly, playful, and operates entirely in the browser. No need to download an IDE or text editor and fiddle with the settings. I wanted class to be about learning the material, not about setting up a laptop for frontend software development.
I think overall I'm pretty happy with my experience using Glitch. At the end of the class, I took an informal poll from students to get their feedback as well. Here's what we decided:
### The good
- the ability to get started coding right away
- easy to "Preview in new window" and have your code auto-refresh to show immediate results
- files were well-organized and easy to find (no directory diving)
- I could create a "Team" for the students to join and share resources and code examples
- the ability to "Remix" became an essential teaching tool: I could write the boilerplate code to create a template, and then students could Remix my code to complete an in-class challenge. This was probably my favorite feature and hugely valuable when it came to teaching.
### The not so good
- ironically, Glitch tended to have a decent number of literal "glitches": some students (and myself one time) couldn't access the Teams page randomly. The browser just showed a blank screen. A similar thing happened with some students having trouble signing into their account. It usually resolved itself one way or another, but was certainly tedious.
- students found the auto-naming feature a bit annoying. When you create a new project, a random three word name is assigned. If you don't rename your project right away to something more informative for searching purposes, it can be hard to remember where to find your code.
## Closing thoughts
For now, these are the lessons that really stood out to me. I wanted to write these down while they are still fresh (I just submitted final grades last week!) but I'm sure I'll have more to say about the topic in the future.
Teaching was a rewarding experience for me and I hope to have the opportunity in the future. Some students struggled more than others, but everyone made a real effort to learn a new and unfamiliar skill. And in a few cases, some students truly impressed me with their curiosity, creativity, and desire to build something totally new to them. It was inspiring. And I hope they also left class feeling excited about what they built.
Next semester I will not be teaching a class. Instead I'm taking some time to reflect and think about what's coming next in my work life. But whatever comes, I'm thankful for this experience and what it taught me.
*If you want to chat about teaching vis, you can find me on [the Mastodon vis.social instance](https://vis.social/@bendexter) or [LinkedIn](https://www.linkedin.com/in/benjamincooley/). I also write a newsletter about these types of things called [Data Curious](https://datacurious.substack.com/).*