PyLadies Workshop Wrap-Up

6 November 2012

A chilly weekend in October, PyLadies descended upon the American University campus to teach a class for women on programming and Python.

Workshop numbers

We had thirty-five slots (five were for AU students, and the rest were for us). Every one of the Meet-up slots was filled, and we had a small waiting list.

A few days before the workshop, we asked people to drop if they realized they couldn't make it. Some did, so everyone on the wait-list ended up getting in.

We ended up having twenty-four students, and this was a very good thing. Any more, and we would have had students without desks. As it was, our volunteers had to sit against the wall.

A panoramic of the PyLadies workshop, from the teacher's perspective.

Materials

With our first class, we used the MIT materials given to us by other PyLadies chapter. This time, though, we wanted to try doing something on our own. I had some different ideas about teaching order, so we scrapped those materials and started fresh.

Well, 'fresh.' To be honest, I was using the order from a book I'm writing. I wanted to give it a dry run on some actual humans before sending the book off for publication. My theory, when putting together the table of contents for the book, was that going back and forth between data types and functionality offered more chances for reinforcement than diving into data types first, then functionality.

I also decided to use IDLE, since getting paths set up is a pain in the ass, when you're talking 20 windows machines. While I still think IDLE is a great teaching tool, having some people on older versions proved an issue. I may turn set-up idle time into 'learn how to get around your computer' time, since many students don't know how to open a terminal or change directories.

Sign-up

This time, we did sign-up through the DC PyLadies meet-up rather than through the much larger DC Python group. This meant our class was filled within days, rather than hours, and our wait-list was much smaller (last time, if memory serves, our wait-list was three times the number of spots).

We kept the number of slots the same (30), but added a new rule: The class was for women and their friends. Basically, men could attend as long as they came as the guest of a woman.

Why did we do this? Because last time, the waiting list was almost completely male. This made me wonder if the fact that our class was mostly women was only due to chance. Had we posted at a slightly different time, would the class have been mostly guys?

This isn't the case for every PyLadies chapter (or group that's set up for women and programming). Some have never run into this issue. Some have had huge issues with it, and have had to put this rule in place for even their casual meet-ups. We added this clause because I'm not sure yet where we fall on the spectrum.

In our case, only two men signed up, so we didn't have to have any awkward conversations. Huzzah!

Also, we didn't charge for the class. I don't believe in nominal fees. No, not because I'm completely selfless; I don't believe in them because they tend to have the opposite of the intended effect. When people shell out a few bucks for a seat, they feel more justified in not attending. You've basically given them a way to pay off their guilt. If you don't let them do this, then they're more likely to get out of bed early and get to class.

Volunteer meeting

A few days before the class, we had a meeting with the volunteers, which I highly recommend to anyone running an Intro to Python class. We covered the syllabus, schedule, and some ground rules:

  • Don't dis the student's ideas, or point out that it's already been done. Everyone has to write a shitty blog app at some point in their career.
  • We have two days to teach the students about Python, so we're going to be streamlining. We're not going to mention some things on purpose. We only have so many hours, and their brains are only going to be sponge-like for part of those hours.
  • Watch for confusion. Never assume the student will 'totally get it later.' They will not. Back up, try again.
  • If you are still running into a wall with a student, grab another teacher / volunteer and let them try.
  • If you think of something that we need to go over, ping me during a break, not while I'm teaching. It might be something we're not going to cover, or I might need to whip up an example really fast. Heck, I might need to check the help, because it may have been a while since I used that particular bit of Python.

Day One

Setting-up

I don't know what the hell happened in DC on Saturday, but traffic was horrific. Like, sit in one spot for 30 minutes horrific. I'm a hardened native who thinks anyone who whines about an hour long commute is a wuss, but even I was yelling 'Oh, come ON!' over my steering wheel. I'd planned on being there an hour early, and was there an hour late.

Happily, everyone else where there on time. The first hour was dedicated to setting everyone up, so all I missed was a bunch of cursing at Windows machines.

I recommend setting up in person or over a screen share, because instructions can easily go off the rails. One click installers often aren't. Sometimes students grab the wrong version, or installed a version that was current a while back. Sometimes, they grab Python 3 no matter how many times you say "Get 2.7" because they've been trained to get the latest version of whatever they need.

