Red Hat Research Quarterly

PyLadies, welcome to open source!

Red Hat Research Quarterly

PyLadies, welcome to open source!

about the author

Petr Viktorin

Petr Viktorin leads the Python Maintenance team at Red Hat, where he contributes to Python and its integration into Fedora.

Article featured in

How did a group of three library students become part of an international force for promoting programming education? A Red Hatter who was there has the story.

PyLadies is an international mentorship group focused on bringing women into the Python open source community. In many places around the world, they organize meetups. I first made contact with them in 2012, when Lynn Root from PyLadies San Francisco visited Brno. Root wanted to start a PyLadies chapter here, but couldn’t find women interested in discussing Python. She gave me a stack of stickers to give to PyLadies, should they organize. I gave the stickers to the first group of women I found that had something to do with Python in Brno: women who had organized themselves to learn programming.

While I did play a part in bootstrapping that group, and I still work with them, I’m not a member of the group. My role in the story comes from a different viewpoint: community programming courses. As with many open projects, the story involves many people who contributed and selflessly helped others. Here I’ll only tell my part of the story. I will need to simplify and to leave many amazing contributors out, and I hope everyone involved will forgive the omissions.

How it Started

PyLadies CZ are most known for organizing courses, mainly a beginners’ course, which I’ve been teaching in Brno for about six years now. Let me explain how that got started.

I’d been co-organizing Python community meetups in Brno for around a year when a few students of library studies asked for help with their Python course. I took on the challenge and told them to consider bringing a few more classmates. All three were women, so I suggested they could call themselves PyLadies. My employer, Red Hat, kindly provided a space. Red Hat already had a process in place for organizing community events, and meeting rooms were available for evenings and weekends.

The students shared their homework and teaching materials with me, and I could immediately see why they needed help. Their course was designed to train computer scientists. Starting with the first lesson’s motivational examples, the course assumed a deep love for mathematics, statistics, and puzzles. To future librarians, it didn’t portray programming as something useful.1

Some of my first students saw tutoring as an easy way to get answers to homework questions. Those were disappointed—instead, I only gave hints and explanations of concepts. After about three such tutoring sessions (and the course’s midterm exams), a lot of attendees left, but one came up with an idea to continue meeting regularly and go over the basics of Python and programming again, discussing them independently from their course. That sounded pretty fun to me, a software engineer.

The content was mostly up to them. I would provide a list of suggestions of what’s possible, they would choose a goal, and I’d explain whatever they needed to reach it. Together we made a few web API clients, some games, and a plane ticket reservation simulator. Over time, people gradually left. At the end, one attendee remained: a teacher who convinced me to gather a new batch of women and start a PyLadies course, explaining the basics again.

The Second Run

One thing I realized as people were dropping out of the first study group is that explaining things to a smaller group of people is much easier than working with a bigger crowd. A small group is more focused, and if someone has an issue, it is often interesting to solve it with everyone involved. Larger groups don’t have such luxury.

The new course, however, was not to be small. About twenty women signed up—enough to fill a conference room. Teaching so many people felt a bit scary. Then again, I told myself, the worst that could happen was that I’d waste a few hours of their time as they realize they’re not satisfied. Perhaps the group would even shrink to a manageable size that way. I asked colleagues from Red Hat to help, and the idea to spend an evening a week with the PyLadies resonated with a few of them. Some had time to come to the lessons; one even set up an additional meeting for extra tutoring.

Since the most interesting projects from the previous study group were games, I decided to teach the attendees to write a game. I think that was—by luck—a good choice. Today my courses still feature games, despite criticisms about practicality. It’s not easy to find a practical topic for general beginners: data analysis, system automation, website backends, algorithmic puzzles, or any other topic is interesting to some but boring or exotic to others. Games are impractical for everyone, but fun for most. And I’m careful to always mention that the skills learned on simple games are transferable to any other field.

Looking back, the course was quite imbalanced and chaotic, but I’m pretty confident that it was worth the money (0 Euros) for everyone, and worth the time for most. It was a reasonable first iteration.

Writing Down and Opening Up

I needed to prepare what I was going to say, and as a relatively inexperienced speaker, the best way to do that was to write it down, word by word. While I would not follow the script exactly in front of the class, I’d have something to reference if I stuttered, and I could make sure the explanations made sense. I put my notes online so anyone who missed a lesson could read it. Since they were quite verbose, they turned out to be useful for self-study or for organizing a similar course. And since it makes no sense to limit the content of a free course to just enrolled attendees, I put them on GitHub under an open content licence. Anyone could read them, reuse them, or improve them if they wanted, in the typical open source way.

