Stat 370 2017S Post Mortem

As STAT 370 draws to a close, it is time for analysis of what went well, and what could be done better.

What went well

Flexible projects: I believe that the only reasonable way to learn to code is with projects you are passionate about. I encouraged students to find such a project and some, if not many did. I gave them about as much flexibility as possible to pursue their dreams. If students found a topic interesting, I wanted them to pursue it and I did not want to stand in their way. I did however steer students toward original projects, not just repeating analyses done by others. I believe that students who felt the passion certainly benefited from it. And the ones that did not fall in love with their topic were probably not hurt by the flexibility I gave them.

Reproducible research and dynamic documents: I experimented with these course objectives and I would definitely continue to make this a big part of the course, if I teach it again.

Course work posted on a web server: I feel very certain that having a course web server is the right way to go. Having shell access to the server means students can clone and update their projects with simple git shell commands. Students have their own home directory and their own public_html sub-directory where the server looks to publish any work. Students all seemed happy to have their work published to the web.

Course wiki: This ties together everything on the web-server with links to project pages and Github pages.

Github: Github was useful for moving files between the server, students' laptops, and the lab computers. Students found the learning curve manageable.

Instructor learning topics on the fly: So much of what I learned I learned on the fly. This worked in many cases, and it was necessary. Being able to learn new things allowed me to adapt to the interests and experiences of the class. But if I teach the classes again, I will certainly benefit from the learning curves I traversed this semester.

GNU-Make is too hard, even if I write the Makefiles: I wanted to use GNU-make so that students could build their projects on the server, and wouldn't need to put large, completely changing with every update, html files under version control. This is what you are supposed to do but it was prohibitively confusing. And using GNU-make created the problem of character set incompatibilities between Macs and the Linux server. It became apparent in a compelling way that students should build their pages and sites with GUI tools, on their own computer, commit the html files to Github, and pull them onto the server. That said, one student had a very complicated website, with many pages, that took about 10 minutes to build in R-Studio---every time she made a small change. We wrote a Makefile together that only build the specific pages that she had changed since the last build. This saved her a lot of time a frustration. While Make isn't a tool for the whole class, it's good to have in your back pocket for these situations.

Keep shell interaction as simple as possible: Students get confused by the shell and don't seem to understand its power. They prefer GUI tools, even though programming is done with typed commands. As the class proceeded, I discovered simpler and simpler ways of doing things, which should benefit future classes.

Data visualization, Shiny, Plotly: