- Similar posts for 'python':
- Katie writes: Kids Code!
- Looking back, looking forward
- Your wiki is a dump
- Teaching: The OS Divide
- Beginners: What now?
- Similar posts for 'women':
- PyLadies Workshop Wrap-Up
- Getting more women to your meet-up
- Lighten Up: A follow up
- Lighten Up
- Vagina Invalidation Argument
- 7/14/14 - Flask + git: Easiest workshop ever
- 7/8/14 - Katie writes: Kids Code!
- 2/7/14 - Rune Factory 4: *What* romance options?
- 12/31/13 - Looking back, looking forward
- 12/11/13 - Your wiki is a dump
- 12/4/13 - Review: System76 Galago UltraPro
- 12/2/13 - What I learned from NaNoWriMo 2013
- 11/12/13 - Alt text - doing it right
- 11/4/13 - Teaching: The OS Divide
- 10/28/13 - Nanoblogmo
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.
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.
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.
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.
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.
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)
- 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.
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.
We were only teaching that morning, but we crammed quite a bit in.
- For loops
- While loops
Brains full, we had lunch, then moved on to 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.
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.