Learning by Wholes

David Perkins is a senior professor of education at Harvard who has done a lot of super-applicable, general-audience writing. I just finished his book Make Learning Whole, and am eager to try applying each of the seven principles he outlines within. Here are some ideas of how I think each could apply to my own work, along with an explanation of the principles themselves.

Play the Whole Game

"We can ask ourselves when we begin to learn anything, do we engage some accessible version of the whole game early and often? When we do, we get what might be called a 'threshold experience,' a learning experience that gets us past the initial disorientation and into the game. From there it's easier to move forward in a meaningful motivated way."

By game, Perkins means a domain, a field, an area of learning. The point is to not to just talk about the game, not to pick away at learning just elements that are part of the game, but to actually do it and participate in it. Sure, you might have to play a junior version, probably with lots of scaffolding to support you at first, but that's still far superior to being promised you'll (maybe kinda sorta) get to the real thing later.

As a computing educator, it is tempting to say that playing the whole game comes for free since you start writing code pretty much right away. But the whole game isn't always present, at least not until later. There are oh-so-many examples of introductory programming learning experiences that go through a laundry list of concepts, using toy examples for each one before eventually getting to look at any sort of interesting, realistic problem. I avoided this with my CS1 design. It is structured around a series of demo programs in Processing. Each module is devoted to modelling how to create one demo, introducing computing concepts as they are needed. I want to make sure I continue to keep the whole game in mind for all my learning experiences. If my learners aren't doing something resembling the real thing, I need to fix that.

Make the Game Worth Playing

Motivation is always a tricky thing, especially in contexts where the reason for learning something is because a teacher said you have to. So how do we make the game worth playing? By playing the whole game, for a start. Look for intrinsic motivators. Connect to practical applications, personal insights, to other areas of the curriculum. Focus instruction on generative topics ("topics that figure centrally in the discipline or practice under study, resonate with the learner's interests and concerns, and, importantly, resonate with the teacher's also"). Teach in a way that highlights "understandings of wide scope, with enlightenment, empowerment, and responsibility in the foreground." Build a tone of enticement into the beginning of lessons. Teach for understanding. Foster a growth mindset. Provide a pleasantly frustrating challenge, seeking flow.

I've done a lot of thinking on game-like learning, and have led and contributed to development of a few game-like and even game-based learning experiences. I think that a lot of the ideas behind making the game worth playing connect well with game-like learning. I recently delivered a course to employees at work and struggled a bit with engagement. In my next experiment, I'm thinking of using game elements to increase engagement and retention.

Work on the Hard Parts

"The hard parts have an annoying characteristic: They do not always get better just through playing the whole game. Real improvement depends on deconstructing the game, singling out the hard parts for special attention, practicing them on the side, developing strategies to deal with them better, and reintegrating them soon into the whole game." Actionable assessment and communicative feedback are important aspects. To anticipate the hard parts, watch out for certain kinds of knowledge: ritual, inert, foreign, tacit, skilled, and conceptually difficult.

I've fully adopted backward course design, and have gotten pretty good at writing learning outcomes. In my next designs, I'd like to identify the 'hard parts' among the learning outcomes, and double check that I am isolating, practising, and reintegrating them. I think I am doing this in my aforementioned CS1, where I get learners to practice the newly introduced computing concept before reintegrating it back into the development of the module's demo.

Play Out of Town

We want our learners to be able to transfer their learning: "People learn something in one context, and this informs how well they learn and perform in another context. ... In other words, transfer is a matter of 'playing out of town,' applying the games we learn to bits and pieces of those games not just in their original contexts but elsewhere, in some other setting where they might be helpful." Think about "what is supposed to transfer, to where is it supposed to transfer, and how is the transfer accomplished." Fostering transfer means including "some of the connection making that we hope learners will do later on."

One of the big goals I had when starting our curriculum-aligned work-integrated learning program a few years ago was to help our students see computer science more holistically while making deliberate, explicit connections between academic theory and the industry work they do. Although I don't work on that program directly anymore, I'm always brainstorming ways to do this and making suggestions to the team. My hope is that the result will be better transfer of academic knowledge to the workplace. I'm also hoping to look for more ways to incorporate reflective abstraction and diverse applications into individual learning experiences.

Uncover the Hidden Game

