Training at EuroPython 2014 Making your first contribution to OpenStack

OpenStack logo

Last week I ran a 3-hour training on how to get started contributing to OpenStack at EuroPython. The aim was to give a high-level overview of how the contribution process works in the project and guide people through making their first contribution, from account creation to submitting a patch.


The session starts with an extremely fast overview of OpenStack, geared toward giving the participants an idea of the different components and possible areas for contribution. We then go through creating the accounts, why they're all needed, and how to work with DevStack for the people who have installed it. From there we finally start talking about the contribution process itself, some general points on open-source and OpenStack culture then go through a number of ideas for small tasks suitable for a first contribution. After that it's down to the participants to work on something and prepare a patch. Some people chose to file and triage/confirm bugs. The last part is about making sure the patch matches the community standards, submitting it, and talking about what happens next both to the patch and to the participant as a new member of the community.


During the weeks preceding the event, I ran two pilot workshops with small groups (less than 10 people) in my local hackerspace, in preparation for the big one in Berlin. That was absolutely invaluable in terms of making the material more understandable and refining the content for items I didn't think of covering initially (e.g. screen, openrc files) and topics that could use more in-depth explanations (e.g. how to find your first task), timings, and generally getting a feel for what's reasonably achievable within a 3-hour intro workshop.


I think it went well, despite some issues at the beginning due to lack of Internet connectivity (always a problem during hands-on workshops!). About 70 people had signed up to attend (a.k.a. about 7 times too many), thankfully other members of the OpenStack community stepped up and offered their help as mentors - thanks again everyone! In the end, about half the participants showed up in the morning, and we lost another dozen to the Internet woes. The people who stayed were mostly enthusiastic and seemed happy with the experience. According to the session etherpad, at least 5 new contributors uploaded a first patch :) Three are merged so far.

Distributing the slides early proved popular and useful. For an interactive workshop with lots of links and references it's really helpful for people to go back on something they missed or want to check again.


The start of the workshop is a bit lecture-heavy and could be titled "Things I Desperately Wish I Knew When Starting Out," and although there's some quizzes/discussions/demoing I'd love to make it more interactive in the future.

The information requested in order to join the Foundation tends to surprise people, I think because people come at it from the perspective of "I want to submit a patch" rather than "I am preparing to join a Foundation." At the hackerspace sessions in particular (maybe because it was easier to have candid discussions in such a small group), people weren't impressed with being forced to state an affiliation. The lack of obvious answer for volunteers gave the impression that the project cares more about contributions from companies. "Tog" might make an appearance in the company stats in the future :-)

On the sign-up form, the "Statement of Interest" is intimidating and confusing for some people (I certainly remember being uncertain over mine and what was appropriate, back when I was new and joining the Foundation was optional!). I worked around this after the initial session by offering suggestions/tips for both these fields, and spoke a bit more about their purpose.

A few people suggested I simply tell people to sign up for all these accounts in advance so there's more time during the workshop to work on the contribution itself. It's an option, though a number of people still hit non-obvious issues with Gerrit that are difficult to debug (some we opened bugs for, others we added to the etherpad). During one of the pilot sessions at the hackerspace, 6 of the 7 participants had errors when running git review -s  - I'm still not sure why, as it Worked On My Machine (tm) just fine at the same time.

Overall, I'm glad I did this! It was interesting to extract all this information from my brain, wiki pages and docs and attempt to make it as consumable as possible. It's really exciting when people come back later to say they've made a contribution and that the session helped to make the process less scary and more comprehensible. Thanks to all the participants who took the time to offer feedback as well! I hope I can continue to improve on this.

Leave a comment

Train the Trainer course FETAC Level 6

Last week I participated in a 3 day-long "Train the Trainer" course at Hibernian College in Dublin. My goals were to get a better understanding of how to teach to adults and learn how to design and deliver effective training sessions, in order to improve my technical courses and workshops, and teach better. It's something I had wanted to do for a couple of years and I'm glad I finally jumped and did it! I found the course both very enjoyable and very useful.

Choosing the course

Originally I was waiting for Engineers Ireland to put their 5-day "Train the Trainer" course back on their CPD calendar but after contacting them, it turns out they are not planning on running it again in the short term.

Trawling the interwebs, there are a lot of training providers out there and it can be difficult to figure out which ones are legit (perhaps I was lucky!). I decided to go with a FETAC approved course even though I don't truly need the certification at this stage, because I figured if a course is approved to offer a government backed certification it'll be somewhat serious. After that, it was down to the luck of SEO and how helpful people were when I requested information. The Hibernian folks answered all my questions promptly and are lovely to deal with, both by email and face-to-face.

