search

swcarpentry / DEPRECATED-bc

DEPRECATED: This repository is now frozen - please see individual lesson repositories.
Other
299 stars 382 forks source link

Collecting tips, tricks, and other hacks for teaching Software Carpentry #56

Closed ahmadia closed 10 years ago

ahmadia commented 11 years ago

We've developed a lot of collective wisdom as instructors over the last several years as we've taught boot camps around the world. This issue will serve as an initial collection point for tips that will end up in a centrally collected place on the website.

Before you contribute, a few guidelines:

I'd prefer to format the contribution page in such a way that we provide a link to the instructor who initially suggested the tip. Please format your name with a URL that you would like if you provide a tip (e.g. from Aron Ahmadia. I can't promise that we'll credit you, but there's a good chance it will happen if you provide something particularly novel or effective.

Try to add a couple keywords that will help us categorize your tip. Please re-use a keyword if it's already active and close. Otherwise, feel free to add your own! Here are a few suggestions.

Please keep discussion in this thread. I'll start up a separate announcement of this thread on discuss, but we're going to try this discussion as a GitHub issue and see how it goes.

Please check if your tip already exists either in the thread or in one of our other pages. Feel free to throw in a "me too", or a link to the tip if you have an improvement or modification to the way the tip is currently stated. Be polite!

Here are the places I'm aware of tips existing on our website. If you find another location where tips are posted, bonus points for you and I'll fix this top-level post to reflect that.

gonuke commented 11 years ago

A variation on the red/green sticky notes.... I made little name tents out of red & green paper, held together with name tag labels. The learners used the white area of the name tags to write their names (imagine that), and could prop the tents either green side up, or red side up, depending on the feedback they were giving about too slow, too fast, respectively. You can see them in action in this photo. photo

Another thing that worked really well - although requires the right space - was to have large white boards adjacent to the screen on which we kept a running list of the commands we had encountered in bash or in git, just a place for people to look back. We also drew a picture of the file system when working on the shell.

mikej888 commented 11 years ago

A co-instructor, when not instructing, can monitor the shared MoPad and update this with the key points made by the instructor, along with related hints and tips that the instructor may not have mentioned. It's less disruptive to the "live" instructor than interjecting with these points, but allows the attendees to get the shared expertise from both instructors.

rhiever commented 11 years ago

Randy Olson (http://www.randalolson.com)

planning

Plan for the first 30 - 60 mins of every bootcamp to be spent on setup, installation, and catching people up. Even if you don't put that time in the schedule, that's how it's going to turn out anyway, and your first lesson will get shafted on time. I've seen some success (N = 1) with scheduling a meeting a day before the bootcamp to sort out installation issues -- and if they don't show up and prove they have everything installed, they are not allowed in the bootcamp.

establishing credibility

When using IPython Notebooks to teach Python, I start the section by talking about ipynb and its relationship with open science, reproducibility, and the benefits thereof. Then I show them actual ipynb's from my own research, highlighting note taking style, data processing, statistical analysis, plotting, etc. all in one notebook. Similarly when teaching version control, testing, etc., I start out by showing and talking to them about real-world examples (my own or others) to motivate why these tools and techniques are useful. Anything to get them motivated to learn and try out these new tools. I believe showing your own examples from your own research strongly establishes your credibility on the subject.

assessment

At the end of every day, have the students write what they liked & disliked about how the material was delivered on the stickies (green for liked, red for disliked). Also ask them to mention on the red sticky if there are any additional topics that weren't covered that they would like to go over before the end of the bootcamp. Have them turn those stickies in to you before they leave. I've found this daily feedback to be tremendously helpful for adjusting the bootcamp on the last day.

assessment

I picked this one up from Jordan Fish. Similar to the assessment tip above, instead of doing the stickies for feedback, have them fill out a Google survey before they leave for the day, answering the following questions:

1) Let us know something you liked about today. 2) Let us know something you did not like about today. 3) What did you learn today that is useful to you? 4) Is there anything you have, or still have, a question about? What's your question?