"Any complicated and challenging activity always has multiple layers beneath the obvious. ... The hidden games are not only interesting but often important to doing well at the surface game. ... A great deal of learning proceeds as if there were no hidden games. But there always are. They need attention or the learners will always just be skating on the surface." A few example types of hidden games include the hidden games of strategy, causal thinking, inquiry, and power. Games hide under the rug of simplicity, within the margins of good enough, inside the cloak of the tacit, and beyond the horizon of readiness.

The next time I create a learning experience for developers who want to learn a different language or tech framework, I want to use my subject-matter experts to help me uncover the hidden game of what they do. I think a short lesson on the ideas from the book might help them know what I'm going after, and I can use my own expertise as a practitioner to dig further. I want to make sure the hidden game surfaces in the learning outcomes and therefore the rest of the learning experience.

Learn from the Team

So much of formal education has the expectation of learning solo. Learning from the team means engaging with richer participation structures (how activities are organized through roles and responsibilities) that are more social and collaborative. Effective participation structures include pair problem solving, studio learning, communities of practice, cross-age tutoring, and extreme team learning.

We've used a few of these, some more directly than others. For example, our work-integrated learning students are asked to pair program very early on in their industry-based education paths. As I work on my CS1 course to be delivered to employees, I'm planning on incorporating learning teams, each one assigned its own mentor. I also want to encourage pair or group problem solving and more meaningful peer evaluation opportunities.

Learn the Game of Learning

"Learning to learn has to do with many things: directing one's attention, choosing time and place, relating new ideas and skills to what you already know. Indeed, it has a lot to do with the previous six principles." To uncover the hidden game of learning, learners need to move from the passenger seat into the driver's seat. Skills ranging from problem-solving strategies to time management should be taught explicitly, either as a standalone course or incorporated throughout curriculum.

Our work-integrated learning program already has workshops that help our students learn the game of learning, such as a growth mindset workshop I led. As I continue to read books on how learning works, I'm hoping to compile the fundamentals into an easily-digestible format and potentially a workshop as well. The former could be shared with learners in my courses for employees as well.

Delivering a Technical Course to Busy Developers

At work, I'm experimenting with how to deliver a technical course to my fellow employees in such a way that participants succeed and our team doesn't have to put in too much time on top of our regular duties. Just making them available for self-directed study results in most folks poking in for an hour and never returning. If we can come up with the right delivery model, we can make all the courses we create for other purposes available to our colleagues without adding stress to our already busy schedules.

Many of our courses were designed for students in our work-integrated learning program first. Most material is curated with our own added context and assessment, and courses are intended to be completed in a self-directed manner. For our WIL students, we provide lots of feedback on their work and hold in-person sessions that range from formal tutorials to quizzes to pair programming assignments, all of which require quite a bit of time and attention from our education team.

I chose a Ruby programming course for my first experiment this summer since the majority of our development is with Ruby on Rails. I put together a series of short workshops previewing Ruby to our Dev Degree students and a more in-depth project-based course the same students took later on. The students spent two hours each on five workshops and about 20 hours a week for 3 weeks on the project.

I initially made the new course 8 weeks long, though we added a breather week partway through. Interested learners were asked to get lead buy-in, and were told they'd need to spend some time during work to succeed. I sent students some pre-learning resources both to set expectations of prerequisite knowledge, and to offer help for those who wanted to fill in any gaps. I recruited experienced Ruby developers as mentors who would answer questions, formally review project work, and run weekly tutorials using video conferencing software. Assignments were due each week, but with soft deadlines; getting an assignment in on time meant being paired up automatically for a peer review.

The course started with over 50 confirmed learners. Many have dropped off since, which isn't unexpected. Some realized that they didn't have enough problem-solving-oriented knowledge, and will likely take one of our intro to CS courses when the opportunity arises. Others found the everyday demands of their jobs made it difficult to keep up, and though there are exceptions, it seemed that once someone fell behind, they more often than not just stopped working on the course.

The course didn't end up being too demanding on my time, but it doesn't look like very many students will finish it. We wrap up next week, at which point I'll start to dig into who finished, who didn't, and why. I plan to have some anonymous surveys as well as focus group discussions. It will be really interesting to see whether we can find some tweaks that result in more success stories.

