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.

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.

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!

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.

Mastering Difficult Conversations

Do you dread bringing up a problem in your relationship because you know your partner will be blinded by emotion? Are your 1:1s at work just happy recaps of your weekend because nobody wants to bring up the hard issues? Sometimes conversations are just plain hard, but it is possible to learn how to have them effectively. I've personally learned a lot from Difficult Conversations: How to Discuss What Matters Most, and have even put some of it into practice already.

The book introduces three conversations that are really taking place in a difficult conversation: what actually happened, how feelings factor into it, and how the participants' identities might be affected. When you're about to embark on a difficult conversation with someone, you should first walk through each of these three conversations to sort out where your story came from as well as the other person's, to "explore your emotional footprint," and to reflect on what's at stake in terms of how you see yourself.

Then, you need to determine what your real purpose in the conversation is. Generally, it's a good idea to come from a place of learning, which means keeping your mind open to the fact that you could have been wrong about how you viewed the situation.

When it's time to talk, you want to start from the "third" story – that is, you need to "describe the problem as the difference between your stories." You have to pretend you're an innocent bystander, and invite the other person to become your partner rather than your adversary in sorting out the problem in front of you.

During the discussion, you have to be an amazing active listener (so much easier said than done!). Acknowledge, paraphrase to check understanding, question...and continually reframe to keep on track. Then, finally, you can get to the problem-solving stage.

A few key takeaways for me:

• Never lay blame; instead, talk about contribution, and try to reframe the conversation to help the other person do the same. Every problem arises because of contributions from both sides, even if the split is 95% to 5%.
   
• Pay special attention to feelings. They are always there, and they can get really complex. Even in a professional situation, it is ok – and important – to discuss how various actions and outcomes make you feel. It can help to sort through feelings before the conversation so you can unpack complex bundles of emotions and better explain your perspective.
   
• Be mindful of your identity, and how it has been affected by the problem you are facing. The reason that the conversation is so difficult might be because you have to face the fact that you may not be acting in alignment with how you see yourself.
   

I've used the ideas in the book already to talk through how a friend might be able to approach their next 1:1 at work. The feelings story was of particular importance in this case, and not something that my friend would have talked about normally.