Although we get much less feedback on this form (in terms of # of people filling it out), the directed questions result in much more useful feedback. Most of the feedback we get on the stickies is not too useful ("good job!", "too fast", "too slow").

rhiever commented 11 years ago

wrapping up

It's really important at the end to stress how important feedback and assessment is to us. It especially helps to mention that we're volunteers and are learning how to best deliver this material. If you don't stress the importance of useful feedback (i.e., not "I didn't like the coffee"), well over half the classroom will walk out without even writing something on the stickies nor filling out the survey. Also, don't let them leave until they fill out the survey -- don't count on them doing anything once they leave on the last day.

rgaiacs commented 11 years ago

Raniere Silva (http://www.ime.unicamp.br/~ra092767)

assessment (or feedback?)

I setup one pad for class notes and another one for feedbacks. I only got one feedback but that can be because this experiment didn't happen in a bootcamp or the comment of @rhiever.

rgaiacs commented 10 years ago

examples and exercises

Ijust end to teach a small course about LaTeX and ask the students to reproduce a little page (only half of it have text) in 40 minutes (students that already use LaTeX finish it in 20 minutes and novices only do half of the exercise) and after finish create a gist with their code (I review the code after the class). It was a very small experiment but seems to me that the students like the exercise.

ahmadia commented 10 years ago

technical troubleshooting

We all support Shell and Git on multiple operating systems, which can be a real pain when you've got students running Windows, Linux, and OS X all in the same session and you're trying to give them the same "look-and-feel" on wildly varying environments.

Install nano on Windows for a unified editing environment

Use the community nano installer, since it is not available by default in msysgit (somebody want to file a PR?)

We have some notes you can use in your install page, but they are not yet available by default

https://github.com/swcarpentry/bc/blob/gh-pages/setup/swc-windows-installer.py

Use nano everywhere when editing files and handling commit messages in Git.

Head to the desktop!

It turns out that:

cd
cd Desktop

always lands students on the Desktop. This is great. They can make files/directories and see the changes, both visually and with ls. This is a great visual way to reinforce what we're teaching, AND they have the ability to open and edit files without hunting around for them. I used this trick at the SESYNC workshop and it was surprisingly effective. We should also perhaps consider updating our shell lessons to get set up on the Desktop by default.

wking commented 10 years ago

On Thu, Dec 12, 2013 at 11:55:59AM -0800, Aron Ahmadia wrote:

Use the community nano installer, since it is not available by default in msysgit (somebody want to file a PR?)

They already bundle vi, which is probably what they use personally. I think other editors are likely to be beyond the scope of msysGit, but I suppose it wouldn't hurt to ask ;).

cd Desktop

This is probably not a big deal for students, who are probably not using fringe desktop, but not all Windows managers use a Desktop directory. Fluxbox (my personal favorite) doesn't have desktop icons at all (there are third-party programs for that 1). Still, anyone without a ~/Desktop will likely not be taking our class.

rhiever commented 10 years ago

@ahmadia, can you please do a write up here about your metaphors for the shell and slicing/indexing? I think that'd be valuable to have here. Maybe include quickly-drawn diagrams to show what they should look like.

wrapping up

While going through the introduction to SWC at the beginning of Day 1, write the high-level advice on the board:

  1. Be fluent in multiple languages
  2. Make it work right first, make it fast later.
  3. Increase debugging bandwidth
  4. Don't Repeat Yourself (or Others)
  5. Automate common actions by saving simple blocks of code into scripts
  6. Refactor commonly used blocks of code into functions
  7. Group commonly used functions into libraries
  8. Reduce Complexity
  9. Back up your data!
  10. Use version control for checkpointing and collaboration
  11. Verify and Validate your Code
  12. Document your computational work

Keep that up for the rest of the boot camp, and put a check next to each tip when it's covered in the boot camp.

If you're near the end of day 2 and there isn't a check next to one of the tips, make sure you cover it before the end of the day.

ahmadia commented 10 years ago

Refreshing my memory:

gonuke commented 10 years ago

@rhiever I've actually been trying to recast the entire curriculum through the lens of this kind of high-level advice (a la "Best Practices" paper) with the understanding that audiences don't attend bootcamps to learn to program shell or python. Rather, they want to know how to "automate their work" or "write code for people", for example (respectively).

rhiever commented 10 years ago

:+1: Do you think the current material doesn't cover those topics well enough? i.e., too focused on the particular tool?

gonuke commented 10 years ago

I think it's a matter of tone. Any given instructor can add this flavor to the material as they teach it, but if I had enough time (ha!), I'd like a version that made frequent explicit reference to the best practices.

gvwilson commented 10 years ago

Replaced by #378.