Have you ever tried to deliver a technical course to your colleagues? What did it look like? What structure worked well?

Six Months On, Six Months Off: My Experience of Maternity Leave in Tech

Today, my second child, Henry, turns one. I went on maternity leave for six months when he was born, which means I have also been back for six months. I was a grad student when I had my first baby, so life was pretty different then. Being International Women's Day in addition to Henry's birthday, it feels like a good time to reflect on my experience this time around.

Henry eating a cupcake at his daycare's birthday celebration.

In no particular order, here are some thoughts about my six months off:

• I felt pretty useless the first 6-8 weeks, recovering from a repeat c-section after 50 hours of labour towards a failed VBAC.
• Everything was changing on my team when I left, big time. We had a new team lead who was amazing, but this fact gave me all kinds of feels as I was more or less 'in charge' until then. 
• I kept close tabs on the goings-on of the team while I was away. Slack was part of my regular social media rounds. I even contributed with tangible work here and there when there was something I could help with or that I was really invested in.
• I managed to get a lot of reading done during my leave and that felt really good.
• I missed the office (the actual building in addition to the people there).
• I decided I wanted to pursue technical leadership instead of people management as a career path.
• I didn't have the motivation to go out to play groups or baby classes as I did the first time.
• I didn't socialize much other than visiting with family. (It was great to visit my parents' pool patio for example, even if I rarely actually swam.)
• Making lunch for myself sucked (we get free lunches at work).
• I constantly asked my husband, who works at Shopify as well, what was going on at the office, what was for lunch, whether he brought my any dessert, etc.
• I felt very grateful that I could take so much more time off than my American friends, and have my EI allowance topped up by Shopify the entire time.
• My team sometimes joked that I never really left.

And some thoughts about my first six months back:

• At first, I struggled with rejoining as an individual contributor on a team I had in some ways started and led for a while.
• My husband was on leave for the second half of Henry's first year and he stayed completely disconnected from work by choice.
• It was incredible how fast things had moved while I was away, and I can't imagine how far behind I would have been if I hadn't stayed connected.
• I was happy to be able to jump back in quickly with work I was very familiar with from before my leave.
• The first four months were difficult in terms of scheduling meetings, pumping sessions, and time with students whose schedules were very complicated. Some of my newer colleagues questioned my time management skills / commitment to quality.
• Henry was a terrible sleeper the entire six months I was back at work (we only sleep trained him this past week and before that waking up every two hours was a 'good' night). I was running on near empty and had nothing left to give outside of work.
• I missed carpooling with my husband and eating lunch with him, but also enjoyed the slight increase in schedule flexibility knowing he could pick up our daughter from school. It was also nice to eat with teammates and get to know them.
• I'm finding myself wanting to wean in the near future, despite having nursed my daughter until she decided to stop on her second birthday.
• I had a hard time enjoying Henry during these months, largely due to sleep deprivation and perhaps being away from him most of the weekdays. But that's back on track now that I am sleeping!

So many feels, this whole baby thing! I'm incredibly grateful to have had this experience while working at Shopify, which appears to be one of the best tech companies in this regard.  However, it's easy to see why being on leave for any number of months, let alone a whole a year, can hurt someone's career. Our society definitely needs to continue figuring out how to balance to scales for folks who leave to care for family, and to encourage men to take leave as often as women.

Getting Better at Ruby for #AdventOfCode2017

Because I'm a computing educator, I don't write code every day. I'd be lying if I said I didn't miss it. So when I heard about Advent of Code late 2017, I knew I wanted to participate.

In its third year, Advent of Code was created by Eric Wastl. On each day of December up to and including Christmas Day, a new problem is released at midnight Eastern time. Each registered user gets personalized input, and when you solve part one of the problem, a second, usually more difficult, part is revealed. Each part earns you a star. The faster you get your stars, the higher you are ranked. There's a global leaderboard showing the top participants.

I wasn't too interested in the competition aspect, knowing I couldn't be up at midnight every night working on code. Instead, I decided to commit to solving the problems as close to when they came out as I could for my circumstances. I also decided to use Ruby so I could remember the basics I used to know from working in Rails for half a year, and learn about the language on its own a bit more deeply.