The course

The advantage of a 3-day course is that you don't need to take so much time off work. The disadvantage is that it is pretty intense! I would recommend having a couple of hours available in the evening for homework, particularly on day 2. The course I did was instructed by Maura O'Toole, who also happens to have some background in computing from early in her career which made for a few funny stories. Otherwise as a professional trainer with a couple decades of experience, she had a lot of anecdotes to illustrate her content and advice and make them memorable. I also liked that although we did go through all the FETAC material, she made sure to contrast it with how the real world works whenever relevant, based on her own knowledge and experience.

It must be a somewhat stressful course to teach because as you explain how to do things, people are analysing what you're doing and checking how it matches against what you are saying - and will call you out on any discrepancy!

The first day is the most intense, I think, which is probably just as well since people come in full of energy and expectations. I learnt a ton right from the icebreaker and icebreaker analysis - not only about training in general but also things I specifically want to try in my next course. That got me enthused for the day! By day 3 it was more difficult to keep the energy levels very high, despite the interest still being there.

The class size is kept small, which is actually a FETAC requirement (max 8 people) and makes for a nice environment, particularly as people need to get up and present quite regularly. The participants' backgrounds were quite varied and we all heard presentations about horticulture, clinical trials, powerboat exams, TV production, programming...


The assessment is in two parts: a "skills demonstration" video where you spend 10 minutes - exactly 10 minutes - showing off your mad training/presentation skills, and a ~2600 words written assignment showing how you would prepare, design and deliver (or have already) a particular training session, to return within 4 weeks of completing the course. You need a pass mark (40%) in each component to get the certificate.

The requirements for the video are such that it contradicts a lot of what is learnt during the course. You shouldn't really be interacting with your students on the video (it's about showing your skills) - and it would probably be quite fake anyway. It's important to stick closely to the time. It was strange to pretend to teach programming with slides.

I still did my best though, I couldn't help wanting to try and plant the idea of maybe learning programming, in the head of my fellow trainees :-) They kindly indulged me. No one was particularly fond of the camera and the atmosphere was really supportive during the day, no matter the number of retakes.

According to the instructor, we all passed the skills demonstration (yay!), although the videos still need to go to the external FETAC examiner to confirm the final grades.

It was strange for me to go from nothing to doing a graded presentation on camera within 3 days. I'm used to preparing and rehearsing and rererererehearsing a lot more than that. It's probably good to just get it out of the way quickly, though perfectionists who want to shoot for the highest grades (ahem) will find it weird. I thought it was good.

Material-wise I was able to reuse content from my previous courses so that was one less concern in terms of preparation, I only had to adapt a little. People who never taught or trained before maybe have a bit of a rougher time (then again if they're deeply knowledgeable on a topic, maybe not). Likewise if you're not comfortable with public speaking (as in, at the level of standing up and introducing yourself/talking shite with a handful of supportive people in the room, without having a panic attack) I would carefully consider whether to attend such a fast-paced course.

A few things I learnt

It's comforting when best practices are described and this happens to match how I've been doing things :-) (For instance my way of doing training evaluation is probably not too crap).

It dawned on me at some point during day 2 that what I was trying to fix - the ways my sessions are designed - is not my main problem. My main issue is that the objectives for my courses are not defined clearly - I kinda try to fit as much as I can without overwhelming within the time I have available. Working from the results I want (using the useful "Training Analysis Framework" I now possess!) would allow me to clarify exactly what I want to achieve, which will then help me organise and (re)arrange my sessions as needed, rather than follow the chronological order. As a very important bonus point, it will help me write course descriptions that are more specific and should help "weed out" the people that the course is not designed for (i.e. non-beginners). I am really happy about this, this is a big problem each time.

I also learnt what I thought was my "happy smiley presentation face" is actually "my serious face." Must calibrate better! :-)

There'll be a lot more once I got through my notes again, but the fact that I was trying to fix the wrong thing was a huge revelation and I'm really happy I figured this out. Sadly I got sick right after the course (better than being sick for the filming, I guess!) and I haven't had a chance to sort out the rest of my notes - or, er, start on the assignment.


I have a couple of weeks to complete the assessment. Hopefully I can get a big chunk of it done over the week-end, once the cold is gone. From what I understand, it is quite time-consuming and the instructor suggested doing it for a course we're actually planning on teaching so that the output is useful and usable, rather than a simple academic exercise. I plan to use my intro to programming course for this, except on a different timeline (I'll imagine it's taught over a couple of days rather than in the evening - and who knows, if I'm inspired I might just go and try teaching it in that format too!)