People from other cities took the materials and organized a course in Prague in 2015, then in Ostrava in 2016, and more cities afterwards. An attendee created a web page at pyladies.cz to list the different cities and courses. People started contributing to the published materials, first fixing typos, then reorganizing the course to suit different lecturers, and even writing entire new lessons.

I knew things like this happened in the open source world, but this was the first (and only, so far) wildly successful project I started. I was blown away by the effect it had.

Reading Up

The next episode in the story came after I saw a recording of Greg Wilson’s talk at PyCon 2014 in Montréal, “Software Carpentry: lessons learned.” Software Carpentry is an organization that teaches programming to scientists. They do a very good job at it, incorporating pedagogy research and openly sharing all their materials and know-how. 

I read the literature recommended in the talk and incorporated many ideas Greg mentioned, like giving students red and green sticky notes with which they can quietly indicate if they are stuck or, respectively, finished with a task. Since then, Greg wrote Teaching Tech Together, an openly available book for anyone who wants to run community courses. I heartily recommend it.

Delegation by Resignation

Teaching and writing content is quite time consuming, but I enjoy it. There are other aspects of organizing a course that I did not enjoy as much: selecting attendees, recording feedback, or reserving the meeting room. Around 2016, I announced that I would not organize the next run. If there was to be another course, PyLadies Brno would have to organize it themselves. I could still teach, and be available to help, but only if asked.

Thankfully, organizers did step up. Some PyLadies liked the community and wanted to continue meeting like-minded people. Some felt that it would be fair to “pay” for the course with their time. Some wanted experience organizing events. Some wanted an excuse to be at the next course, so they could go over everything once again.

With courses no longer restrained by a single tired organizer, they flourished. The new organizers started going for dinner and drinks at a restaurant after each lesson, leading to more new friendships—and a lowered drop-out rate. They came up with a better process for selecting attendees or for giving feedback. I did not agree with all the changes, but since I was no longer an organizer, I gave suggestions and then kept silent.

Having delegated the organizing to others, I’m essentially doing only the role I like: preparing lessons and teaching. The nice part is that nearly everyone involved also does only the roles they like. And when someone stops liking a role, there’s usually someone else to fill the empty space. From this point, I started seeing PyLadies Brno not as the courses’ attendees, but the organizers. The attendees often include a guy or two. I, with my beard, am just an external lecturer. It’s the PyLadies who make it happen.

Programming vs. Computer Science

I teach programming, rather than computer science. I skip algorithm design and all kinds of theory I learned (and enjoyed!) at the university. Sometimes, that leaves people worried.

A century ago, each car driver also needed to be a mechanic. A few decades ago, each programmer needed to be a mathematician. Neither is the case today. Just like you don’t need to know how to replace a brake pad to drive, you also don’t need to implement Quicksort to automate downloading spreadsheets. Of course, just like we need car mechanics, computer science is still relevant. We just don’t need everyone to be a computer scientist. And universities already do a good job teaching the interested people.

I would actually be OK if my students forgot all programming skills and were only left with an idea of what programs can do. That way, next time they find a very repetitive task, they know it’s possible to automate it. Even if they forgot how, they will know that a programmer can automate the job for them, just like they know to look for a lawyer when they need to sign an important contract.

Going online

During the years I spent teaching, I always resisted putting recordings of the lessons online. It’s not the right format: the explanations and pauses are tailored to a specific audience. Also, if the participants know they’re being recorded, they are much less likely to ask questions.

In 2020, we can no longer meet physically, so everything is now recorded. And since questions are mostly asked in text and there’s no need to make the videos private, I began streaming the lessons on YouTube. There’s still interaction with the audience, so I don’t think they’re good video lessons on their own, but they do get more views than participants. My goal is to improve the learning materials, which everyone else can then use to learn or teach from. The live class is the better way to test the current iteration on live people and gather feedback.

I think such testing could apply to any set of instructions. Next time you write a tutorial for a piece of technology, consider finding people from your audience and doing a community workshop or course to test it out. Chances are, you’ll learn a lot about how people understand whatever you’re trying to explain.

Or you might find a great way to help a community grow.


  1. Since then, the university has introduced a Python programming course for people not studying computer science, which, as I’ve heard, fixed the issues that got me started teaching. Thanks to Masaryk University in Brno, both for making that mistake and for fixing it!

SHARE THIS ARTICLE

More like this