I managed to solve almost all the problems the day they came out, with just two or three being finished the day after due to time constraints (read: two young children). I also learned a lot about Ruby, from the unexpected things you can do with hashes to its memory model, and more. My favourite trick was using a two-item array representing an x-y coordinate as a key to a hash.

More importantly, it was really really fun writing code every day. I couldn't believe how addicting it was. Most of the problems were fairly easy to solve using Ruby (sometimes it felt like it was cheating using that particular language!), though some were much trickier conceptually. None of them completely thwarted me though, and I managed to figure them all out on my own without looking online. Earning each star was very satisfying.

The code as I wrote it is now up on my Github – no editing after the fact. I know I'm not following all the Ruby conventions (I really do prefer camel case for example), and I'm probably being more verbose than a lot of folks doing this competition (I love readable code). Now that the competition is over, you can see all the problem descriptions to understand what I'm trying to achieve. (I think you still have to solve part 1 to see the part 2 description, though.)

GHC17 / Teaching Literature with Interactivity

Any time I go to a conference and see the word 'learning' in a session title, I get excited. Even better when games are involved. So I was already positioned to enjoy Elizabeth Hunter's talk on teaching literature with interactivity. Bonus that she herself is getting a PhD in theatre and knows how to present!

Elizabeth told us about her interesting game project called Something Wicked. The project aims to answer the question of whether playing a true-to-the-text video game adaptation of a famous work of literature help people better understand the work.

In the demo version of the game, the player participates in a battle with the king of Norway. In the book, the battle is described for 70 lines by a bloody military man, but you don't get to see it; it's not engaging for modern students. But you need to understand the nuances in the monologue or else you don't really understand the play.

Elizabeth previously found in her research that taking Shakespeare into unusual settings, using the full environment, helped people enjoy it more. They felt inside the story, and they cared more, which allowed them to think more deeply about the text.

While live theatre does not scale, video games do. It's worth noting that video games are not a replacement of live theatre. However, we can use games to capture some of the benefits we get from live theatre, like boosting affinity, critical thinking, and comprehension. Unfortunately, a lot of literature video games are nothing more than a jazzed-up book, a little too true to text rather than just inspired by a work of literature.

Something Wicked was built according to the rules governed by the world in the book. The game mechanics reward making decisions that Macbeth would have made, rather than "playing well." If you don't play violently enough you have to start again. You have to behave with bloodlust and sneakiness.

So far the game seems to be succeeding in its goals. One cool thing, for example, is that older players end up being excited to analyze Shakespeare's text to figure out why the game was designed the way it was (and even to argue about those decisions).

Learn more about Something Wicked and sign up to playtest on the project's website.

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 AnitaB.org'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 AnitaB.org. 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 AnitaB.org website.

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!

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.

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.

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.

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!

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.

 

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.

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

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).

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.

GHC16 / Lyndsay Pearson on Valuing Inclusive Game Design

Invited technical speaker Lyndsay Pearson spoke at Grace Hopper this week about inclusive game design. Lyndsay has, as she puts it, grown up with The Sims, having working on the game in various capacities since nearly the beginning of the franchise. She shared some universally applicable advice on inclusive game design while sharing examples from The Sims.

By Dinosaur918 (Own work)

[CC BY-SA 4.0], via Wikimedia Commons

The first lesson, of course, is that the players are out there. Long gone are the days of believing all players are high-volume males in their late twenties whose central hobby is gaming. With such a huge diversity in players, there's an opportunity to develop games for even more inclusive audiences. To do that, we need to expand beyond the current factors most values in games: time, money, and number of games played.

So what can we do? Respect all players, invite different opinions, and intentionally build relatable experiences.

Respect All Players

Respecting players means truly recognizing them and their diversity. Coming to a game for a different reason that "most" gamers doesn't make you less valuable. Designers should ask themselves: how can I continue to connect with that player and relate to them? First impressions matter, which is why The Sims offered more options for body type and so on in their character creation.

Invite Different Opinions

The thing is that you have to do this even when it's uncomfortable. "We need to help bring people in and help them not bounce out," as Lyndsay puts it.

One example of this is ensuring you tune yourself to cultural sensitivity. For example, the Sims team learned that women were not allowed on game boxes in Saudi Arabia. Despite the fact they really didn't want to, they created a box with all men so that the game could be sold, and still be accessible in all the same ways to people in that country (especially women!).

