As CQuIC’s first-ever computing workshop has wrapped up, I wanted to share some of the lessons I learned in the course of organizing it. Maybe they will be useful to you when you develop/run your own!

1: Expect learners to use multiple operating systems.

Scientific computing takes place across all three major operating systems - Windows, Mac, and Linux/UNIX. As such, you have to expect that several operating systems will be used at the workshop. This means it’s worth knowing a few things about the nuances of each - for example, their default text editors, or what a good UNIX-like command-line tool is for Windows. We ended up splitting responsiblity for the different operating systems amongst ourselves.

Practical Tip: Make sure you have people on the organization team who are competent in at least one of the major operating systems.

2: Expect software installation issues.

We found issues related to software installation broke down into two broad categories:

  • Learners were unfamiliar with how to download and install the software (e.g., using a package manager).

  • Getting niche software to work on different operating systems was difficult.

We had anticipated the first issue, and held a pre-workshop “installation/technical troubleshooting” session a few days before the first teaching sesson. Several learners showed up, and they were able to get the software installed. Dealing with the second issue was a bit harder. While we had tried to use “ubiquitous”/easily-available tools (e.g., Python via the Anaconda installer, git, Make, LaTeX), there were a few lessons where somewhat niche software was required (in particular, sympy for symbolic algebra, and mpi4py for parallelized computation). For those, we had to take some time to see how installation was done on different operating systems. (Figuring out how to get mpi4py working on Windows was a bit of a challenge; I’m grateful for Xiaodong Qi’s help!)

To make sure learners had all the software – and that the software was the version we wanted – we modified some test scripts provided by Software Carpentry. As long as the learner’s machine passed the test, we knew the right software had been installed.

Practical Tip: For an introductory workshop, teach easily-available and commonly-used tools. Regardless of the tools being taught, use some kind of test script to verify software installation has been completed.

3: Expect logistical issues.

Logistical issues come in many forms, and you should expect several to show up in the course of organizing your workshop. Some issues we encountered included:

  • Organizing the organizers: To keep each other accountable, and to make record-keeping easy, we used a shared Google Doc to record minutes from our planning meetings. We also had a dedicated section for action items. Once an action item was completed, it was marked as “Done”, but was not deleted from the list.

  • Determining session times: In a pre-workshop survey, learners indicated they preferred having several sessions split over multiple weeks, as opposed to a series of back-to-back sessions in a single week. As scheduling is a notoriously difficult problem, we sent a Doodle poll to learners to gauge their availability on different days, and then chose days which worked for the largest number of people. (If you are organizing a larger workshop, this is probably not a viable approach.)

  • Scheduling a room to hold the sessons: While we were initially going to hold the workshop in the CQuIC conference room, we realized that space might be a bit small. Thankfully, the Physics and Astronomy Department has an easy-to-use web scheduler, with first-come, first-served scheduling. (Again, for larger workshops, you may have to get an auditorium or other larger space.)

Practical Tip: Sort out logistical issues as far in advance as you are able. Expect your solution(s) will change.

4: Live-code your lessons.

Jonathan Gross had suggested this approach, given his experience with Software Carpentry workshops. I’m glad we implemented it! In a nutshell, for each lesson, we had both the instructor and the learners type out code. This approach had several benefits:

  • The instructor couldn’t zip through pre-written code, causing learners to rapidly fall behind.

  • Learners could see the instructor make mistakes. As the instructor corrected them, he could explain why a mistake happened, what the error message meant, and how to fix it.

  • It teaches the instructors about lesson planning. Knowing that I was going to have to type out code in real time forced me to think more deeply about what content I wanted to cover. (And even with that, each lesson still had content that wasn’t covered!)

To enable learners to give real-time feedback about how they were doing, we used the sticky system suggested by Software Carpentry. Live coding made this kind of feedback much more effective: seeing a wave of red stickies go up, the instructor knew it was time to stop and see what was going on.

Practical Tip: To help you remember exactly what code needs to be written, first write out all the code. Then, go back and add descriptive comments indicating what each line does. Then, delete the code, and use the commented-up file as a template to guide you and the learners through the lesson.

5: Delegate as much responsibility as is appropriate.

If you are like me, and are the kind of person who likes leading teams and being a driving force in projects, this lesson is for you! In my role as an organizer, I was responsible for communicating with learners (workshop announcements, etc.), purchasing coffee and snacks for breaks, handling the room scheduling, and coordinating the other organizers. In my role as an instructor, I taught 4 lessons, 3 of which were written from scratch. While that amount of work was manageable, I fell into the (classic) trap of over-extending myself, and in doing so, robbed other organizers of a chance to let their talents shine. The other organizers could have handled some of my tasks much more competently than I, and it was a mistake to not see that.

Part of being a leader is recognizing that you cannot do everything yourself. While that’s somewhat self-evident, an extension of it is that you should focus on doing what you are good at, so that others on the team can do what they do best. A leader needs to maximize the strength of the team and minimize its weaknesses. “Task hoarding”, or avoiding delegation, accomplish neither. (Of course, not all responsiblity can be delegated. I cannot expect someone else to write my own lessons, now can I?)

Running this workshop helped me realize the importance of knowing what can, and what cannot, be delegated. It also showed me the benefit of working with motivated, competent people - you can delegate and know not only that things will get done, but that they will be done well.

Practical Tip: Go read “Extreme Ownership” by Jocko Willink and Leif Babin, especially Chapters 2 (“There are No Bad Teams, Only Bad Leaders”) and 10 (“Leading Up and Down the Chain of Command”).

Thank you!

Putting this workshop together was no mean feat, and I want to thank Jonathan Gross, Anupam Mitra, and Xiaodong Qi for their time, help, camraderie, and patience.

A special thank you to CQuIC PIs Ivan Deutsch and Carlton Caves for their support of our efforts.

Thanks to Software Carpentry for providing open-source materials, some of which we incorporated into our workshop.