Friday, October 13, 2017

GHC17 / Changing of the Guard: Welcome to the New ABI President and CEO

At the opening keynote of this year's Grace Hopper Celebration, eighteen thousand technical women got to meet's new President and CEO, Brenda Darden Wilkerson. She introduced herself as a warm, eloquent, and passionate lady. She and outgoing CEO Telle Whitney made a touching video in which Telle passes the proverbial torch to Brenda, heralding an exciting new era for the organization.


I have had the great pleasure of getting to know Telle over the last number of years. A talented computer scientist, she took on the commitment of heading up the then-called Institute for Women and Technology in 2002 when her dear friend Anita Borg fell ill. Though CEO might not have been a role she expected to have, Telle embraced the challenge and lead the institute through incredible growth and impact.

I first met Telle when I was assigned as a Hopper volunteer for an ABI advisory board meeting during Grace Hopper in 2010. I was then invited to be part of the board and got to know Telle more over the years. Some of my fondest memories of her are on the dance floor, where she was always ready to bust a move with me like we were the best of friends.


I had the chance to meet Brenda Tuesday night before GHC started. The ABI advisory board no longer exists, but I had the chance to attend the Systers leadership dinner with the Anita|Bees committee. Brenda addressed our relatively small group with such warmth that I couldn't help but immediately like her. That she has such an impressive background, and founded the original 'computer science for all' initiative, just makes it all the better.

I'm also tickled that we had a bonding moment over breastfeeding. I was nursing my six-month-old Henry when she was going to introduce herself. After noticing what I was doing, she told me about her own experiences with her babies. I love connecting with folks on a personal level like that, no matter how "high-up" they are.


I think everyone can agree that great things lie ahead for I hope that Telle enjoys her well-earned retirement, and I hope that I'll have a chance to dance with Brenda someday as well.

If you'd like to learn more about Brenda, check out her interview on the website.

Wednesday, July 5, 2017

How We Learn: A Book that Understands the Research and Brings it to the Masses

There's a lot of research out there on the theory of learning, so you'd think we'd all know the tricks by now. Unfortunately, due to the relative inaccessibility of academic research by the general public, this isn't the case. Academic writing, when you can find it without needing to shell out a lot of money, isn't exactly designed for consumption by the everyday person (and I say this having been an academic).

Luckily for us, Benedict Carey, a long-time science journalist, has done the work of distilling key learnings (pun intended) about learning science (etc) from the literature. He shares some very practical results in How We Learn: The Surprising Truth About When, Where, and Why It Happens. Even better, he does it in a way we can all understand.

The book climbs the ladder of abstraction of the mind. It begins with some basic neuroscience theory, explaining how the brain works. It then goes through some of the best techniques to remember things, shares ideas behind effective problem solving, and finally discusses how learning happens away from the conscious mind.