Another example is religious sensitivity. They thought The Sims was good at avoiding overtly religious objects, but they later realized that the ghosts and voodoo dolls they included in the game also have religious origins. Thus, they realized were actually consistently inconsistent in this area. They had to own the fact they had no clean line and try to make decisions as consciously as possible.

The bottom line is that you need to get uncomfortable with these kinds of conversations. Do know that you get better at it the more you do it, though.

Build Relatable Experiences

Connect, relate, and interact with current world experiences. What's going on in the world that can be incorporated into the game? A nice example is finally incorporating women's team into the FIFA game. When they decided to do that, they became fully invested, considering all kinds of new possibilities, like a player leaving partway through a season to have a baby. The Sims also now has much more fluidity in its gender selection, helping break gender norms as we are trying to do in real life.

---

Lyndsay gave us a lot to think about when it comes to designing inclusive games, but as she pointed out, the lessons apply to all software design. Let's all make sure to keep these things in mind in our own endeavours.

HLF2016 / Spotlight on Preethi Srinivas: HCI Researcher Improving Coordination and Communication in Hospital ICUs

This blog post originates from the Heidelberg Laureate Forum Blog. The 4th Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place September 18-23, 2016. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

Meet Preethi Srinivas, our next featured young researcher in a series about some of the women attending this year’s Heidelberg Laureate Forum in September 2016.

Photo courtesy of Preethi Srinivas

Preethi is currently wrapping up her PhD at Indiana University School of Informatics and Computing and is originally from Chennai, India. She is also a Senior UX Designer at Regenstrief Institute Inc.

Preethi’s dissertation work has the potential for making a huge impact on communication in hospital intensive-care units. Notes made on paper and synchronous communication in ICUs can lead to issues in awareness and coordination. Preethi proposes a method for “rapidly generating, managing, and sharing clinical notes and action-items among ICU providers” as well as a “visual and tactile notifications system that induces minimal interruptions to an ongoing activity.” Long term, her research provides novel guidelines for mobile communication tools for ICUs. She says she is “proud of this little accomplishment although this research is a small, design-based contribution to the medical and HCI communities.”

As for many graduate students, Preethi’s ultimate success comes from learning to embrace failure. She also learned that it’s ok to switch projects if you aren’t engaging sufficiently with your current research direction.

I started my PhD program working on a research project that seemed to work well, but I soon learnt that I was not meant to be working on the project since I did not really find myself interested, even though I was working hard. This experience taught me that one of the huge factors to research is involvement or drive to being committed to a project. I soon moved onto another project that kept me committed, without which I would have never made as much progress as I did.

As someone who switched topics completely between Masters and PhD, and who went through a few project ideas before settling on a thesis topic for my PhD, I can relate to this completely!

Preethi is excited for HLF for the opportunity to interact with some of the world’s best and most passionate researchers. The forum’s interdisciplinary nature is also very appealing. She hopes to receive some great advice from fellow researchers on how to embark on independent research post-PhD, and is “looking forward to making new friends with whom I could potentially collaborate in future.” Plus, she loves to travel, and who wouldn’t want to visit such an interesting city as Heidelberg!

I believe you won’t be disappointed in the city nor the forum, Preethi. Looking forward to seeing you there!

Stay tuned to meet other young researchers, a special post about mentors, and the advice our featured women want to share with others.

The Low-down on Speaking at GHC

So you're speaking at GHC16. What do you need to know? How can you prepare to be the best you can be? How do you calm your nerves?!

Although I wasn't lucky enough to have any submissions accepted to this year's conference, I have spoken at Grace Hopper before along with many other venues. Let me start by reassuring you that this is one of the very best places to present. I have rarely found a more wonderfully supportive audience.

Let's get some of the official stuff out of the way. As a speaker, you need to thoroughly read through everything on the speakers section of the conference website. In particular, note the quick references on the right.

I'd like to draw your attention especially to the Speaker Ready Room info. There, you'll learn about uploading your slides before your presentation, and you'll see a link to the slides template. Please take the time to design your presentation using the template right from the get-go. Trying to shoehorn an existing presentation into the template tends to look unprofessional, and not using the template at all even more so. Also make sure to leave plenty of time to upload your presentation and test it. You'll want to make sure any embedded media is actually embedded, and that your fonts and colours look ok.