After that, I want to schedule the course and teach again in Tog. I "paused" teaching because I felt my course wasn't good enough and I wanted to overhaul it first. As with many "let's redo it from scratch!" projects, it's just meant I haven't taught in over a year now... So, time to fix this, and as I refamiliarise myself with the course first time around, the only major change I'll make will be to update the examples to Python 3. It's time!

Updated in May to add: I passed! :) Let's go and teach all the things!

Leave a comment

Teaching Webcraft / Audience Who are your learners?

The second task for the Teaching webcraft course is about making up profiles for people we're hoping to help. The couple of biographies that follow do not cover it all, but should still be a fair sample :-)

* * *

Jessie is a high school student, and although she thinks about it often, what she wants to do after her final year still very much depends on what catches her interest the most any given week. She navigates the web effortlessly, and hangs out online in all the social networks her friends are into. She never really considered programming as something she could learn, but when presented with the opportunity to join an intro course she thinks maybe there she'll learn enough code to be able to personalise her blog, and make it look unique and more interactive.

This course will teach Jessie how to create her first program, and that programming is more similar to puzzle solving than inputting number in Excel to do sums like in the ICT class. Perhaps something worth exploring further...


Jon is working hard at his PhD thesis in social sciences. He has a lot of statistics to parse and go through every day, results of experiments to reproduce before building on them and so on. He has a dozen of Excel spreadsheets set up with insane macros that save him a lot of time, but still wastes many hours manually inputting data taken from websites or articles. He's hoping learning to program will enable him to spend less time on drudge work and more time exploring the interesting questions.

This course will teach Jon how to automate more of his experimental work, and in the process make him realise there are other areas where some scripting would make writing his dissertation more efficient.


Paula doesn't consider herself a power user, but she knows the keyboard shortcuts for every application she uses, is familiar with the file system layout of her computer (and learnt what a file system is) thanks to a couple of misadventures clicking on interesting looking icons, and is known to her friends and colleagues as the go-to person whenever a computer misbehaves. Though she doesn't plan on making a career out of it, she is curious to gain an understanding of what's under the hood of all these applications she uses.

This course will teach Paula the fundamental steps and "bricks" that every program is made of, and help her understand why bugs happen and what makes them difficult to eradicate. Maybe putting together a short script to randomly assign secret Santas for the next Christ Kindle wouldn't be too hard, though...

Leave a comment

Teaching Webcraft / Compare your practices to IES report's recommendations

I'm taking an online course at the P2P University, on "How to teach webcraft and programming to free-range students" taught by Greg Wilson.

Looking at the initial comments on the course it's possible I misunderstood what "free-range students" means ; from the course description I took it to mean teaching in various non-traditional settings, but it might actually be specifically about online learning (?). It's fine, the general concepts of "what is good teaching", "how people learn" and how to encourage independent learning will be helpful anyway. :)

First task