There are a few themes that are threaded throughout the book. For example, some level of difficulty is desired, such as forcing yourself to struggle to remember things through self-testing. Another theme is the power and importance of forgetting:
“Compared to some kind of system in which out-of-date memories were to be overwritten or erased,” Bjork writes, “having such memories become inaccessible but remain in storage has important advantages. Because those memories are inaccessible, they don’t interfere with current information and procedures. But because they remain in memory they—at least under certain circumstances—be relearned.” 
Thus, forgetting is critical to the learning of new skills and to the preservation and reacquisition of old ones.
Other important ideas include the role of context in learning (it's best to switch it up!), why testing is much more important than just for assigning grades, and how to know when to stop working on something for a while to let it percolate.

Carey walks through all of these ideas by telling the stories of the researchers who discovered the various principles, and how their ideas can be put into practical use by us today. If you're looking for just the quick and dirty list of what to do to improve your learning, this probably isn't the book for you. Such a list is there at the end, but you might find reading the whole book inefficient. On the other hand, if you like to have ideas reinforced several times and enjoy hearing about the history behind them in an engaging way, I highly recommend this book!

Monday, May 29, 2017

When Feedback Makes You Cry a Little

Feedback really is a gift. But feedback can also be hard, both to give and to get. I moved into a leadership role a little over a year ago, and got my first hard-hitting feedback at the end of 2016.

Got Feedback?

The fall was a stressful time for our entire team. We were launching something completely new with fewer people than we needed and inherently inflexible deadlines. I was pulled in multiple directions as I tried to build what our team would do more broadly, champion this one huge project, and do a fair bit of individual-contributor work that really did have to be done by me in the circumstances. Everyone else was faced with wearing too many hats, too. We managed to maintain a very high quality through the fall but we were all worried about what was looming in the new year.

Late fall, my lead initiated a feedback process for me that included everyone on our team and a bunch of folks that worked with us. I also did a self evaluation. It's a standardized process used with all folks in leadership roles. I got a report back with a summary of scores on the various questions and the written responses, but of course none of the names to go with them.

When I first got the report, my heart just sank. How poorly I had calibrated my self-evaluation is what struck me first - most scores given to me seemed really low. Then I started to read the written stuff and my heart sank even lower.

Nothing written was mean, and in fact, none of it was unfair. It took a day or two of reflection, but the feedback was absolutely right.

I wonder if there are known stages of absorbing feedback, like the stages of grieving. At first I felt shock, then I felt a little upset, and then I felt horrible about how I had made the team's lives harder in some ways. It was difficult to realize how much less self-aware I was in some areas than I imagined.

After reading the report I had a session with one of our internal coaches. I definitely cried a little in that session. We worked through the feedback, me talking through what likely caused it and how I missed realizing what I was doing. It was extremely valuable and I highly recommend doing something similar if you can.

The coach gave me some suggestions for how to address the feedback with my team. At our next standup I brought it up using her advice and cried a little again. The team was so wonderful. It became really clear that the feedback came from a place of us all caring about each other very much. It was a difficult but very important experience.

I was able to put some of the plan for addressing the feedback into action before leaving to have a baby a couple of months later. My biggest takeaway, besides the specifics of the feedback, is that I need to give and ask for feedback more often. It's not always easy, and it might make you cry a little, but it is so so worth it.

Friday, March 24, 2017

Review / Invent to Learn: Making, Tinkering, and Engineering in the Classroom

While visiting a branch of our city's library system we don't often find ourselves at, I browsed the tiny section on education. I found Invent to Learn by chance, and though the title's font left me a bit skeptical, I decided to give it a try. I'm glad I did.

The premise of the book is that adopting principles of making into formal and informal education is both feasible and worthwhile. The focus is on maker projects oriented around fabrication, physical computing, and computer programming. The book starts with solid learning theory and goes all the way to how to actually teach with open-ended maker projects.

I'm admittedly an education nerd, so I was delighted to see the book start with some relevant education history, learning theory, and discussion on "thinking about thinking." Seymour Papert, creator of Logo among many other things, is a central figure threaded throughout.

Papert coined the term constructionism, which builds on a previously established theory of learning, constructivism. As defined in the book, constructivism is:
...a well-established theory of learning indicating that people actively construct new knowledge by combining their experiences with what they already know. Constructivism suggests that knowledge is not delivered to the learner, but constructed inside the learner's head.
On constructionism:
Papert's constructionism takes constructivist theory a step further towards action. Although the learning happens inside the learner's head, this happens most reliably when the learner is engaged in a personally meaningful activity outside of their head that makes the learning real and shareable. This shareable construction may take the form of a robot, musical composition, paper mâché volcano, poem, conversation, or new hypothesis.
The authors claim that constructionism is the learning theory that resonates most with the maker movement, and build the rest of the book on this idea.

The rest of the text covers what makes a good project, what 'making' means today, the three game-changers in making (the aforementioned fabrication, physical computing, and programming), the practical stuff of actually teaching through maker projects, and how to convince others that the maker approach is a good idea.

Many concrete resources and materials are described throughout the book. It was published in 2013, though, so a lot of the specifics are likely to be out of date. Nonetheless, the suggestions should serve as a good starting point. (As a side note, the book's website,, appears to have been hacked, so best not to visit it at the moment.)

Overall, if you are curious about having your students learn by making things (real or virtual), and want to get a taste of the theory behind why it might work as well as the practical suggestions on how to do it, it's worth checking this book out.

Thursday, March 2, 2017

Why I Prefer Processing as a First Language to Teach

Once upon a time, almost 5 years ago, I wrote a post about Python vs Processing as a first language to learn. It became my only post to appear on Hacker News and still gets plenty of hits. The reflections in that post were quite early on in my use of either language for teaching, though. Now that I've used both in several teaching contexts, I'd like to explain why Processing still holds top spot for me when teaching beginners about computer science and programming.

(from a demo in my CS1 course using Processing)

Before I begin, I'd like to say that just because I like Processing best doesn't mean that other options aren't also good. Python, for example, is still a good first language in my view; I even use it in some of my course designs and workshops, especially if someone is in a field that will likely only ever use Python. For younger audiences, Scratch is still my go-to. There are many other languages and tools I probably haven't even seen yet that have great promise, too. But for workshops and courses to introduce beginners in high school, post-secondary, and beyond, Processing remains my go-to.

Without further ado, here are some of the reasons why I love Processing...

Processing is easy to download, install, and run. When you open it, it looks clean and simple. You can ask learners to write in one line of code, press play, and see a drawing pop up. This matters, especially when you are aiming to reduce intimidation of learning to program among less traditional groups. I'm always looking to remove any barrier possible that might make a beginner "nope out" of computing.

The fact that Processing's main purpose is to create visual output is also a huge bonus. You need very little code to create something that is meaningful enough to show others. Running home to show your family that your code spits out a number on a console just isn't the same as showing a (usually interactive) visual program. On the console, it's harder to understand that the code does something interesting and that it took effort to do it.

A further advantage of visual output is the ability for learners to see more of what their own code is doing. When you perform a computation with a single result at the end, the code can feel a bit like a black box. If the answer is wrong, which part of the code caused the issue? At least when all your code contributes to what's on screen, you have some more ability to reason about which code is causing the output to be wrong.

Pedagogically, I have a strong preference for introducing as few individual concepts at a time. I don't like the approach of most textbooks and courses I see, where all the fundamentals (variables, branching, iteration, functions, etc) are introduced quickly up front with toy examples before finally getting to the more interesting projects/demos. At the same time, starting with something too complex right away is intimidating and would likely lead to cognitive overload (*cough* Pygame).

I find that Processing allows me to design demos of just the right complexity. Each new demo only needs max a few new concepts (be it a programming concept or something Processing-specific like adding images). I can show the demo, and start working on creating it, introducing concepts just-in-time. It's also possible to design lots of interesting exercises with the same minimal number of new concepts, allowing learners to focus on mastering a small number of things at a time. I find this more difficult to achieve with other languages, even if there is a visual component (for example, I found Python Turtle too restrictive to achieve this for anything longer than a short workshop, while Pygame is way too complicated up front).

As an example, here is a summary of my CS1 course design in terms of the demos I cover for each module and the concepts that are introduced (more detail, including slides and code):

  • Drawing pictures with Processing – a static image with several semi-complex entities (basic drawing, variables)
  • Interactive painting with Processing – an interactive painting program that allows you to change colours (active mode/interactions, basic functions, switch statement)
  • Jukebox – a music player with three buttons to start and stop songs (functions as abstractions, Boolean expressions, if statements)
  • Sheep AI – pet sheep that wanders toward your mouse, drinks tea when it reaches it, and emanates coloured rings when clicked; pictured above (state machines, while loops, arrays)
  • Foreign student data visualization – visualization of sortable data available on Canada's Open Government website (Strings, algorithms, state-only objects, constructors)
  • Social media set cover problem – contextualized example and visualization of the set cover problem for a small set of data (shared data and references, for loops)
For beginners I prefer teaching languages that are statically typed and generally more 'rigid' for lack of a better term. The more the compiler or interpreter can tell you about what you're doing wrong, the better. I've seen so much frustration from my students working in Python because they do weird things that are syntactically correct, but make no sense semantically. Of course this point doesn't limit the choice to Processing, but it's an added plus for me.

It can also be useful that Processing is Java, but with the tricky parts abstracted away in the IDE. Starting this way is great because you don't have to say things like "don't worry about what public static void means, I promise it'll make sense later." Yet students are actually learning Java syntax when they learn Processing, and can even start pulling in more advanced features of Java later on if desired. When a follow-up course is done in Java (as the CS2 course I designed is required to be), the transition is smooth. Even better, you can still use the Processing library in a 'regular' Java project (example), so you can incorporate it into those later courses if you want. For instance, in CS2, I do so to get students using a third-party library and to learn about MVC and event-driven programming (see more).

I could probably go on about how useful I've found Processing in teaching beginners, but I think this is a pretty good list for now. I'd love to hear about how you've used Processing in your own teaching!