The conference website also includes some tips on speaking. I'd also like to share another amazing resource that brings you weekly inspiration and advice on speaking: a newsletter called Technically Speaking. Subscribe now and you will benefit leading up to your talk, and check out the archives as well.

Finally, I have a few tips of my own:

• Design your slides with as few words as possible. Convey the main idea through pictures and a short phrase.
• Add speaker notes into the notes section of the slides. When practising, you can simply read the notes at first. This should make you familiar enough to be able to improvise more day-of.
• Practice in front of colleagues at some point with enough time to receive feedback. Provide them with a written feedback form they can use to give you anonymous ideas for improvement.
• On the day of your talk, arrive in the room early to give yourself time to calm your nerves.
• Make sure you have access to water during the talk.
• Before you start, take some deep breaths, maybe with your eyes closed. Think yoga breathing.
• Invite the audience to chat with you after the talk, and stand somewhere where it's easy for the audience to actually do so.

Good luck with your talk – I'll know you'll be awesome!

HLF2016 / Spotlight on Hana Khamfroush: Research Associate in Wireless Communications and Networking

This blog post originates from the Heidelberg Laureate Forum Blog. The 4th Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place September 18-23, 2016. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

Meet Hana Khamfroush, our next featured young researcher in a series about some of the women attending this year’s Heidelberg Laureate Forum in September 2016.

Photo courtesy of Hana Khamfroush

Originally from Sanandaj in north-west Iran, Hana has a PhD in telecommunications engineering and currently works as a research associate at Penn State University in the United States.

Hana’s PhD focused on applications of network coding for geographic communications in dynamic wireless networks. Her Masters was on reducing energy consumption of routing protocols in wireless sensor networks. Hana’s current work looks at security and recovery issues of interdependent networks. More specifically, she says, “I work on modelling and analyzing cascading failures in interdependent networks and network recovery after massive disruptions.”

Hana’s proudest accomplishment is impressive indeed: she was named as one of the rising stars in electrical engineering and computer science (EECS) by MIT in 2015. But despite such an amazing background, success did not always come easily. It was, at times, difficult to maintain motivation and perseverance as a graduate student.

I think the biggest lesson I learned from my PhD was to stay patient and work hard toward your goals, and be sure that “Hard work pays off.” I learned not to get disappointed by defeat, instead to learn from them and always have hope for better results. In the first two year of my PhD, I was not getting very promising results for my research and I didn’t even like what I was doing. I kept working harder and changed my research topic. The last year of my PhD was the best; I got many papers accepted and it felt like everything changed! I learned a lesson: I am the only one who can help myself, so I solved my problem by finding a more interesting research problem! Don’t wait for others to help you, change your status by yourself.

For HLF, Hana is particularly excited about the positive energy she finds at any conference or academic gathering. HLF is an even more amazing opportunity since she’ll get to meet some amazing new role models. She says, “it is very exciting to meet with those who were internationally known for their scientific contributions, and who actually made a change to the world.” She expects to learn a lot and bring back the positive energy when she returns home.

Hana is also looking forward to meeting other young researchers in her field. If you share research interests, don’t be afraid to reach out and say hello!

Keep up your amazing work Hana, and see you in Heidelberg!

Stay tuned to meet other young researchers, a special post about mentors, and the advice our featured women want to share with others.

HLF2016 / Spotlight on Helen Wauck: HCI Researcher Studying Spatial Skills Training with Games

This blog post originates from the Heidelberg Laureate Forum Blog. The 4th Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place September 18-23, 2016. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

Meet Helen Wauck, first to be featured in a series about some of the women young researchers attending this year's Heidelberg Laureate Forum in September 2016.

Photo courtesy of Helen Wauck

Helen is a PhD student at the University of Illinois Urbana-Champaign, where her work centers on human-computer interaction. Her research, as she explains it, is on the cognitive side of a rather broad field.

I study how to use video games to train spatial skills. Spatial skills are crucial for success in STEM disciplines, so figuring out the best way to train them is very important for lowering the barrier to entry into these fields, especially for populations that typically have lower spatial skills, such as women and ethnic minorities. Some existing commercial games are very effective at training spatial skills (Portal 2 and Tetris, for example), while others, including cognitive training games like Lumosity and Dual N-Back, are completely ineffective. The goal of my research is to determine what specific game features contribute to the effectiveness of a video game for spatial skill training.