Our first task is to take a look at the IES (Institution of Educational Sciences) report on "Organizing Instruction and Study to Improve Student Learning" (summarised in Greg's post here) and compare their recommendations to our own approach to teaching programming.

For the record, I teach sporadically in my own time, to small groups of 6 to 10 complete beginners, usually-but-not-always adults, in the local hackerspace.

Recommendation 1: Space learning over time.

Arrange to review key elements of course content after a delay of several weeks to several months after initial presentation.

In a 5 or 6 weeks-long course, this can be difficult. However, most concepts do build on top on each other: once learnt, they will be used every week from then on. The later concepts could benefit from regular review, but by then the course is about finished unfortunately.

Recommendation 2: Interleave worked example solutions with problem-solving exercises.

Have students alternate between reading already worked solutions and trying to solve problems on their own.

From the 2nd session of the course, I start by showing a short, working program to the class and ask them to think about what it could be doing, (trying to) figure out as a group what could be its purpose. This sounds more like review though, as it reuses the previous concepts. The report also reads that alternating working examples + exercises is hugely important. "Worked example solutions" should go into much more details than what I've been doing as well (showing intermediate steps, rather than only the final solution).

Recommendation 3: Combine graphics with verbal descriptions.

Combine graphical presentations (e.g., graphs, figures) that illustrate key processes and procedures with verbal descriptions.

I can't say that I'm really doing this. I'm projecting code, sometimes working out solutions in front of the class but this isn't particularly graphical. I'm not sure how to do this either. It actually reminds me of the approach to learning that Sean O'Leary mentioned in his talk on differentiated learning at the Reimagining Learning conference, where he told us about adding visual cues to quizzes and concepts to help dyslexic learners and students with a more visual approach. Although useful, this doesn't exactly match the IES report recommendation which advocates making sure the graphical element is directly relevant to the concept being taught.

Recommendation 4: Connect and integrate abstract and concrete representations of concepts.

Connect and integrate abstract representations of a concept with concrete representations of the same concept.

The report explains that students gain an understanding faster when using concrete examples, but then don't know how to transfer the knowledge to new problems ; while students who learn the concept abstractly struggle more initially but are then more flexible with the knowledge. The report advocates mixing up both, which I'm not doing or not doing well as my students tend to have trouble reusing previous concepts to break down more intricate problems on their own.

Recommendation 5: Use quizzing to promote learning.

Use quizzing with active retrieval of information at all phases of the learning process to exploit the ability of retrieval directly to facilitate long-lasting memory traces.

5a. Use pre-questions to introduce a new topic. I don't do this. I wonder if "previewing" an unknown programming concept would help learning, or increase confusion. It'd definitely need to solve a concrete problem, ideally that we encountered in the previous session.

5b. Use quizzes to re-expose students to key content. I don't do this either. (Actually, reading on the report, presenting small programs and asking students to figure out what it does may be considered a quiz, as it encourages them to retrieve previously learnt material). It's interesting, and I wonder how to apply it to teaching practical programming while keeping the questions short and meaningful (maybe tiny programs with missing bits, with a multiple choice as to what to fill the blank with?)

Recommendation 6: Help students allocate study time efficiently.

Assist students in identifying what material they know well, and what needs further study, by teaching children how to judge what they have learned.

6a. Teach students how to use delayed judgements of learning to identify content that needs further study. I'm not doing this, except perhaps brutally when giving exercises that a student doesn't know how to solve.

6b. Use tests and quizzes to identify content that needs to be learned. This advises giving a quiz, written or oral, could be done as a game, right after presenting new material, so students can assess what they actually do remember. I don't do this. Considering most of my students don't make the time for homework or studying at home, I don't know if this would be very effective on its own. Or perhaps it would highlight that they do need to study outside of the class and encourage them to do so...

Recommendation 7: Ask deep explanatory questions.

Use instructional prompts that encourage students to pose and answer “deep-level” questions on course material. These questions enable students to respond with explanations and supports deep understanding of taught material.

I do a tiny bit of this when I introduce a new concept or explain what an existing program does, but not very deeply, nor involving the class enough (it can be tough generating discussion!). Some of the suggestions include having students think aloud, then comment and build on each other's understanding.

Leave a comment

Teaching programming to beginners Latest roundup

An overdue post on the latest course I taught, which ended about 2 weeks ago. I taught a group of 9 people (8 adults, 1 teenager) of various backgrounds the basics of programming, using Python. It went well overall, and the class atmosphere was enjoyable.


Unfortunately I still fail to explain some concepts clearly -- namely the dreaded for loop. I kept telling myself I needed to change the way I introduce it and finally did so, and wow. It went even worse than before. I could see in my student's eyes how they were trying to understand, until eventually shrugging it off when I couldn't find any different way to explain it. It may have come across a bit better eventually when we started working with files and used for loops to go through every line, but introducing the concept went very blergh. Definitely need to do it differently next time. I think I will try to introduce the for loop over 2 sessions: one where we only see and do exercises related to "for i in range(0, x)" and separately introduce "for item in my_list".

I don't know if I just forgot before, but failing to get a concept across is really, really depressing. I was bummed out for a while afterwards, wondering if I'm just making more damage than good and messing up my goal of making programming less intimidating.

...Yet another reason to do better next time!


I should make sure to have at least one "Fill in the blanks" and "Change this existing program so that..." type of exercises for every concept. I think they encourage students to read and try to understand existing code -- an important skill to develop, and it also makes the first attempt at using a new structure more manageable.

In general, I'd really like if I could find a neat program that could be cut down into exercises relating to each concept, that'd build up to something cool and awesome as the course goes on. It would help get across that complex programs are really made up of simpler pieces ; if you can't figure out how to do something, break it down further. I haven't really figured out a program that fits the bill yet.

Overall, material-wise I'm getting there (except for For :|), it'd be worthwhile focusing on improving the exercises for the next course.


OMG some people actually did the exercises as homework this time :O Wow. I tip my hat to them, it's great and it paid dividends for them. Unfortunately it also meant they had nothing to do while the others were catching up, so... I should probably give away only a portion of the exercises as homework, and save a few for the actual session. (The idea with the exercises is that everybody should get at least 1 done before we move on ; having many gives the faster students something to do while others don't feel too rushed.)