You also do not want a poor Windows user screwing up their path while they try to get Python to run on the command line.

Wifi was problematic due to some duplicate logins. Some people stayed on fine. Others kept knocking each other off. We weren't doing much with the Internet, but I still recommend bringing in installers on flash drives. I also recommend making sure that the students have wifi before anyone else.

Let's get started!

Once everyone was set-up, I realized we still had a while before lunch, so I went ahead and started covering some introductions and basic concepts.

I talked a bit about who we are (most of the attendees had never been to a PyLadies meeting), gave an overview of the class, and talked about all the stuff that Python can do, and is currently doing. We had a mix of students, from a high school student to people into scientific computing, as well as a hardened Java and PHP developer. I tried to hit on as wide a range of applications I could. I wanted everyone to recognize at least one thing I was tossing out there.

At that point, I pulled up IDLE and started going over some basics.

  • What's a variable?
  • Numbers (floats and integers)
  • Math
  • Comparing values
  • True and False

At this point, food was ready, so we ate and helped anyone who was still having technical issues.

After lunch, we moved into our next topics.

  • if / then statements (with a quick dip into try / except)
  • What's a block?
  • Storing text
  • Playing with text (conversion and math)
  • Getting input from the user
  • Lessons about trusting the user (never trust the user)
  • Working with files

By this time, it was three o'clock, so we introduced the idea of student projects. We asked them to go home and think about what in their life could be automated, or what they were curious about. Sunday afternoon, we'd break into groups and help them realize at least a part of their project.

I then went home and drank.

Day Two

There was a marathon scheduled in DC, so I emailed students, warning them to check their route. I struck out early and managed to get there insanely early.

Note: Nothing is open on the AU campus on Sunday.

I didn't notice any attrition on our second day, which delighted me. Everyone showed up, we cleared up a few technical issues, did a quick review of what we'd gone over the day before, then launched into more Python.

More Python!

We were only teaching that morning, but we crammed quite a bit in.

  • Lists
  • For loops
  • While loops
  • Dictionaries
  • Imports
  • Functions

Brains full, we had lunch, then moved on to student projects.

Student projects

Previously, we had the entire class do a Twitter project. This time, though, we decided to let the students think of their own projects. We broke them up into groups that had roughly the same idea. There was a web group (including a woman who got Django running the night of the first class!), a PyGame group, some OS people, and... other groups. I'm kicking myself that I didn't make a note of all the groups that we had.

Volunteers and teachers moved amongst the groups, helping students focus a big idea into something more manageable. It was amazing watching students work through the logic of a program, then light up when their code started doing what they expected.

The next level?

One request we got from many students was a second class, covering the next level of coding. We didn't get to object oriented programming (because come on, people! We only had two days!), and we were barely got to cover imports or installing other libraries.

I'm putting together materials for a 'Intro to Python II' class now, and trying to figure out a way to screen for people that may be better off in the Intro I class. Ask them to write a bit of code? Quick test? Ask that they finish the Codecademy Python section before they come in? I don't want to put people off, but our time and the seats available are highly limited. I'd rather not have a class full of people who assume that they'll catch up quickly.

Releasing materials

I was asked during the class whether I would be releasing the materials for others to use, and the answer is 'yes.' I'm just considering licensing. Creative commons makes the most sense, so I've been reading over all the variations. After talking with some people who've used CC licensing, I think I'm going to go with CC-NC-SA. So, people are free to use the materials (with attribution), and alter them (as long as they share alike), but any commercial uses will require a waiver.

I may strip off the NC part, but it was pointed out that, once I do that, I can't undo it. I'm not against people charging for a class, but I want err on the side of caution for now.

Last but not least...

A huge thanks to my co-organizer, Jackie Kazil, who made the food and the space happen, DC Python for lending us their non-profit status, all of our wonderful volunteers who made it possible for me to teach without having to debug someone's computer every two minutes, Social Code for the sponsorship, and American University for the space.

Share

Related tags: python women

Comments

1 Barry Morrison says...

Were any of the attendees able to complete the project they started on Sunday? From Idle, did you move them to a text editor?

Obviously 2 days isn't enough time to talk about source control (scary words for anyone), but were they saving to a thumb drive or how were they able to take their project with them?

