Activity idea: prediction

From EDEC-625 notebook, Fall 2015, 19 Oct 2015.

Setting up a prediction activity. This is a classic technique for Science classes, where labs and experimentation are part of the process. But it should work really well for Math and CS too, where the algorithm/formula/steps are complex enough that students have to do some mental gymnastics to go from seeing them on paper to knowing what they will do.

What to do:

  1. Activate the students’ prior knowledge, as needed.
  2. Show the setup of something new. Don’t execute it yet.
  3. Ask for predictions. Probe for understanding of the details of the setup and the underlying concepts at play. Discuss in small groups and/or large group, and record the students’ ideas visually as per usual technique.
  4. Execute the program/problem/algorithm, and confirm the results.
  5. Was the outcome understood? Which theory “won”?

Go through this cycle with a well-chosen case, and then do it again with new inputs–maybe once or twice more with inputs that you choose for specific reasons (they generate good illustrations, highlight edge cases or unintuitive results, etc.). Then repeat a few times with the students suggesting the inputs. Repeat until everyone is able to predict together how it will behave.

Allow students to give you crazy inputs. Don’t think too hard about what the result will be, and (unless it’s too crazy) don’t say “no” to a student’s suggestion. The idea is to (a) let go of the usual tight curricular control that we usually exercise, and (b) to help the students poke and prod the concepts you are illustrating.

The overall cycle is: Input > Predict > Execute > Discuss

Key objectives:

  • The teacher holds back his/her own knowledge of the outcome.
  • Teacher draws thinking out of the students, builds ideas before executing, gets them to reflect and understand after the execution.
  • Teacher embraces unknown, novel, or surprising results.
  • Teacher relinquishes control over inputs and problem design.

Activity idea: peer challenge

From notebook EDEC-625 Fall 2015, 19 Oct 2015.

Have students in groups. Each group creates a programming challenge for the next group to solve. They have to come up with something that’s within the class’s ability, using the blocks and techniques they’ve all learned up to that point. Ex:

  • Make the sprite draw _______.
  • Make the sprite do _______.
  • Animate a conversation about ____ with appropriate costumes.

Each group formulates a challenge and passes it to the group to their right. They receive a challenge coming from their left, and they have to carry it out.

The idea:

It’s great to solve a challenge… but it’s an even richer task to think up a challenge. You have to see through it, understand how a person might go about it, understand where the pitfalls are (or maybe intentionally place some). That’s good meta-cognition.

Kate and Kids Code Jeunesse on MAtv

Yesterday our Kids Code Jeunesse founder and chief badass Kate Arthur chatted on Montreal local tv with Richard Dagenais. Great interview — I think Kate did a good job positioning code as a common everyday medium that anyone can (and ought to) get a taste of and put to use, even without becoming a programmer.  And maybe some folks in the audience will come away a little less intimidated by learning to code. 🙂8b8db55d7dcb2cb6_150_montreal

Episode: MONTREAL BILLBOARD October 13, 2015 (Kate starts at ~8:30.)

Cited in the interview: our partner codecademy, who has a great lineup of well-documented, self-paced lessons in a variety of coding platforms. (Seriously, check out their HTML + CSS sequence. It’s not perfect, but they align well with my axioms of programming instruction. It’s a very good entryway for kids and newcomer adults.)

Introducing Mike’s axioms

finger point photo
Photo by jetheriot

Introducing…. Mike’s Axioms for Computing Instruction.

As I do more and more teaching and lesson writing, I’ve started collecting the gemmiest of my design principles.

Little by little I’ll record them here in the blog with some examples and the reasoning behind them, and hopefully they’ll be a useful reference for me and others. As I deepen my formal knowledge and gain more hours of practical experience, I’ll come back and elaborate or revisit.

Continue reading Introducing Mike’s axioms

CS Capture the Flag 2015

Following the recent topic of cryptography for high schoolers, here’s a cool event that popped up on the radar this week: HSCTF, a US-wide high school “capture the flag” style programming competition.

The week of May 17-24, 2015, students from across the US are invited to play a (everyone outside the US too, but they’re not eligible for prizes). Challenges include cryptography, reverse-engineering, and reconnaissance. Continue reading CS Capture the Flag 2015

Crypto for high schoolers

At one of our recent Kids Code Jeunesse meetings, my friend, high school programming teacher Stuart Spence (see his site and his YouTube channel) was telling us about what his students are into.

One of the things they get most excited about–especially, he says, the girls–is cryptography. They think it’s really cool that they can use their just-beginning programming skills to reverse-engineer passwords and crack codes and stuff like that.
Continue reading Crypto for high schoolers

Was object-oriented programming a failure? – Quora

From the discussions in my Quora digest recently, a brilliantly simple and cheeky question:

 “Was object-oriented programming a failure?”
( free signup required to see the whole thread)

Note the use of the past tense. You gotta love trolling for Java apologists.

To be fair, you gotta love trolling for Python believers too. The difference, of course, is that the Python believers are usually right. 🙂

If you read the Answers, there are some very thoughtful critiques . The best of them seem (my favorite is by Joe Wezorek) to conclude that Object Orientation is a useful way of thinking about certain things – but maybe is a relic of the past, developed as a good response to the specific kinds of software problems that were prevalent in the 1980s, and probably gets used too abstractly and too blindly to be called good practice.

Another good response (by John Colagioia) appreciates the fact that Object Orientation provides some useful scaffolding: “You might not end with a great design, but you can have a passable design if you ‘implement every noun as an object, every verb as a method, every adjective and adverb as a condition.'” I can get behind that.

But the over-abstraction that we see in some languages–and really, this may just be because it’s being poorly understood and taught–is a real stumbling block to having more people become coders, and having our existing coders be expressive with their work.

My own opinion is that the over-abstraction may just be a natural interaction that happens when engineering meets the corporate business world. You end up with people who think a certain way about process and content and how they should work in the world, and before you know it, you’ve got a gospel that turns an otherwise creative, dynamic act (programming) into an exercise in over-architecture and bloat.

But my favorite bits are still the ones where the Java folks get teased.

Why, exactly, teach coding?

So here we are, in another generation of Let’s teach programming to kids.

We’ve got Scratch, Tynker, Hopscotch, ThimbleMinecraftEdu, Codea, and many, many others — great ways for kids to get their feet wet with programming and building digital things.

Pick up the Education section of any newspaper or magazine these days and you’ll see a profile of someone who’s either teaching kids to code, or building a foundation or a policy to support someone who is. It’s a wave.

But this isn’t the first one. And this time, just as before, it’s worth asking why, exactly, teaching kids to code is so important.

If you’re part of this enterprise, what makes you so sure this is worth it? And how do you convince others they should join in?

Continue reading Why, exactly, teach coding?