I taught over 5 weeks this time (2h30 in the evening with a 20-30mins break), and I will do 6 weeks next time. For real beginners it's still reasonable and it will let me take more time on concepts like For, and maybe an opportunity to show at the end what else there is to programming, and give ideas on which direction they could go on from here (GUIs, web development, robots...).

Speaking of robots

At the last session I brought a Finch, which I still haven't had much time to play with :') But with the Jython bindings it was possible to show a 5 lines Python program that has an effect in the real world. The Finch was very popular!

I want to play with the robot more, and see if perhaps it would make sense to use it to teach the whole beginner course at some point in the future (which would bring its own set of issues, $$$-wise).

Student feedback

As usual I asked if students could fill in a feedback form.

Everybody agreed they learnt a lot. "Fun" and "interesting" were in about everyone's "3 words to describe the course", with"hard" and "challenging" occasionally thrown in there :) "Useful" came up in half the forms too, which makes me happy.

The projector wasn't great with yellow which unfortunately was the default colour for strings in the IDE. It would have been worthwhile spending the time on fixing that rather than let people squint (sorry :().

A couple of requests to link more clearly exercises with the real world. So very difficult when we're still introducing new concepts! But definitely something to strive for.

Someone suggested writing a sample program where every line is explained (e.g. if x:    <-- this will do...). I think it's a good idea, I will try for next time. It would be useful as a reference.

I should be teaching this course again around March. Any pointers to beginner exercises, general comments, teaching advice, teaching programming tips all very much welcome!

Leave a comment | 5 so far

Teaching, take 4

As mentioned before, I'm teaching programming again, to a group of beginners :) (Although as usual, even in a group of complete beginners there are variations in people's levels and comfort with the subject.)

Initial advertising

I'm really happy with how the PR worked out this time. The first time I taught this course in Tog, I made the mistake of putting "Python" in the name of the course and ended up wasting a lot of time screening out people who wouldn't be a good fit. This time I only mentioned it in passing, and the amount and type of answers I got was much more manageable and appropriate. We still managed to fill up the course and to have a waiting list (hope to see you next time!), so it's a success. I'm pasting the announcement here for future reference:

Class: Introduction to Programming

Are you curious about programming? Ever wished you could write your own scripts to automate repetitive tasks, or for fun? Or been interested in understanding how an application works (and why there are always bugs in the software you use??). Tog is running a new class on learning how to program, for complete beginners with no previous programming knowledge.

The course will cover basic programming skills, which will also give you a better understanding of how computers work. We will be using Python, an excellent learning language because it is simple yet powerful, and extremely readable. At the end of the course you will know how to write simple programs, and you should have enough understanding of the basics to move on to either more complex programming tasks in Python or learn another language if you wish to.

The course will begin on October 20th and will run for 5 weeks every Thursday from 7.00pm to 9.30pm. The cost is €40 for non-members, and free for members. The class size is limited to about 8 people, for a relaxed atmosphere conducive to learning.

If you are interested in attending, or have any question about the course, please use the form below or leave a comment — we’re happy to answer any query! You must sign up if you want to attend, space is limited.

Please note that this is a course for complete beginners, who are not yet familiar with the usual syntax for programming. If you’re a programmer interested in picking up Python, you should keep an eye out for our crash courses!

A fair percentage of the students heard about the course from Twitter even though I'm not on it, which is interesting. I should explore how to use the tool better. As I mostly hang out with fellow nerds, reaching out to interested beginners is always tough, so anything that can help...


The pace of the course is manageable as well -- which doesn't mean preparing and teaching isn't time-consuming still! But I felt quite burnt out last time after the pace at which I taught the PhD students (mostly through my own fault), so it's refreshing to come back to teaching pure beginners and not go crazy from week 2.

Surprisingly enough and to my utter delight, a huge portion of the students took on the exercises as homework! I'm so happy when I get questions about the exercises or lessons via email, to see people interested enough to poke at problems outside of the classroom. If we keep it up we should be able to cover more as well, which will be interesting for everyone.

As for feedback, I found a couple of positive tweets after the first session, which is always encouraging. Woohoo \o/

Leave a comment

Teaching again

Curious about programming? Ever wished you could write your own scripts to automate repetitive tasks, or for fun? Or been interested in understanding how an application works (and why there are always bugs in the software you use??). I'm teaching a new class in Tog on learning how to program, for complete beginners with no previous programming knowledge. We'll be using Python, and you can find more information including how to register over at Tog's website: Class - Introduction to Programming.

Leave a comment

Reimaging Learning Conference

Last week-end I attended the Re-imagining Learning conference in Limerick, a conference by the Educate Together folks aiming to rethink early secondary school.