Did you feel that letting them do their own project vs. a defined/completed project was better. On one hand I can see the benefit that it's something that interests them, they can relate to better than Twitter (maybe they don't even use twitter!)...but having an outlined project, you could have "stages" if you will...student gets behind, or what not, they could simply reference the source of the stages and/or view the completed source/app. Thoroughly commented code would allow them to view code and find blocks they're stuck on.

I'm also curious if someone's project wasn't perhaps very (lack of a better word) advanced -- how do you weigh what you've taught, versus what might be necessary to actually do/complete the project. You don't want to squash their dreams persay, but how do you instill a sense of realism?

Did you have a feedback form/survey to grade the coursework/instructor/volunteers/event?

Posted at 9:21 a.m. on November 6, 2012

2 Katie says...

@Barry

So many questions!

> Were any of the attendees able to complete the project they started on Sunday? From Idle, did you move them to a text editor?

Some got a good chunk done, including one woman who got Django running and created her own app. We did only have four hours, so the idea was to give them a solid start, get one piece of functionality working, and introduce them to the libraries they'd be needing to continue.

> Obviously 2 days isn't enough time to talk about source control (scary words for anyone), but were they saving to a thumb drive or how were they able to take their project with them?

Every student was required to bring their own computer with them, so everyone took their code with them at the end of the day.

> Did you feel that letting them do their own project vs. a defined/completed project was better. On one hand I can see the benefit that it's something that interests them, they can relate to better than Twitter (maybe they don't even use twitter!)...but having an outlined project, you could have "stages" if you will...student gets behind, or what not, they could simply reference the source of the stages and/or view the completed source/app. Thoroughly commented code would allow them to view code and find blocks they're stuck on.

I felt that letting them do their own project generated a LOT more excitement than a project that we'd outlined for them. It also gave them experience in focusing and narrowing requirements, which they wouldn't have gotten otherwise.

> I'm also curious if someone's project wasn't perhaps very (lack of a better word) advanced -- how do you weigh what you've taught, versus what might be necessary to actually do/complete the project. You don't want to squash their dreams persay, but how do you instill a sense of realism?

I don't think any of the projects were too basic, but if one had been, I still would have helped them complete them. Each student had varying levels of comfort with Python by day two, so we encouraged each student to do use the tools they felt comfortable with, rather than pushing them to use things they didn't quite understand yet.

> Did you have a feedback form/survey to grade the coursework/instructor/volunteers/event?

No, we completely forgot to set that up, but the class was highly rated on Meetup, and the follow-up responses have been really positive.

Posted at 9:58 a.m. on November 6, 2012

3 Mohamed says...

I recommend using PyScripter. It's very easy to use and has nice debugging features.

Posted at 12:13 p.m. on November 6, 2012

4 Nick Coghlan says...

Thanks for the very interesting write-up, but I do have one question: what are you introducing under the name "block"? Python doesn't have anything user visible that's referred to as a block in the language docs (except in the generic "here's a block of code sense". Do you mean suites?

Also, be wary of CC-NC licensing, as it's not at well defined legally (is someone reposting your stuff on a site that runs Google AdWords a violation?). If you haven't seen it before, I highly recommend this discussion between Nina Paley and Cory Doctorow regarding the merits of using CC-NC-SA vs using CC-SA in conjunction with the Creator Endorsed mark: http://blog.ninapaley.com/2010/09/01/paley-vs-doctorow/ (obviously, I'm firmly on Nina's side in that argument, but it's worth having a read before deciding)

Posted at 6:03 a.m. on November 7, 2012

5 Katie says...

Hi Nick!

> [W]hat are you introducing under the name "block"?

I mean indented code. This is something that experienced developers often forget about that trips up new coders.

> Also, be wary of CC-NC licensing, as it's not at well defined legally (is someone reposting your stuff on a site that runs Google AdWords a violation?).

I'll probably add some automatic waivers (if you have adds on the page, or are charging a fee LESS than X for your class, have at it).

I still have a while before I decide. I don't plan on releasing the materials until December, anyway. I'll give that link a look!

Posted at 7:54 a.m. on November 7, 2012

Comments are closed.

Comments have been closed for this post.