Helen's proudest accomplishment so far was to win the "United States' National Science Foundation's Graduate Research Fellowship (NSF GRF), a prestigious fellowship that grants recipients three years of generous funding and international research opportunities." The application process included a proposal for a multi-year research project, and despite not winning the award the first time she applied, she worked hard and won the second time around. As Helen says, "It's really encouraging that not only my advisor but the NSF has faith in my ability to carry out this research topic and that it's worth researching."

Of course, life as a graduate student hasn't been without its challenges. For example, Helen attended a liberal arts college and therefore took fewer computer science courses than many other undergraduates would have. At first, this left her feeling like a second-class citizen in her graduate program, but over time she came to realize that, in fact, everyone has come from wildly varying backgrounds. Even better, she eventually saw how her multidisciplinary background gave her an edge when it came to communicating her research effectively.

Like all participating young researchers, Helen is very excited for her upcoming trip to HLF:

I'm very excited to meet the other young researchers from around the world and hear about their experiences in their programs. Human-Computer Interaction is a very different field from many of the more systems- and math-oriented computer science subfields. The perspectives I get from researchers coming from all sorts of different backgrounds in computer science and mathematics will be very different from the perspectives I usually have access to in my field, especially given the heavily international nature of the HLF. I hope to meet lots of fellow researchers whose experiences can give me new insight into how I might direct my own graduate school experience, and who I can hopefully maintain contact and friendships with after the conference is over! I'm also very curious to hear this year's laureates speak about their research process and how they overcame the challenges that were thrown their way; it's so rare to have an opportunity to meet these incredibly successful researchers face-to-face and hear their personal stories.

Congratulations on your accomplishments, Helen, and we look forward to meeting you in September!

Stay tuned to meet other young researchers, a special post about mentors, and the advice our featured women want to share with others.

How to Be a Leader, Shopify Style

Self-actualization, that thing at the top of Maslow’s hierarchy of needs: “what a person's full potential is and the realization of that potential.” Shopify cares deeply about growth, and aims to be a company where its people reach the self-actualization level of the pyramid. I think that’s pretty special, and it’s just one of the things that leaders need to manage during their time at Shopify.

For the last few months, I’ve been participating in what we call Lead Level Up. I’m not formally a team lead yet, though I have been in a bit of a leadership role and should become a team lead eventually. A lot of what we learned in the all-day kick-off is general enough to share, so I’m going to highlight the things that resonated with me the most. Most of what follows comes from our CEO and co-founder Tobi’s presentation that day.

An interesting fact is that Tobi and his co-founders/early employees didn’t know how to be managers. It was an entirely new skillset. Tobi admits he was not a natural manager; he found it difficult losing the tight feedback loop you get when programming. He admits he fought often with the others in the early days until they sat down and decided to respect each other by committing to being honest and improving their feedback.

Tobi ultimately believes that he was able to improve his own management skills by learning how to better give effective feedback. Everyone is bad at this at first, and there is no limit on how much better you can get. It can be really difficult to take feedback as the gift it is because your ego is so tightly wrapped in the exchange. When I was an instructor at Carleton, I learned how hard it can be to give good, honest feedback, especially if the other party (students, in my case) don’t entirely trust that you have their best interests at heart. I’m now learning to give feedback with radical candour.

A major tool that will help any manager is trust. Trust is more nuanced than a binary relationship. Trust exists between departments, and is fundamental to being highly aligned and loosely coupled (that is, fast-moving teams with high autonomy working toward common goals). When you start seeing a large amount of process being introduced, it’s usually because there is a lack of trust. Process is a prescriptive solution to a problem that isn’t terribly intuitive. It’s a bit like baby-proofing.

After trust is established, the manager’s job is to make their team better every day. If the team is not getting better, it is getting worse. Questions a manager can ask include whether they can remove any ambiguities or dependencies, have they helped someone have a breakthrough, etc. Focus on the high leverage activities that yield the greatest output for your team. Teaching, for example, is high leverage in all its forms. One-on-ones, while important, may generally not have high leverage.