I have also found the knowledge useful when faced with a difficult conversation started by someone else. Where I might have normally become defensive and frustrated, we were able to resolve our problem somewhat quickly. (Now I just have to make sure I don't do the same dumb thing again.)

I think this book would likely have something useful in it for just about anyone. If you're in a leadership position of any kind, it will be all the more valuable.

My Nonlinear Career Path

I've had a really nonlinear career path. One step forward, two step sideways, new goal, start it all again...

My interest in computers started at a young age. I was lucky that my dad, a government worker, was able to bring home the computers his office was done with. As a result, I have had access to computers, and even had a computer in my own room, from a young age.

I've always loved to create with computers. From writing stories to designing newsletters for my Guiding troupe, I was always making things. Even today, I make digital scrapbook pages!

In high school, I started becoming more and more curious about how things work "behind the screen," so to speak. How do you write code to make a word processor? What's the math behind vector graphics? How does computer hardware, at the lowest level, add two numbers?

I decided I wanted to take computer science in university so I could learn all this and more. I didn't learn how to program in high school; instead, I took drama and music while I still could. But I was pretty sure I'd love the world of code whenever I eventually entered it.

Turns out I was right. I also loved working in the industry during my co-op terms. One of my jobs was at Ross Video, working on software for a video production switcher. The other was at Corel, where I worked on the text engine for Corel DRAW, software I had used for many years in my personal projects.

Nearing the end of my undergrad, the most difficult decision I faced was which of these two companies I would try to work at full-time. I never thought I'd do anything other than go to industry.

I was going to be a software developer.

Until, that is, a professor approached me and convinced me to consider graduate school. The catch? The application for the big scholarship was due in a week. Well then.

Image adapted from Ivory Tower by OfTheDunes

I applied, and I got the scholarship. So I went to grad school for my Masters. I had a great time, and even got my start in outreach, but learned something very important: I didn't care for the low-level, experimental nature of my thesis topic, and wished I did something more applied.

I decided to continue on to my PhD, choosing storytelling in videogames as my thesis topic. I engaged in educational games and computer science education research on the side. I also took the opportunity to gain more teaching experience. I eventually realized that education was my passion and I wanted to teach.

I was going to be a university instructor.

After some contract work, I got a two-year term position as a full time faculty instructor. I made an impact with some innovative course designs and a lot of hard work in outreach and diversity. But when I tried to get a permanent instructor job, I missed it by a hair. Although I was not yet finished my PhD, I didn't really fancy going back to being a full-time student. Instead, I figured: why not go back to industry and be a software developer again?

So off to Shopify I went. I joined the Home team, working on the first page merchants on the Shopify platform see when they log into their admin. I learned both Ruby and Rails, and finally had a chance to try real-world web development.

I quite enjoyed working as a developer, but it was a step sideways from my goal of teaching. However, in the fall, an opportunity arose.

I was going to jump back into education once again!

Starting this past January, I became Manager of External Education Programs. I'm working on some really exciting education projects, including a sponsorship of the Ottawa Network for Education's AppJam. I get to create curriculum, teach, and even create a team of similarly passionate folks here at Shopify.

So while I have taken some steps back in my career, and some other steps sideways, I find myself feeling very fortunate to end up where I am now. So if you ever find yourself on a really windy career path, don't fret: go with the flow, and see where it takes you. You might find yourself ahead of where you expect, even if it you hit your goal at a bit of a strange angle.

On Completing a PhD Proposal

In Mid-December, my PhD thesis proposal was accepted, leaving me ABD ("all but dissertation"). It was quite the journey to get there, and I have some hopefully useful insights to share from the experience.


if you've ever wondered... / toby

If you're curious, much of the information about the doctoral proposal for our School is likely widely applicable. We are supposed to finish the proposal within 6 terms of registration, but in reality that's not very common. Many students do their proposal much later in the process, after completing most of the work needed for the thesis. We tried to do my proposal a bit sooner so we could get some solid feedback earlier in the process. I'm really glad we did, but more on that later.

The Document

The first step of the proposal is to write the document. I started working on this during the summer while also developing a prototype game using my interactive storytelling framework, then part-time in the fall when I went back to teaching. However, several iterations were required, the first being on the general structure of the document. This is what we settled on in terms of chapter layout:

• Introduction
• Background
• Project Goals and Design
• Work Completed
• Future Work Plan
• Conclusion

I put most of my effort into the second and third chapters. The background is where you have to not only show that you have a good grasp on what's out there, but also clearly show the gaps you are trying to fill. I used the Project Goals chapter to really spell out what I was trying to accomplish, and describe the storytelling framework we had published at Foundations of Digital Games.

Both of these chapters needed multiple iterations even after I fixed the overall structure of the document. We tried to bring them as close to final thesis-level quality as we could in the time we had, hoping we could reuse a lot of it again later. This is what I spent most of the fall doing.

My process for the background section is interesting to look back on: although I knew from the beginning what the text in that chapter had to accomplish, it still took me three to four iterations to get there. I fixed one problem each iteration. First, I improved the organization of the chapter so each major section had a clear organizing principle. Then I analyzed the literature more critically, then more effectively highlighted the gaps. I reorganized the sections again, and finally added better conclusions to tie up each section. The final product actually ended up being decent!

In some ways I would have liked to spend more time on the document. I noticed a few too many problems when re-reading it a few weeks after giving it to the proposal committee. For example, I cut back my introduction just before submitting, and later I realized just how... bad it was. But, to be honest, the end result — passing the proposal — would not have changed. Sometimes you have to know when to stop, even if that reason is that you simply can't spend any more time on it.

The Oral Examination

Three weeks after submitting the document to the committee, we had our proposal examination. It started with me giving a 15-20 minute talk, followed by two rounds of questions from the committee.

When preparing for the talk, I re-used a technique that helped me with a past conference presentation: I wrote a script to figure out what I wanted to say. After some feedback from my supervisor on that, , I ended up iterating on that, too.  I ended up finishing my slides a little too close to the actual presentation time. I had originally hoped to run through the talk at home at least a few times (once with my husband), as well as take notes about my background section and key project information so I would be really well prepared for questions. I did none of that. Although I still passed, I think those with some more time might really benefit from trying these ideas.

These are the slides from my talk, which give a decent enough idea of how I structured it in the end. As you can see, I centred the organization around the proposed contributions of the thesis.

Because of my lack of planned practice, I ended up being pretty nervous for the talk, and it showed.  Which is a shame, because I'm generally pretty good at presentations and keeping nerves in check.  But I guess it turned out well anyway, since some of the committee understood what I was trying to do better after the presentation.

The question portion of the exam was... interesting.  I feel like I was barely asked any questions at all.  I mostly got feedback about the proposal document (lots of constructive criticism!) and suggestions for where to go from here.  The committee suggested some ways to narrow the scope of our work and suggested ways to avoid having to make an entire game to test our designs.  This was incredibly relieving! Nothing I've done so far has been wasted effort, and future plans now look more achievable somehow.  The plan is to meet back up with the committee in six months to go over an updated plan since things are likely to change enough that we don't yet know what the final thesis will look like.

Based on this outcome, I am very glad we did an "early" proposal.  I highly recommend biting the bullet and proposing your thesis as early as you can.  Your supervisor should know if you've got enough to pass.  Get valuable feedback early and perhaps even save yourself some work, as happened in my case.

How Beyond the Code Attendees Found Their Spark with Anita's Quilt

Recently, Shopify put on a super cool conference called Beyond the Code.  Hosted at the Ottawa Convention Centre, the event's main goal was to highlight the role of women in technology.  All types of folks were there,  from devs to designers — and the audience was more than half female!

I was lucky enough to run a lunchtime workshop called Find Your Spark with Anita's Quilt.  Some of my fellow Quilters developed this workshop, so I had a good base to start from.  The general layout we used was to sort people into tables as they came in (we used chocolates!), then have them introduce themselves to their table mates, pick and read a story from the Find Your Spark! page, and  talk about the stories using the discussion questions we provided them (now also on the Find Your Spark! page).  After the discussion, we had a few tables share their biggest takeaways (there wasn't enough time to go through all tables let alone all questions).

