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, inventtolearn.com, 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!

Friday, January 20, 2017

A Growth Mindset Workshop

I recently gave a workshop on the growth mindset with first year computer science students working as part of this amazing program. It went well, so it seems worth sharing. What follows is the workshop plan.

Growth 

Take the following quiz and share results: http://mindsetonline.com/testyourmindset/step1.php

Share definition of growth and fixed mindset (read quote, put key parts on a slide):
“When we ask people to tell us what the growth mindset is, we often get lots of different answers, such as working hard, having high expectations, being resilient, or more general ideas like being open or flexible. But a growth mindset is none of those things. It is the belief that qualities can change and that we can develop our intelligence and abilities. 
The opposite of having a growth mindset is having a fixed mindset, which is the belief that intelligence and abilities cannot be developed. The reason that this definition of growth mindset is important is that research has shown that this specific belief leads people to take on challenges, work harder and more effectively, and persevere in the face of struggle, all of which makes people more successful learners. 
It is hard to directly change these behaviors without also working to change the underlying understanding of the nature of abilities.” (source)
Watch TEDx talk by Carol Dweck. Have students write down everything they found interesting, surprising, or useful. Pair up, pick the top three points of interest, share them.

Share printout with the following quotes from Mindset and have them read them individually. While reading, think about times in your studies (especially in the fall!) where you might have approached something with a fixed mindset, and other times you have used the growth mindset.
I [Carol Dweck], on the other hand, thought human qualities were carved in stone. You were smart or you weren’t, and failure meant you weren’t. It was that simple. If you could arrange successes and avoid failures (at all costs), you could stay smart. Struggles, mistakes, perseverance, were just not part of this picture. 
...children with the fixed mindset want to make sure they succeed. Smart people should always succeed. But for children with the growth mindset, success is about stretching themselves. It’s about becoming smarter. 
Why is effort so terrifying? There are two reasons. One is that in the fixed mindset, great geniuses are not supposed to need it. So just needing it casts a shadow on your ability. The second is that … it robs you of all your excuses. Without effort, you can always say, “I could have been [fill in the blank].” But once you try, you can’t say that anymore.
In this course [in our research study], everyone studied. But there are different ways to study. Many students study like this: They read the textbook and their class notes. If the material is really hard, they read them again. Or they might try to memorize everything they can, like a vacuum cleaner. That’s how the students with fixed mindset studied. If they did poorly on the test, they concluded that chemistry was not their subject. After all, “I did everything possible, didn’t I?”

The students with the growth mindset completely took charge of their learning and motivation. Instead of plunging into unthinking memorization of the course material, they said: “I looked for themes and underlying principles across lectures,” and “I went over mistakes until I was certain I understood them.” They were studying to learn, not just to ace the test. And, actually, this was why they got higher grades – not because they were smarter or had a better background in science. 
[Benjamin Bloom, eminent educational researcher, says:] “After forty years of intensive research on school learning in the United States as well as abroad, my major conclusion is: What any person in the world can learn, almost all persons can learn, if provided appropriate prior and current conditions of learning.” 
Just because some people can do something with little or no training, it doesn’t mean that others can’t do it (and sometimes do it even better) with training. This is so important, because many, many people with the fixed mindset think that someone’s early performance tells you all they need to know about their talent and their future. 
[Story from one particular student, Tony:] In high school I was able to get top grades with minimal studying and sleeping. I came to believe that it would always be so because I was naturally gifted with a superior understanding and memory. However, after about a year of sleep deprivation my understanding and memory began to not be so superior anymore. When my natural talents, which I had come to depend on almost entirely for my self-esteem (as opposed to my ability to focus, my determination or my ability to work hard), came into question, I went through a personal crisis that lasted until a few weeks ago when you discussed the different mindsets in class. Understanding that a lot of my problems were the result of my preoccupation with proving myself to be “smart” and avoiding failures has really helped me get out of the self-destructive pattern I was living in.
After the exercise, have students pair up and discuss the consequences of using the fixed or growth mindset in different scenarios. Share one or two stories with the group.

Tuesday, November 22, 2016

GHC16 / What Are Tech Tools Doing That The Best Diversity Initiatives Aren't?

How can software help companies recruit and hire more diversely? Erica Joy Baker, Laura I. Gomez, Stephanie Lampkin, Liz Kofman, and Aline Lerner tackled this question on a panel at Grace Hopper this year. Most came from the perspective of creating the tools or working in tech, and one came as a social scientist studying the problem. It turns out that technology can do a lot, from removing biases to helping employees find good matches in prospective employers.


Here are my live notes from the session, edited slightly since I took them.

- we'd like to have the tech to kill the resume and allow for anonymous processes where everyone is evaluated the same
- what drives behaviour change? show candidates what's really going on in companies
- "I don't believe in unconscious bias training. I believe in results."

- compelling to see results of a fairer, more competitive process
- many challenges in academic research: one group, no change, another group, huge difference (why?); the more data we have, the more we can figure out what's really going on
- early feedback is that demystifying 'the pipeline' idea has been valuable