Speaking of one-on-ones, how do you make them effective? Have them at least once a month. Take notes. Find your own style. Use them as a learning opportunity, and a chance to understand the other person. There will be hard situations, and they are only solvable if you have an extremely good read on all involved. Crucially, you must give good, honest feedback. And if you ever hear during a one-on-one that you have made a massive, positive contribution to someone’s life, then you know you’ve made it as a manager.

As mentioned above, managing is an entirely new skillset. Become well-rounded, focus on personal growth, read a lot (e.g. High Output Management and Thinking Fast and Slow). Become the guidance counsellor, the coach, the shrink. Help get yourself and your team to self-actualization, and you’ll do just fine.

Google I/O 2016 as an Anita Borg Scholar

Back in February, I ran an event to celebrate Anita Borg's birthday. I along with some Shopify colleagues focused on students not majoring in computer science; we invited them for a short talk, organized mentoring activity, and coding workshop. I got the idea from the alumni network of past Google Anita Borg Memorial Scholarship winners: we were invited to run events all over the world. Google program managers picked the most impactful events from each region, and the winners got to attend Google I/O all-expenses-paid. I was one of the winners!

I'm not a developer within the Google ecosystem, though I do use Google products to run my life. (Even more ironically, my husband is currently an Android developer.) As such, my experience of Google I/O wasn't going to be based on the talks per se. Instead, I focused on networking while catching a few talks that seemed interesting and relevant to my group back at Shopify.

Most of the AB scholars attending for the same reason as me stayed in the same hotel, and I was really grateful to be able to head to the conference grounds with one of them after arriving Tuesday afternoon (thanks Saboya!). We got our conference badges and then headed to the Women Techmakers dinner around the corner. There, I met a bunch of wonderful women, including some as passionate as me about computer science education. I also met up with some women with whom I submitted an (unsuccessful) Grace Hopper panel proposal. The event was lovely and I'm very appreciative of the folks that put it on.

Fellow scholar Saboya before the delicious food was served

The next morning, I/O proper began. Our group of scholars was extremely lucky to be given reserved seating at the opening keynote. Hosted at an amphitheatre, half the audience was in the direct, late morning sunlight for two full hours. We were in the front half of the seating area and therefore shaded.

The keynote itself had a really fun opening with animation and music that was totally my style. I wasn't terribly inspired by CEO Sundar Pichai, and it took a while to see any women on stage. But there were a few interesting announcements like Google Home and clever uses of AI in messaging, even if I still don't see how changing the font size in instant messages was ever considered note-worthy.

After the keynote, there was a flood of people having no idea where to go to get lunch food. The conference had to feed us because there was nothing else available anywhere nearby, but being so incredibly hot and sunny, it was not exactly comfortable to eat most places on site. Our group of scholars and friends managed to find a tree to sit under, which was again quite fortunate.

This was the best we could do for lunch. Many were stuck in the sun.

You may be starting to see a theme here about the sun. Many folks, including my work colleagues, were feeling sick from being in the direct sun during the keynote, and it was difficult to escape it the rest of the conference as well. The activities were all spread around the amphitheatre's parking lot with little shade available.

Talks were in air conditioned tents, but there was grossly insufficient seating in them, so long lines started forming an hour or even two before the most interesting talks. I was lucky to get into a couple of the rather popular virtual reality talks without dying of sun stroke, which was nice. But I only attended three talks in total because it just wasn't worth standing on pavement in the sun. Frustrating to consider that people watching the conference from home for free got better access than those spending hundreds of dollars to be there in person.

I spent most of the conference chilling in the shade, but because of the reasons I was there, I didn't mind. I had opportunities to chat with work colleagues as well as fellow scholars and new amazing women I tried to recruit to Shopify (still hoping to hear from some of them!). I'll never forget the many times I got to talk CS education with some truly amazing people.

Plus, you can't complain about the parties, assuming you weren't too exhausted by the evening to attend them!

Our scholars group got to meet up several times for meals at the neighbouring Google offices, and on the last day of I/O we gave presentations about the events we ran. So inspiring! I am really looking forward to keeping in touch with the group, and seeing how we might make an even bigger impact together.

All in all, despite the griping about I/O (no device giveaway!) and the very real issues with this year's venue (your take-home is heat exhaustion!), I'm very grateful I got to attend and that I got a lot out of the trip. Can't wait to meet up with some of the scholars again at Grace Hopper!