Summary of 2016 debrief
Here we will summarize the points that were discussed in the debrief meeting. Feel free to add/modify.
Here is a link to the exit survey and the responses
General Remarks
- Overall feedback was positive
- As predicted, people most enjoyed the projects/excercises and want to see more of those.
- The pair/group programming approach was popular
- Git and Bash were both divisive subjects
- A number of people would have appreciated more advanced topics / splitting the group according to skill
- The organizational aspects (e.g. course mailing list, making all materials available at the start) could be improved
- In relation to the above, we should give more motivation to the day's activities
By Topic
Basic Python
Positively received. Some people made the comment that it was too easy and could have been set as a preliminary excercise before the course.
Bash
Divisive subject, although people's preconceptions seem to have played some role in this (e.g. "I never liked the shell"), while other people learned a lot and found it useful.
Points for improvement
- more motivation for why shell is useful (examples where you really could not do this with a GUI)
Scientific Python
Overall positively received.
Points for improvement
- Be more specific about what will be taught (the aims of the lecture: maybe focus more on workflow than the tools)
- Be more pedagogical (slow down so people can follow on their own screen)
- Have a more gradual difficulty ramp for the exercises (similar to day1)
Git
As usual, this was a divisive subject but this is probably an intrinsic property of Git.
A number of people said that they couldn't see themselves using it in their daily work (which, for someone working in science, is a little difficult to believe). This may stem from a need to better motivate the problem that Git solves. The PhDComic was cute, but maybe a real example from the instructors own work could be used?
Related to this, we could consider giving the students a source tree with an existing history to work with. The problem with working with a history of ~2 commits is that it's hard to see what the point is. Maybe we could come up with "real scenarios":
- What version of my paper did I actually submit to Arxiv?
- What did my collaborator change since yesterday?
- When was this change on this line introduced? By whom?
- I want to undo the changes I just made
- ... that people can more easily map onto their own workflow. Maybe have excercises that require people to work with and manipulate the repository.
Driver / Experimental control
Positive responses, except a couple of people. Maybe give some more specific guidance.
Points for improvement
- A "fake manual" for the equipment that we are driving.
- Maybe have a publically-listening port for instructors to more easily debug students' instrument servers
Projects
These were most people's favorite part. Some people would have been happier with some more specific guidance. I think a more curated selection of projects, categorized by difficulty could be very beneficial. The easier projects should contain more guidance about overall structure (e.g. "write a function that takes X and returns Y").
The only issue with this is that it takes a reasonable amount of work to assess the difficulty of a project and come up with relevant guidance, so in practice we need a single person who can take responsibility for coordinating this effort.
Maybe we could present the projects and talk a little about each one, to make it explicitly clear what is expected.
Having groups give a short presentation about their project is a good idea.
Action Points
-
Make current course materials available on the web (and send email around about this) -
Update course description (remove the more advanced topics that weren't covered) - Develop our "library" of longer projects (this is a longer running issue, and so will be split out into sub-issues)
- Write a "fake manual" for the instrument server