As expected the majority of the talks were very interesting and/or inspiring. The way the schedule seemed to work, keynotes were meant to be higher level and make the audience think and ponder and imagine, while the sessions in between were more practical, sharing information on past or current initiatives by education professionals.

Attending a conference outside of my field was an interesting experience, although I found it awkward to introduce myself. I thought afterwards I should have simply left it to "I'm interested" rather than trying to justify my presence, but thinking again I'm not quite sure it really explains what the hell I'm doing here. Ah well. I can figure it out as I participate in more of these events, I guess.

I took a ton of notes, however as I haven't been good in the past at transcribing talks, I'll start by posting a mishmash of thoughts, themes and ideas that I took home with me.

First and foremost, there is a lot happening in Ireland in education at the moment, including curriculum reform (recommendations) at the Junior level. It was inspiring to be surrounded by professionals in the field who obviously care so deeply about what is going on and how to improve the state of things.

The Friday morning keynotes looked at the early years of the Junior level, covering how these first few years have a major impact that will affect the attitude of the student toward school until the end of their schooling. "Curriculum integration" was a big theme over the two days and another speaker noted curriculum cannot be looked at independently, it is heavily dependent on the political context even if we like to pretend it is neutral.

John Portelli's keynote was very interesting, explaining the importance of a critical-democratic framework and the dangers of pre-judging. He touched on a lot of themes and it was incredibly frustrating to see him having to rush through the ideas he was introducing. Although the conference was very professionally organised, time-keeping was terrible from the beginning and it put a lot of undue pressure on speakers who felt they had to fly through their material.

Some practical tips I picked up during some of the sessions:

  • In Sean O'Leary's talk on science differentiation, he mentioned simple ways to make material more accessible, for instance language level readability. He showed examples of a science exercise, and how to rewrite it so that it means the exact same thing, the problem is framed the same, however the language is simpler which removes a potential barrier. That's something I absolutely want to look into, because I know I am guilty of it, as I tend to switch to smartass academic language whenever I write an exercise sheet that I know I will be handing out. He also uses visual cues as often as possible to help with memory (rebus). To dos:
    • Find a site or software to assess the readability level of the material I write.
    • Check out the Science Differentiation Pack the speaker worked on and see what I can use in there
  • Neil Bulter showed us all sorts of games he used in class to encourage students to develop their problem solving skills. See notably Fantastic Contraptions, Gravity Pods, and Light bot. To dos:
    • This last one I must check out properly and see if it can help newcomers come to term with how programming works

Some general ideas that stick to mind:

  • Like everyone teenagers want to know more about themselves, understand who they are and what is their place in the world. By teaching them about development theories they can learn to make better decisions. Development theories include multiple intelligences, etc.
  • Teaching in groups is excellent and the ideal way to do things, however the teacher needs to help/teach/promote higher level thinking and discussions, to move it beyond disputes (e.g. partner phrases)
  • I didn't know the Irish Computer Society was so involved with school and education! They train schools in using technology to engage with students. And they even have an awesome Scratch handbook! To dos:
    • Get the handbook
    • Find out more!
  • Many times speakers put forward the idea of having the teacher stand back and act more as a facilitator and guide. For instance, community-based learning (Martin Galvin), that encourages young people to look into a problem in their community (e.g. nutrition based health problems) and learn about it in a self-driven way and through community service. Giving an ill-structured problem (a very general question) that has no clear-cut answer, and let students run with it! See also the Global Learning Initiative Project (Lori Holcom) that hooks up students with other students from schools around the world.

Some books/articles I want to look into:

  • The Passionate Teacher, 1995
  • Something to learn more about teacher follow-up moves, by Brodie (2008). This was mentioned as part of the talk on "fostering a 'conjecturing atmosphere' in mathematics lessons" (Therese Dooley).

Of course the conference covered all these topics (and more!) in much more details and I have a lot of things to think about, think through and hopefully use to better my own beginner-teaching and make it more relevant.

Additionally, I met with Paddy, a retired school principal from Cork, who was kind enough to give me some advice on how to find a school near where I live and who to talk with to see about teaching programming to high school students. A big to-do!

Leave a comment

Python Office Hours 1st edition, roundup

Last Thursday was my first attempt at setting up "Python Office Hours", an evening during which people starting out with Python are welcome to drop in with questions, problems or just to work on beginner projects with someone who can give a hand within reach.

It probably wasn't a success, though it definitely wasn't a disaster. I only sent out the announcement to my former students, and several people were really excited about the idea though only one confirmed he would come. And indeed, although my opt-in "Python Office Hours" list now has a few more names in it, on Thursday there was only me and the one student, so not quite the successful evening turnout-wise. However, we had a very long discussion about the project he wants to do, how to go about cutting down the design into different Python projects manageable for a newcomer to the language, to a level that we wouldn't have been able to discuss had there been other students around. So this wasn't a wasted evening, although we probably went into more depth than I was thinking or hoping for! That's the advantage of showing up, you can get more than you bargained for :)