It was an enjoyable way to spend lunch and meet some new people, but the thing I was most excited for was to hear what the participants actually got out of reading the stories.  I have been working hard to curate a lot of the great content on Anita's Quilt, so of course I wanted to know whether it has been meaningful and even useful to readers.

I was really impressed with the insights that came out of the discussion.  A few key issues were brought up:

• One group noticed the prevalence of the imposter syndrome, that feeling you get that makes you think you don't deserve to be where you are and that everybody's going to find out any day now.
• Another group pointed out that a lot of the stories are about how somebody corrected course when their life got back on track.  Realizing this allows the reader to see how others did in case they ever face the same situation.
• The fear of failure was a big theme.  That lead to discussion on the importance of a support network of friends, family, and mentors/sponsors that can help you lose the fear of failing.
• The last group brought up the issue of the kind of language women tend to use, and how it often portrays less confidence, or attributes success to factors outside of their own good work.

It's almost as though we went through a checklist of common issues facing women in tech!

If all this sounds intriguing to you, or you could just use a really good story to get inspired, be sure to check out the Anita's Quilt Story Campaigns archive,  or follow the Find Your Spark! model to choose a story and think about the discussion questions.  Let me know what you get out of the stories you read!

Be a GHC Community Volunteer and Change Your Life

You should sign up to be a volunteer community note-taker or blogger by our new deadline of September 8.  It could change your life! Seriously!

Blue Jelly Social Media Icons / WebTreatsETC

I started attending the Grace Hopper Celebration of Women in Computing in 2008, and have only missed a single year since (I was too pregnant to fly).  I started off as a volunteer blogger, like you might be considering doing now.  My good work opened the door to becoming lead blogger and eventually co-chair of the Communities Committee.  It opened up a lot of opportunities, including joining the Advisory Board for the Anita Borg Institute, who puts on the conference.

Now, your path will likely be different than mine, but I hope you are convinced that good things can happen.  Here are some other benefits to becoming a volunteer:

