The Oslo Bootcamp

This post originally appeared on the Software Carpentry website.

Karin Lagesen writes:

The bootcamp took place at the University Library at the main campus of the University of Oslo. We had set a limit at 40 people, and we had a total of 32 attendees signing up. Sign-up was in the beginning quite slow, and we were actually at one time wondering whether we would have to cancel the event. But, as we got into June sign-ups picked up. We had decided to ask people to pay $20 to sign up (which was subsequently converted into coffee) and this might have caused people to not sign up until they were sure they could join. We ended up with 27 actual attendees the first day and 25 on the second day. The attendees were for the most part related to biology in some way—not strange considering we had advertised it in connection with the Galaxy 2013 community conference and on several bioinformatics related email lists. Also, most of them were either doing their PhDs or working on a post-doc. Both Lex and I feared lots of issues with installation, but even though the pre-bootcamp survey showed that almost half of the attendees were bringing Windows laptops things went surprisingly smoothly.

This was the second bootcamp that I have taught—I also had the pleasure of teaching with Alexandra Pawlik in Krakow in May. In Krakow I taught shell and Python. At the Oslo bootcamp Lex took on the shell part, and I had the daunting task of teaching Git. Although I have used VCS-es before, I had only started using Git this spring, so teaching it was quite a challenge. However, I did have a nice set of lessons that Alexandra Pawlik had helped me find, which made teaching it a lot easier than it could have been. Overall, I think the Git tutorial went ok. We had a collaborative part at the end of the session, where people paired up and worked towards the same repo. The room was during this part of the session buzzing quite a lot, and it seemed like people were quite nicely able to push, pull and merge their changes. I think that this session in particular served to show the power of version control.

Teaching Python actually turned out to be more difficult than Git. I believe this was caused by me knowing Python a lot better, and that I simply tried to teach too much. I spent too much time on basic data types and did not proceed quickly enough to the functions and modules part of the tutorial, which IMO is where the real power of Python in a bootcamp context lies. Some people also had to leave before we got to this part of the Python tutorial. Someone once told me that when teaching you should create our curriculum and then cut it in half before proceeding, and this is most definitely what I should have done with this Python session.

All in all I think the bootcamp went well. We have yet to see the results from the post-bootcamp survey, but I have the general impression that the attendees were happy with the material and felt they got what they came for. For me this was both fun and challenging, and I look forward to doing it again.

Lex Nederbragt writes:

This was my first bootcamp as an instructor, and I taught the shell at the beginning of the first day, and data-exploration using the IPython notebook and Unit Testing at the end of the second day. Karin and I had practiced the material for our colleagues, so at least I felt prepared. Based on blog posts summarising other bootcamps, I mostly feared the technical problems with people's laptops that undoubtedly would appear. It was not too bad in the beginning, but we had some weird issues with Git and IPython during the second day. Apparently, installing Canopy is not enough, I guess one needs to actively add IPython and it's dependencies. So, we lost some time there but overall we managed to get through the material, not least thanks to the help of three of Karin's colleagues who volunteered to attend to people's problems.

Attendants were all from Europe, with many from Norway, and even one from Zurich. They were the usual mix from total newbies to people who already code a lot for their work, and for whom much of the material was an eye-opener and/or aha-moment. That is very satisfying to experience as a teacher. One of the best moments for me was when we asked the students to pair up to figure out the code that produced a certain given outcome. This was a good puzzle and took them some time to get right. We then used this function to come up with a set of unit tests (I copied this exercise from the bootcamp I first attended, where Greg Wilson taught this). The other highlight was teaching the IPython Notebook, a tool that I have come to love myself (making it easy to be enthusiastic while teaching).

It was great fun to teach these people; they were smart and very interested and overall very happy with the bootcamp. I wish I could find out in half a year, or 12 months, how they are doing, whether what we taught them stuck and has changed the way they do their work—as attending a bootcamp has done for me.

At the end of the bootcamp we did a good/bad session. Here are what the attendees answered:

Good Bad
  • learning Python +4
  • Git +5
  • collaborative editing/conflict merging +1
  • IPython notebook +1
  • pandas in the IPython notebook
  • learning unix shell
  • helpers and stickies
  • location +many
  • practically applicable, can see instant use in everyday work
  • unit testing +1
  • coffee and tea
  • working with a remote repo
  • get to know people
  • got what I came for +many
  • installation issues
  • went over time +1 (we finished later than advertized both days)
  • got lost some times (technical issues)
  • sometimes too fast, difficult to catch up +1
  • need to see more of the code in same window
  • make empty lines between commands in shell
  • would have wanted to learn about debugging too
  • take more time for case study, i.e. independent work
  • use whiteboard to explain logic
  • hectic at times—things moved too fast
  • unit testing could be earlier
  • beginning Python stayed too long in the interactive shell
  • tie the IPython notebook work in with the Python module principle
  • should have specified beforehand not only what software that was required, but also version numbers.
  • not sure whether they would be ready to reuse and integrate what we taught
  • could have an advanced bootcamp, introduce IDE's, project organization, etc.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github