I will do a few more of these office hours. I think maybe people will get moving in their projects and/or learning if they know it's a regular occurrence. I'll likely expand the reach too, though I'm a bit concerned people will misread and show up expecting more (or any kind of) structure -- as I discovered a couple of courses ago, people read an email and focus on one keyword at the expense of what the actual course or event is about! Everyone ends up disappointed and frustrated, so I'll make sure to pen that email carefully, and work at learning which words to bold for maximum effect :]

Leave a comment | 4 so far

Python Office Hours Trying something different

Python logo

I've decided to try something different and will be holding Python "office hours" in Tog on Thursday evening. It's not really a secret but I'm not exactly advertising it either. I sent an email to my former students for Thursday's test run, and depending on how it goes I may hold these regularly and be more vocal about it.

What is it going to be about? This is sort of a follow-up to an intro course, for people who have a project but can still get stuck and could use some guidance. Or for people who want to reinforce  their knowledge of Python/get up to speed by doing exercises, with someone nearby to give a hand if needed. Basically it's for people who want to do their own thing, with the knowledge that if things don't work there's someone who should be able to help in the room, rather than hours of frustration in sight. Or that's the idea! This isn't a course, I won't be teaching or lecturing or erm talking that much. If no one needs help I'll be working on my own stuff.

I look forward to seeing how it goes. Drop by Tog ( map ) anytime between 6.30 and 9pm this Thursday if you're interested! And feel free to drop me a note (see About page) if you're curious but not sure if it's a good fit for you.

Leave a comment

Course content, now CC-BY-NC

I added a notice to my previous courses notes to indicate that they are now available under the CC-BY-NC license. I don't know if it'll be in any way useful -- as I'm well aware the courses could use a huge amount of improvement (working on it!) -- but it seems worth doing.

Note to interested parties: If you're only looking for exercises to use in your own courses, don't worry about the license and just grab them. I would only humbly request, that you feel very free to also share back any exercise or resources you found useful to teach the basics -- I always struggle to find more! :-) Add a comment or contact me directly.

Leave a comment

Teaching conclusions

My last course to teach Python to beginners ended Monday last week and wow, am I behind in writing up the post-mortem :)

This time I taught the basics of programming with Python to a group of 6 adults, mostly PhD students either in political sciences or mechanical engineering. Nearly all of them had used some statistical/domain-specific language before, such as R or Matlab, which had a greater impact on the course than I anticipated. I taught in the students' University and thus was able to donate all the proceeds to Python Ireland, woohoo! To an awesome PyCon Ireland conference this October!

Progress isn't linear

The first and most important lesson, for me, was that progress isn't a linear thing and I really let the first session influence the pace too much. On the first day, we went through the material in a blink and I found myself short on exercises and concerned about the amount of new content that would be required for the rest of the course.

However, this day 1 effect happened because people were already familiar with the basics of programming, and they had no problem mapping what they knew to Python. I didn't realise this though, and stepped on the gas from that point on, failing to adjust properly until several weeks later. It was brought to my attention later on that actually students could have used more time and depth to understand several new concepts (that's where it helps to have a friend as part of your students, they'll mention it even if in passing!)

Which reminds me: note to self, completely redo the way you introduce for loops.

Initially, I was also a bit disappointed because I enjoy guiding students through the ah-ha! moments of figuring out programming and it felt like people already knew everything. I was wrong here as well, there may not have been any in the first session but there were plenty of satisfying ah-ha moments as we went on with the course.


As usual, I started crashing toward the end of the course ; preparing and refining material and exercises always takes a ton of personal time and when the course ended I was much looking forward to having time again to work on my own projects (...till the next course, as usual! I never learn ;))

Preparations are really the most time- and mind-consuming aspect of teaching. Even for the existing material, there's always a bit of work to try and adapt the exercises to topics that might interest current students or make lessons flow better. With the pace we were going at, I didn't have everything ready beforehand either. On the minus side, this costs time and means the lessons can be less polished. On the plus side, it usually means the lessons are better suited to the level and interests of the class.

Student feedback