• Provided you contribute three session blog posts or notes on the wiki, you will get a ribbon to wear on your badge.  Ribbons are coveted at the conference, and the more you have the better!
• You were probably going to blog, tweet, and pin anyway, so why not get recognized for your efforts?
• Blogging or note-taking is a great way to give back to the community if you've been funded to attend the conference.
• You will make some wonderful new contacts.  Some will be very useful professionally, and some will become great friends.  It's quite fun having someone to visit no matter where you travel in North America!
• You can feel good about bringing the conference to those who can't make the sessions they want to, and those who can't make it to the conference at all.

Ready to sign up? Here's the official info:

Every year, GHC has a vibrant and active community of bloggers and note-takers. With an amazing schedule this year, we do our best to cover as many sessions as possible. How about taking notes or blogging about a session? Join other GHC community volunteers to capture presentations, workshops, poster sessions and more.

Sign Up To Volunteer

Hitting a Block and Feeling Stuck

I recently received an email asking whether I've ever faced programmer's block.  The emailer was referring to those times you sit and stare at a problem but never make any progress.  You feel stuck and, in some cases, just give up.  How does one get past that?

Stupid Computer!!! / f1uffster

The good news is that I think all programmer's face this feeling at one time or another, and most likely, they feel it rather often.  The thing that changes with experience is usually the level of complexity of the problems causing stuckness, not whether a programmer will get stuck in the first place.

That might seem really depressing, especially if you hear this after your first extremely frustrating moment of stuckness.  But it's not all bad news.  As you learn more strategies for getting unstuck, you don't stay stuck nearly as long.

Some strategies: learn to experiment.  When you first start programming, many tend to be a bit afraid of tinkering with code, trying different things with an eye toward understanding better what's going on.  It's not just trial and error; you have to be strategic.  You have to take the time to understand why something finally works, even if you hit upon the answer randomly.

To improve your experimentation skills, you need to learn to debug.  Whether you just print the values of variables at key locations or use a fully-featured graphical debugger, learn how to display as much as you can about your code so you can ensure your mental model of it is correct.  You must learn techniques that help you first narrow down where the problem is, then you can tackle figuring out what the problem is.  For example, you might narrow down that a problem appears inside a loop.  From there, you can start printing out the variables you are changing in the loop to see if they are what you expect.

As you learn more and more about programming, algorithms, data structures, and so on, your toolbox of problem solving techniques grows and grows.  Things that seemed so hard in the beginning are now no problem to spot, all thanks to experience.  Of course, new problems are introduced, but you know how to tackle them, thanks to your ability to experiment and debug.  It takes time, but damn, it feels good when you finally get unstuck again!

