Home> Blog> The Good and the Bad of It

The Good and the Bad of It

This post originally appeared on the Software Carpentry website.

We've come to the end of a hot, slightly sweaty, two days of learning in UCL and have just done a straw poll of participants of the good and bad points of this bootcamp. Something that was trialled at UCL was asking participants to sign up in small (3-4 people) teams drawn from their local research group. In total, we had a little over 40 learners and 10 helpers. We also taught the version control portion using EasyMercurial (thanks to Chris Cannam from SoundSoftware).

Here's what we learned...

Good

  • Beginner friendly
  • Easy learning curve
  • Now know how to use SQL
  • Doesn't matter what programming language I used in the first place
  • Version control for the win
  • Taught functional programming rather than object-oriented
  • Material backed up by anecdotes and evidence
  • Good at giving thoughts rather than skills
  • Can go back and share with other members of the group
  • Killed my fear of version control
  • Give tips on good programming practices
  • Anything new was given with the why as well as the what
  • Introduction to systematic testing
  • Best balance of typing, testing and listening
  • Good ratio of helpers to students
  • Greg's digressions keep your mind active
  • Learned feedback technique of using coloured sticky notes
  • Test driven development
  • Quoted Alan Turing (programs are just a type of data)
  • Working in pairs
  • Live coding (realtime typing)
  • Being forced to use python
  • Psychological aspects, and how it relates to programming
  • Always good to reinforce the learning of things you've heard before
  • Interaction with participants at workshops — both in workshop and in pub
  • Website is a good resource
  • Insight (for a sysadmin) of how the researchers I support work

Bad

  • Can't afford to buy all the books referenced
  • Too early a start [9am start both days in central London]
  • Too much to take in
  • Not enough functional programming
  • Lower level than group is used to
  • Need coffee at the start of the morning [which we didn't have on day 2]
  • Problems with the wireless network
  • Need biscuits in the afternoon
  • No handouts [though SWC does this because best practice suggests you shouldn't give out handouts at the start]
  • Lack of air conditioning
  • Too short (not enough days) [SWC experience shows that 5 days F2F didn't work, will have online followups]
  • Not clear when you should be furiously catching up on typing
  • Greg's too fast
  • Helpers not physically interspersed amongst tutors
  • Room too small
  • Not enough desks / table arrangements
  • Couldn't find nose on list of required software
  • No documentation on how to get nose running on a windows system
  • No toilets / running water on the same floor [we broke the toilets and the lift!]
  • Microphone would have been good
  • Recommending Cygwin rather than VMware or Virtualbox [but people want to come out with a working setup...]
  • Implied endorsement of bittorrent for illegal activities (plus smartass comments)

What does this tell us? Probably that the teaching environment has a much bigger impact than you might expect, and that we should do all we can to fix it upstream. Also that Greg talks and types too fast!

We're going to have plenty of chances to see how these good and bad points change as we go on to the next workshops — collecting the evidence so that we can understand how to teach people better.