Category: OCRI

How Mentoring Works

Welcome back to this semester’s OCRI updates. Back in October, we looked at how to kick off a project. Today we’ll talk about learning programming.

Last Monday I visited All Saints High School here in Ottawa. The students there are creating Flash-based games for a class of grade 3 students at a neighbouring grade school.

The neat thing about this particular class is that it’s not a programming course — it’s a course in multimedia. The advantage this brings is that the students are familiar with the ins and outs of design and publishing; this will give us a chance to put some real polish on the finished products. The obvious disadvantage is that most of the students have very little programming experience. This is backwards from usual, and I’m curious to see how it turns out.

We teach in a one-on-one sort of setting.

It’s not usually very effective for myself or the other mentors to lecture the students on how to program. They have a teacher for that, and if we do it too then the students are more likely to lose their enthusiasm and less likely stay engaged and focused. Plus, there are a few advantages to a one-on-one coaching approach:

1. I can easily and reliably gauge how much each individual student knows about programming. This helps me decide how much of my attention each group will require.
2. I can customize what I teach each group. Since the students’ games and programming backgrounds are all different, each group will have a unique set of needs.
3. I can connect better with each student. This is more rewarding for me and for them, and it makes it easier for the students to accept my help.

Since this was my first session at the school this semester (I missed Day 1), I spent most of my time floating around to each group to see what their game was about. What immediately surprised me was how far along all of the groups were. Normally we use Java, which has a much steeper learning curve, but Flash is easy to pick up, especially for students already familiar with tools like Photoshop.

The other big surprise was how much I learned. While I’m an (Adobe-certified) expert in Actionscript, I’m used to dealing with Flash Builder (the IDE), not Flash Professional (the animation tool). So while I was explaining how and why to define a constant, the students were teaching me how to tween a movie clip.

It will be interesting to see how the next few sessions pan out.

Over the next few weeks, we’re going to be moving away from the design aspects of the games and more towards scripting. Some games will require more of a back-end than others, and especially in those groups whose games are particularly script-heavy, it will be interesting to watch the students adjust from designing to coding.

I suspect I’ll have a fun programming story or two for our next update. Stay tuned!

The Value of a Project Kick-off

Welcome to the first in a series of posts about the work I’m doing this semester with OCRI. I’ll have an update like this every two weeks until the end of January, usually on Fridays (this one is a day late).

Every year, before we go into the classrooms to help students learn how to write working software, we have a big, group kick-off. The invite list is all-encompassing:

• All the students from the class of each school we’re working with.
• The teachers of the classes involved, and occasionally the schools’ principals.
• All our industry mentors (that’s me).
• Various representatives from OCRI (project coordinators).
• Some of the program sponsors’ representatives (like IBM’s Marcellus Mindel)

It’s a pretty diverse group.

There are a few introductions, and usually a speaker (Marcellus gave a fantastic talk this time around about innovation in technology), and then we all get to work on our task for the day. It isn’t brainstorming ideas or programming lessons, and in fact it has nothing to do with software development: we all get together and take apart a bunch of old computers.

If this seems odd to you, you’re not alone. It took me a few times to realize why this is a really, really important part of the kick-off, but at this point, I think I’ve got it figured out. Taking apart computers together builds a sense of community between the mentors and the students. Specifically, there are a few reasons why this works really well:

It gets the students into a co-operative mindset. Some students we get have done this many times before, but the majority have never seen the inside of a computer. Since we only have about a dozen computers, we set the students in groups of four or five, and they tackle it together. This allows the experts to show off how much they know, and the newbies to learn a few valuable skills. Of course, the mentors are running around helping each group and explaining neat things, so none of the groups are on their own.

It lets the mentors gauge the students. By the end of the day, I have a pretty good idea of which students will be enthusiastic about the program and which might need a bit more of a push. I know which students are good candidates for helping out their peers, and which ones might need that help. All of this will be useful over the coming weeks as we move on to developing software.

It lets the students gauge the mentors. By choosing a task that the mentors are good at, we can show the students that we’re both knowledgeable and helpful. Even the hot-shot kid that has been building computers since he was 10 can’t explain to me what a CMOS battery is for, so it shows them that they all still have something to learn. And the students who don’t know a hard drive from a CPU find out that we’re there specifically to demystify whatever they don’t understand. This builds rapport, and positions the mentors as experts, which will be important at that first programming session in a few weeks.

Most of all, the kick-off really is a fun time, and it gets everyone fired up for the start of the program. After all, isn’t that what a kick-off is for? I already can’t wait for our first visit to the classroom next week.