If you'd like to read about some more specific programming problem solving techniques, check out Think Like a Programmer, which I've reviewed here.  (I wasn't compensated to say this - I just really like the book!)

One Way to Study for Exams

For both my classes, I put together a study guide that included some general tips on studying as well as what topics to focus on.  Since the general advice works for many classes, I figured I'd share it here.  It's based on what I used to do as an undergrad.

York College Library Study / CUNY Academic Commons

A good strategy is to create your own study notes, preferably on paper (manually writing will help you remember what you are thinking about better).  Here’s one possible way to make these notes:

• Go through the course learning objectives, slides, and assignments, and make a list of key concepts that you should understand.
• On a separate piece of paper for each concept, write the concept at the top of the page.
• For each concept, write a general description of what the concept it about.  Try explaining it as if you were teaching someone who has never seen it before.
• Look for ways the concept has been used in class.  How does it apply to the topic’s contextual question? What other contexts did we apply it to (in code, assignment questions, Poll Everywhere, etc)?

A few general studying tips:

• Find ways to stay relaxed.  High stress will make your studying time far less effective. (Don’t leave it to the last minute!)
• Try to stop working on your notes before your normal bedtime the night before the exam (if not sooner).  Get a good night’s rest - this really does matter!
• If you have time, you can spend some time memorizing some of your notes.
• On the day of the exam, review your notes.  By now you don’t want to be still trying to understand the concepts or memorizing key points if possible.

Be sure to state any assumptions you make when answering the questions.

Be strategic rather than starting at the beginning and working your way through.  Read all the questions first, then start answering the questions you are most confident about.

Gearing Up for Grace Hopper Next Week

For me, today is all about getting ready for the Grace Hopper Celebration of Women in Computing next week.  As usual, I'm involved with the conference in many different ways, from presenting a poster and talk to being a member of the Communities Committee.  Plus, I'm organizing a group of five other Carleton students who are attending for their first time!

I was thinking about all the different posts I've made about GHC over the years, and realized that I probably have a few that would be useful to attendees this year, too.  So here's a round-up of my most useful posts as we all gear up for next week:

• Getting Ready for a Conference
• Making the Most of Conference Travel
• Presentation and Communication Skills in Computer Science (check this out if you're giving a talk this year!)
• Dancing with Hundreds of Technical Women at Grace Hopper (aka one of the things I look forward to most!)
• When Having a Lot of Facebook Friends is Good (good ways to network with the attendees you meet)
• GHC09: I Am A Technical Woman! (a great video to get you in the mood)

Designing an Intro to CS for Non-Majors: From Objectives to Problems

When working on my introductory computer science class for non-majors, I started with the objectives.  From there, I thought about the types of assignments and tutorials I wanted, but mostly moved on to figuring out the actual lecture content.  I like to organize my courses by specific problems in a way that is loosely related to inquiry-based learning.

With this approach, I think about the kinds of things that my audience might find useful or interesting.  The earlier problems tend to be more on the interesting side, but by the end the problems should be more relevant to the students' fields.  During lectures, I will introduce the problem by showing the completed software, then go step by step in showing how that software is built.  In the process, new concepts need to be introduced.  For example, when we start to get bored of repeating certain values all the time (and start to run into errors when changing these values), I'll introduce variables.

The best part about having my learning objectives done first is that I can use them to make sure I've hit all the main points within these problems.  As I write out my step-by-step outline, I highlight key words that are colour coded to the objective they relate to.  I imagine this will also help tremendously as I move on to writing the code and creating the lecture slides and peer instruction questions.

Here's an example of the second problem's design for this course:

Another nice feature of the problem-based organization is that I have a natural way to organize the content (such as slides, code, and other resources) in our online learning management system.  I haven't tried this before, so I don't know how well students will like it compared to, say, a week-by-week organization.  I should mention that I am also including tables of resources according to topic (e.g. variables, functions, good programming concepts, etc) as well as by problem, so hopefully this will help.

With all of this laid out, it will be much easier to fill in the details.  That's the most fun part!

Designing an Intro to CS for Non-Majors: Starting With the Objectives

I have been working on my course design for my introductory computer science class for non-majors.  It is taught in Processing and covers all the basics of programming and computational problem solving.  I have been keeping the idea of backward course design in mind in that I am starting with my learning objectives and working from there.

via Development Phase in Instructional Design

This approach is turning out to be helpful for several reasons.  For one, I wanted to organize the content into 8 or so example programs that will hopefully be of interest to the target students.  Each program will be demonstrated first before I walk them through how it's made via live coding.  As certain concepts are needed, the coding will pause and we will discuss the concept in general and in the specific context of the program.  I also intend to have at least one peer instruction question per lecture period.  Having a detailed list of objectives is helping me ensure I hit all the main points in the planning process.

Beyond this, as I have found when teaching as a contract instructor in the summer, you can give your learning objectives up front all you want, but it doesn't mean students will remember them or see how the course material connects to them.  This year, I plan to colour code the objectives and explicitly link to them during every lecture and in every tutorial and assignment.  I am hoping that this will make the course more clearly interconnected and help students organize the content in their minds as we go.

Finally, always linking back to the objectives will help me prove to students (and know for myself) that everything we do is relevant to the desired outcomes.  Nothing should feel like busy work!

If you're interested, the current version of my objectives for this course are below.

By the end of the course, you should be able to...

• Understand what computer science is, and how it can help you solve problems in your field.
• Learn how to use Processing to create visual programs of varying types.
• Explain these basic concepts of programming to somebody who has never programmed before:
• data types (numbers, Strings, etc)
• variables
• functions
• Booleans and if statements
• loops
• arrays
• objects
• Solve basic programming problems by working with:
• searching and sorting algorithms
• using simple data structures
• dynamic memory
• recursion
• Develop good programming practices in the areas of:
• breaking a problem down into smaller pieces
• testing
• debugging
• code reuse
• Learn to approach programming problems with the following values:
• a desire to experiment
• the confidence to make mistakes and try again
• the instinct to consult documentation and seek solutions yourself before asking for help

Making the Most of Your Messaging in 'Women in Computer Science' Outreach

If you've ever done outreach with girls to try to get them into computer science, you may have wondered what the best way to do it is.  After all, we've been at this a while, and yet we haven't seen the level of progress we had hoped for.  What is going wrong?

 Confused Owl / ~Phee

I have a formula that I've used in my outreach for the last 6 or 7 years now.  It goes something like this:

• I introduce myself with fun pictures of my family and hobbies.  I also include a photo of me at the Golden Gate Bridge so I can talk about how companies like Google support women in CS through scholarships and gatherings.
• I ask the girls what computer science is, then explain that it's really all about problem solving.  I go through several domains to show how computing is connected, and if there's time, I ask them for their hobbies and give some possible connections there.  I also show a video from University of Washington on various pathways in computer science to drive home the point that CS is really diverse.
• Our discussion then turns to the issue of women in CS.  I show some graphs that illustrate the problem, then ask the girls to discuss three questions in small groups before we bring it up with everyone: (1) Why don't girls go into computer science? (2) Why is this a bad thing? (3) What would make you interested in trying computer science in high school or college? This is followed by the great little video on women in CS from Google.
• Finally, I do a hands-on activity to showcase a real computer science problem (typically, a CS Unplugged activity).

This formula has served me well.  In my mini-course, I have this discussion on the first morning of five full days of learning about computer science and videogames.  I do pre-course and post-course surveys to see how the girls' attitudes change, and generally the trend is positive.  Even when they aren't sure about CS being a good career for them, they are interested in pursuing some courses in the future.  (You can see some results here, here, and here.)

But is my approach the best it can be? Will it encourage the girls to stick with CS even if they do decide to pursue it somewhere they are likely to be the minority?

My section on the 'women in CS' issue has been questioned a couple of times.  In the first, Barbara Ericson mentioned that when they tried to counter stereotypes, they actually ended up reinforcing them, causing a decrease on the number of girls who thought they could succeed at computing.  More recently, Jim Davies pointed me to research about normative behaviour, explaining that by pointing out the problem, people are more likely to focus on that and behave the same way.

Obviously, these two things had me a bit concerned, and got me wondering if I should be dropping that portion of my outreach altogether.

But I knew I had a purpose for talking about the problem.  It would feel disingenuous to ignore it altogether because I think most people realize it's an issue; however, if doing so improves our results then it may be worth it.  Another reason I do it, though, is based on the fact that I am not only trying to change a current opinion about the field.  I want to make sure that if I can convince them to further pursue computer science, they will not leave again as soon as they run into the issues that might have kept them away now.  In other words, I want to prepare them for what may come next.

Based on this, I knew I had to dig deeper so I could try to modify my approach instead of dropping that section altogether.  I found the research that Jim was talking about: a paper called Managing social norms for persuasive impact.  It describes a study on what type of messaging is most effective when trying to convince people to behave a certain way (in this case, to stop people from stealing wood from a petrified forest).

There are two main ways of illustrating the type of behaviour you want from people.  You can use descriptive norms, which make use of what people are currently doing.  Public health campaigns use this often: "more than 3 million youths in the US smoke and ... 3,000 become regular smokers each day."  Alternatively, you can use injunctive norms, which focus on what people ought to do.  For example, "don't leave your campfire."

Previous theories as well as this particular study have shown that the most effective type of messaging is not descriptive, but injunctive, for the reason Jim mentioned above.  Further, it is much more effective to use negative wording rather than positive (e.g. "don't leave your campfire" vs. "stay with your campfire").  This is interesting given how many campaigns meant to persuade people ignore this advice.

In my case, it seems clear that focusing on the actual number of women who don't go into computer science is a mistake, given the descriptive nature.  The girls in my audience may focus on that and think, "well if no other women go into computer science, why should I?" The follow-up discussion may counteract that, but why risk it?

If I still want to address the issue in some way, I need to find an injunctive way to do it.  I think it may be possible to do this by focusing on what we want the girls to do: try computer science.  A negatively worded question I came up with is this:

What would stop you from trying and enjoying computer science?

I think this avoids the issue of focusing on women who don't go into CS, yet allows us to explore the issues they might face later on.

What do you think? Is there a better way to approach this problem that fits with the research? Where can you switch your own messaging from descriptive to injunctive?

Active Learning in Large Lectures

One of my (self-assigned) tasks lately has been to go through my teaching notes before I start planning my fall courses.  The latest topic I dug into was teaching interactively in large lectures.  This is especially relevant because I am a strong believer in active learning, and I'll have 200+ and 400+ students in my classes this fall.

That Huge Lecture Theatre! / teddy-rised

(Carleton doesn't have anything quite this big!)

Your first thought might be that I'm crazy.  Interactive lectures don't seem to be very common even in classes of a more manageable size.  However, some computer science professors have been working on ways to engage their students since the early 90's.

For example, Jeffrey J. McConnell's paper on Active Learning and its use in Computer Science was published way back in 1996! His intro does a good job of explaining why active learning in lectures is worth the trouble:

Active learning gets students involved in activity in the classroom rather than passively listening to a lecture. This activity can be reading, writing, discussing, solving a problem, or responding to questions that require more than factual answers. The idea is to get students thinking about the material. This is important, because students who are passive have a decline in concentration after 10-15 minutes in a 50 minute lecture.  Further, the act of learning is not passive. ... By carefully involving the students on [the] path to knowledge, we can increase student depth of understanding of the material, increase student comfort with the material, and improve student confidence.

Ryerson University has a decent little handout on engaging students in large classes.  It's not computer science specific, but all of the ideas are applicable.  For example, think-pair-share is probably more commonly used in less technical courses, but there's no reason you could not apply it to algorithm tracing or having students predict the output of a code sample.  There are also many opportunities for asking conceptual questions in our field.  The handout also has some good advice for making the course material relevant to students.

Carleton College has a great resource on interactive lectures.  It emphasizes the need to plan ahead carefully, deciding on the learning goals for each interactive technique incorporated into the lecture as well as the engagement trigger that will lead into the activity.  There are many useful sub-pages to explore here, with the section on Managing the Large Enrolment Course being particularly relevant to this discussion.

One of the techniques I hope to use will rely on enough students bringing their laptops to class.  I would like to design the progression of my programming lectures such that I can build some knowledge with demos and slides, then give students a mostly-complete piece of software that they will add code to based on what they just learned.  After a few minutes I would demonstrate a possible answer with live coding.  I tested this approach with a guest lecture I did last year, and it seemed to work well, though there were far fewer students in class at the time.  An alternative would be to come up with some paper-based equivalents like code tracing or pseudo-code sketching.

What sort of active learning techniques have you used in your lectures, big or small? Any tips for making them work well?

Working With Google Spreadsheets Data Directly

On Wednesday I talked about assigning numbers to my princess-and-dragon story.  I have all my data in an easily parsable format in a Google Spreadsheet.  I decided to use Python to do my story-related computations because of the fast start-up time and the existence of the Google Data Python Library.

Things started well enough thanks to a decent quick start guide, even though I've only used Python a few times before.  I was able to connect to my spreadsheet without issue and start working with the spreadsheet's feed.

But from there things got... complicated.  The quick start guide didn't cover what I needed to do, and I kept getting referred to the spreadsheets API that made mention of other languages, but not Python.  This isn't the first time I've found documentation by Google to be lacking in some way.  I could probably figure things out eventually (perhaps by looking at the source code), but I didn't really want to spend that much time on getting the data - I would rather spend time processing it!

Luckily, @ArcTanSusan and @sharonw gave me a great suggestion on Twitter: gspread.  It was made for Python specifically, has good documentation, and offers much simpler code for doing what I needed to do.  Sign me up!

Making the switch saved me a bunch of time in the end.  The moral of the story: use gspread to work with Google Spreadsheets in Python, and search for alternatives before just using Google's stuff.

My Beautiful GRAND Conference Poster

I'm a strong believer in creating conference posters that look good.  If they have a striking resemblance to printed papers, in my opinion something has gone really wrong.  With that said, I have to say I had a lot of fun designing my most recent poster.

Although this image is slightly out of date from the final print version, it gives a good idea of what I was going for.  You can get the gist of the research by looking at it, but it does not contain all the information a paper would.  That's what the poster presentation itself it for: I will have the opportunity to discuss the work more deeply.

There is no reason whatsoever that a poster can't be both beautiful and functional, so I encourage you to see what you can come up with the next time you create a poster! If you have an example to something you're particularly proud of, I'd love to see a link in the comments.

Edit: You can now check out the high resolution PDF of the poster if you'd like.

Motherhood, Tech, and Leaning In With Marissa Mayer

Recently, I happened to start looking at some of the stories featured on the new Lean In website and came across Marissa Mayer's.  For all the interest and controversy she's drummed up in the news lately, I quite liked hearing her perspective on joining Yahoo! when expecting a baby.

Fortune Most Powerful Women Dinner With Marissa Mayer / Fortune Live Media

Although she'd received offers like that of Yahoo!'s before, this time was different.  The company was a perfect fit for her experience.  But as she says, "...it wasn’t a foregone conclusion that I would or could make it work when I got that first phone call. At the time, I was pregnant, and I was thrilled."

Motherhood is an oft-discussed topic for women in tech (and probably women everywhere).  It can be difficult to be a pregnant woman among many men who don't necessarily understand what comes with that.  Equally daunting is the prospect of taking time off for maternity leave when you'd be one of the few to do that in your company or perhaps in your position.  (If there were more women in the field, it wouldn't seem like an uncommon occurrence.)

Mayer had been looking forward to a six-month maternity leave with Google, way longer than most Americans can even dream of.  By taking the CEO job, she would cut her leave down to almost nothing.  "The responsibilities were too big, and time was of the essence—it just wouldn’t be fair to the company, the employees, the board, or the shareholders for me to be in the role, but out for an extended period of time."

Did she find that motherhood has hurt her ability to be CEO?

I’ve come to realize that being a mother makes me a better executive, because motherhood forces prioritization. Being a mom gives you so much more clarity on what is important. I’m very close to my own mother; she has always been my most important role model. I’m grateful to her and to my father for a lifetime of their love, attention, teaching and sacrifice. Over the past five short months, my appreciation has grown for all parents, especially those balancing work obligations, because I know they have that same clarity of dedication and purpose.

Clearly, it's not an issue.  Granted, she has much money at her disposal to help keep her personal priorities.  However, families around the world have been figuring out many different ways to make it work for many years.  Money might make some things easier but it's not the only answer.

So can we stop bringing in the pregnancy and motherhood issue into discussions of women in tech (and other) companies? It's not like we ever do the same thing for men with young families.

My Secret to Surviving Grad School With a Baby

When I reflected on all that's happened in the last year or so, I didn't mention how I managed to do it.  My secret? An excellent support system!

I'm really lucky that both my and my husband's parents live near us.  I'm even luckier that three of them are at least semi-retired and willing to watch Molly a few hours a week.  So when I need to be on campus (just once a week last semester, but three times this semester), one of them is usually able to come over to be with Molly.  In addition to that, my dad is able to be there to distract Molly once in a while so I can work without interruption.

Sometimes people ask why we never moved away to California or Seattle to work somewhere like Microsoft or Google.  This is the biggest reason why - family is really important to us in many ways.  I love that they are willing to be babysitters, but I love even more that Molly gets to spend so much quality time with relatives, and not just strangers.  I figure we can move somewhere cool once our kids are older and perhaps even moved out on their own.

If you have or are considering having a baby in grad school, think about who your support system is.  It might be family, but it could also be a strong network of parent friends you can share childminding duties with.  It could even just be an excellent daycare you know you can trust (perhaps you'll even become part of a lovely community surrounding it).  Who else might you be able to count on?

Whoever it is, this to me is a big part of surviving grad school with kids.  Don't go at it alone.