- technical interviewing it totally broken; interviewing as a process is as effective as putting names on a dartboard and throwing the dart (this is especially true of unstructured interviews, which have no correlation to success outcomes; structured interviews have a tiny amount of correlation)
- competency-based interviewing helps structure interviews as well as check later whether the interview ended up being a good predictor of future performance; issue is that managers don't know what competencies matter, so hand-holding in that regard is needed
- big companies need to have the same vocabulary and awareness of where the issues are

- want companies to dissect what makes a high performing employee, then capture that about a candidate; again, because traditional interviewing sourcing process is broken; need chances to capture data in soft skills, behaviour science, neuroscience...

- hiring processes are antiquated; why haven't we seen much innovation in this space?
- change is hard partly because those responsible for letting folks into the pipeline don't have the skills they're recruiting for; they have the wrong incentives

- anonymizing applicants: is this the same as that Wall Street Journal author's suggestion, which made many women and other feminists upset?
- even when we remove the name, there are other indicators; how you write can identify you, even when what you said doesn't change
- anonymization doesn't take away identity; it lets folks look at us differently

- audience question: should companies be aiming to improve diversity? how will anonymization help them identify those candidates?
- yes, there are companies actively sourcing; mixed evidence on blind identity (may not help companies that were already trying); have to understand the context of the companies, each of which are so complex
- not as simple as sourcing underrepresented groups; need efforts to improve the process and give resources to those that don't have them
- recognize that we do have biases, and give tools to interrupt them

- audience question: has bias affected how much funding your companies have received?
- bias toward funding previously successful founders, even though data shows this isn't a good indicator of success
- needs to be more examples of success because there's a lot of pattern matching going on
- Stephanie: need to set the example as a young gay black woman, farthest from an old white man as you can get
- having a personal brand ended up helping some of the panellists (though not deliberate); e.g doing a lot of writing on the broken hiring process and sharing data

Sunday, October 30, 2016

GHC16 / Building a Better Classroom: Lessons from Ed-Tech

One of the panels I attended at this week's Grace Hopper Celebration featured women from various companies engaging in ed tech, whether as their sole purpose or as a smaller part of their mission. Panellists included Prachie Banthia (moderator, Google), Lauren Janas (Microsoft), Stephanie Killian (Knewton), Jen Liu (Quizlet), and Sha-Mayn Teh (Teachers Pay Teachers).

iPad

The panel began with a discussion of the challenges in getting classrooms to adapt ed tech. Unsurprisingly, cost and difficulties in rolling it out topped the list. Then each panellist discussed what problems specifically they are trying to solve:
  • Learning can be static, tedious, and boring. Quizlet makes it more fun. Most users are middle and high schools using it for language learning, math science, etc. Some adults use it too, for things like med school and even bartending. Today, their focus is on K-12.
  • Knewton focuses on the problem in ed of 'one size not fitting all.' Standard models of education treat everyone the same (curriculum, pace).
  •  Some teachers were really focused on using tech in the classroom, e.g. to scale learning to class sizes of 45. Google Apps tries to support and reach the majority of teachers that aren't currently doing this.
  •  MS Office Mix supports developing materials for flipped classrooms. You can record yourself talking over a PowerPoint presentation, include quizzes, and distribute to students. The software provides analytics to improve lessons and see how well students are learning.
  • Teachers Pay Teacher helps teachers search for the right resources quickly.
Another one of the challenges faced by creators of ed tech is surviving the peak time of back-to-school. Advance planning is required to figure out how to scale the load capacity based on projected numbers of students. Launching any time after August 1 is really like launching the following year on August 1, because you've missed the critical window for adoption. The holiday season is the down-time, and that's where fixes and be made.

So how do these panellists view adoption of ed tech? They say tech in schools is fragmented, and so it is difficult to target a particular platform. It is very important for a company to earn the trust of teachers and administrators. Teachers are reluctant to test things on students. Too much setup time will make adoption harder: class time is precious. You have to make the barrier to entry as low as possible. And, of course, there are many issues around school networks / wifi. 

When it comes to the fear that ed tech might be trying to replace teachers, the panellists say this isn't the case; they want to empower teachers. Some call themselves teacher-preneurs and they all have such passion, and find creative ways to use technology to make their point with students.

A controversial question: are larger companies like Google and Microsoft more likely to succeed than the smaller companies, thanks to their resources? Having a lot of spare resources does give bigger companies a leg up. Smaller companies with education as a core product need to find a revenue model, which is challenging. Enterprise partnerships can help. All agree that it is good having the larger companies there, but also the smaller disrupters. Large companies have scale, and people already know how to use their products. Even still, monetization is hard for everyone (even Google struggles with this still). Smaller companies have the advantage when it comes to the ability to disrupt: Google can't take a pedagogical stance (65 million users whose trust can be lost), but smaller companies can.