This is probably another reason why it took a bit of time to sit down and write this all up. Overall, on the scale of happiness and knowledge the students appear satisfied with the course. Some comments on how to improve the course somewhat confused me. I think once again some felt I was guiding too much. However this time I'm really happy with how we learnt to use and navigate the Python documentation and I think that's the best thing I can teach for students to become independent. At that beginner level, I'm afraid I'm not sure what more to do unless I'm offered specific suggestions. There was another piece of feedback about still not being sure where to start if wanting to create a new program. Something I'd like to experiment with in the future is to start by giving a big project at the beginning of a course, and then along the weeks with various exercises we start solving it bit by bit, and hopefully that would give students a fairer idea on how to break down problems into manageable tasks. I need to think about it.

Some of the feedback wondered about the point of some of the exercises, which is very valid criticism. When I create a new lesson and associated batch of exercises, the ratio of suck tends to be high. It's quite difficult to find small self-contained exercises, that touch only on the necessary specific concepts without going all over the place! I need to hunt for more.

Overall I'm happy with how it went and will of course teach again in the future. I'm disappointed with the way I presented the material at times though. I think I need to do more public speaking and general talks, to stop letting myself become intimidated when I speak for a while and no one's looking my way or interested (or awake!)... as opposed to the pleasant interactions of helping students debug their programs. Maybe a lightning talk on teaching programming? ;)

Update: Oh, and I forgot to mention I received homework this time! This is so cool. It came from students who had a project on the side they wanted to solve with Python. Hope I helped :)

Leave a comment | 4 so far

Book review: How to survive your first year in teaching, by Sue Cowley

I got "How to survive your first year in teaching" after finding some very positive reviews and it's been worth every cent -- from the beginning I had to stop reading to take notes and add bookmarks for future reference. The target is "real" teachers (at the primary and secondary level) who are preparing for the first year of teaching on their own after their training.

At my level (volunteer unqualified teacher), I found the book tips very good to help structure both a course and specific lessons. There are many activity ideas to try out in class and suggestions to avoid sticking only to one teaching style (e.g. lecturing) -- it doesn't matter what age group you're teaching, there will be something useful and I've already been applying some of them. I'll be re-reading the behaviour and class management chapters when I teach high school students again (having a clue what to do will hopefully help in these situations!)

For non-professional teachers like me, there are a number of chapters that don't apply, like class decoration or school administrative tasks. I still found them interesting on my first read-through though I'll likely skip them on subsequent reads (and I learnt a bit about the UK school system... for instance I thought "houses" only existed in the Harry Potter world :-)).

The kind of sections I bookmarked: activities to try in class, balanced lesson planning, setting aims and objectives, differentiation, resources to spice up lessons, assessing and marking (great to understand the types of feedback you can offer), grading and writing reports (feedback to students once again). I was pleased to read the section on differentiation and find that I had figured out a lot of it on my own, though I could definitely improve on differentiating for weaker students. Might need some additional resources on the topic. Anyone has recommendations to offer?

Leave a comment

Teaching, teaching Session #2

I thought before I started this course, "oh, it's the third time I do this, it's all old hat, I'll just have a general recap blog post rather than weekly ones" but heh, as long as I keep learning and questions and topics to ponder come up, I'll keep writing them down if only for future reference.

I worked hard to have an interesting session with plenty of content this week. I mixed and mashed and added and transformed what usually takes 4-5 hours into an intense 2 hours session. It was worth it, I think it was a good pace for this class and the experience was rewarding.

It was really hard work though. It took such a long time to prepare that I'm not quite sure I can scale it, especially now that I need to create new material (and I'll be travelling the last 2 week-ends of the course). I'll see what I can come up with to keep things interesting without burning out on preparations -- all suggestions very welcome!

In parallel I've been reading an incredibly helpful book on teaching, and am using its tips and advice to structure my lessons better. I'm also figuring out things that are more specific to teaching programming ; for instance, having a code reading question when it's time to stop the exercises seems good at making students actually stop what they're doing and pay attention to the front of the class, rather than their screen. Then it's easier to move on to explaining a new concept.

Leave a comment | 2 so far

A few notes from the first session Teaching again

Post-session #1 thoughts (from Monday's scribbles):

  • Note to self: Re-read carefully the lesson's content beforehand, to remember it all. Knowing what's "print" and what's a variable like the back of your hand doesn't mean you remember how to explain them to someone encountering the concepts for the first time. Very embarrassing, I never want to introduce any concept like this again.
  • PhD students are SMART.
  • It's a shockingly different experience than what I'm used to. People read things once and Just Get It (TM). Unfortunately they also call to me less and so I don't have a chance to see their progress and correct mistakes, share tips, point out inefficiencies or just help in general. I'm making plans to try to mitigate this.
  • Overall I will have to work very hard to keep things interesting. It's both exhilarating and super scary.
Leave a comment | 2 so far