Teaching Soft Skills

I think I write about this a lot because I think it’s honestly the most important thing we can teach.  Soft skills mean different things to different people.  Some think of them as skills like critical thinking and collaboration.  Some think about them as being resilient (or having grit).  Anya Kamenetz outlined some of these different skill sets in an article a few months ago.  Likewise, schools have implemented programs to specifically teach some of these skills.  Louisville Collegiate School created The Edge, outlined in this NAIS article with classes taught by the Administrative Team.

Recently, we’ve been updating our standards for our curriculum map.  As part of that, we, too, outlined a set of soft skills that we think should be included.  We had some discussion about whether to actually put these into the map as something teachers would list.  Some in the room said that it should just be a given that you’re doing these things and that they would be checking every soft skill box for every lesson.  Or some said it should be relegated primarily to advising.  And I sort of agreed, but as I worked with my two CS classes this week, I started to think that 1) not everyone teaches these skills or has these skills in mind when they’re teaching and 2) there are ways to explicitly teach these skills or set up assignments in ways that teach them.

For example, we have on our list Reflection as a skill.  We mean, of course, reflecting on the past in order to make an action plan for the future.  And this can be reflecting on what your learned, on how much you studied for the test, or how many extracurriculars you signed up for and thinking about whether or not that was a good idea.  I can’t imagine that every lesson includes this.  Or maybe not even every unit.  You have to create the space for students to do that reflection, in written form, through class discussion, or through one-on-one conversation.  It has to be intentional.  You can’t assume.  I’m having my students do this in blogs, which can be found here and here.

Some of our other skills include

  • Self-assessment
  • Perseverance
  • Resourcefulness
  • Flexibility
  • Self-regulated Learning
  • Internal Motivation

I specifically assign things that require students to assess themselves.  And perseverance and resourcefulness are just par for the course.  I often jump into teaching things I know little about.  My project-based learning approach basically requires all these things in order to be successful in the project.  I don’t outline the steps to take or give them every resource they’re going to need or tell them if what they’re doing is right or wrong.  What I tell them I grade is the process they go through, which they document for the blog, and I tell them I’m looking for all these things in the whole of their process.  I’m looking for them to not just be going through the motions, but to be really asking themselves hard questions and sharing their successes and describing how they got there that shows what they learned and what they had to overcome to get there.

Yesterday, as we were laser cutting some recursively-created designs, one of my students said, “Yay, it didn’t work!  Now I have something blog about!”  (Check out our blogs for more on that.)

So while I think most teachers have these concepts in the back of their minds and may think they’re approaching their lessons in a way that incorporates them, I think it’s worth being explicit about it and really asking yourself as a teacher if the lesson, the unit, or the whole course is really structured to teach these skills and if not, what pieces could be added so that they’re included.

On not being the expert

Back in my first year of teaching, I didn’t know anything.  Sure, I’d been teaching for close to 20 years, but I’d never taught middle school or high school and I’d never taught CS.  I’d taught a “boot camp” but not a full length course.  And rather than teach what I’d taught in that boot camp, I did my research and selected a language that I hadn’t learned yet, but that the research showed was a good first language.  That first year, I learned alongside my students.  I had spent the summer doing online courses, going through books, so certainly I knew more than they did, and conceptually, I knew a lot more.  But I wasn’t an expert, and that meant that I didn’t always have the answer.

And that still happens to me, because rather than have everyone do the same assignment, they choose what they want to do, and inevitably, they choose things that I’ve never done.  I just said a couple of days ago in my CS II class to a group that was struggling to figure something out, “You remember I told you I’d never done this before, right?”  Even in my web design class, which is truly an area of expertise for me, I was looking at a student’s CSS and I said, “I don’t think you can do that.” And she said, “It’s in the book.” And sure enough it was, and sure enough, she saved her code, refreshed her page, and I said, “Cool! I learned something new.”  And it happened again about 5 minutes later.

Not knowing everything about your content can be unnerving, but it can also be enlightening, and you can be a good model for your students.  You’re showing them that learning doesn’t end; it’s always happening and will continue to happen for them, hopefully all their lives.  And you can empathize with them more.  You know what it’s like to struggle to understand something.  This is a common theme for me, because I’ve yet to have a year where I’m not teaching something that’s brand new to me.  That’s how I roll.

I was reminded of this whole feeling by a post from Teaching Humans by Meghan Paris. She writes about how not knowing everything has brought joy back to her teaching:

For the first time in my professional life, I enjoy the act of teaching. Most freeing of all, perhaps, is the feeling of not knowing exactly what I’m doing while actively doing it.

The next two paragraphs are worth reading.  We ask our students to learn everyday, to struggle to understand, to keep learning even when it’s hard.  When we do that alongside them, it’s so much better for us as teachers, but more importantly, it’s better for the students.


Summer Learning

I should be doing a million things right now–grading, responding to email, etc.  but I’m going to clear my head a bit and write a post about summer.  I’m sitting outside on one of the many benches we have around the school.  The birds are chirping.  There’s a slight breeze and it’s warm.  In the summer, I start to get tired of the artificial climate indoors and prefer a little sweltering to the refrigeration of air conditioning.

I am planning a lot of learning this summer, as I do every summer.  I’m repeating a couple of conferences from last year and attending another that I haven’t been to in a while.  I’m going to be at conferences 3 weeks in a row, which might be a bit much, but I know I’ll be challenged and will learn a lot.  I will start my conference going with ISTE, which is here in Philly this year.  It’s been a few years since I’ve gone as I felt like I’d gotten as much out of it as I could.  I’m presenting this year, and I’m looking forward to attending some other sessions on new ideas.

Next, I will go to Constructing Modern Knowledge.  This is where some serious learning will happen.  I’ll be rolling up my sleeves, and actually trying to create a project using programming and materials I may never have used before.  i learned a lot last summer, and I expect to learn more this year.

Finally, I will end with CSTA, a conference I’ve been enjoying for 5 years now.  This is the conference where I get to get into the nuts and bolts of teaching CS and people don’t look at me like I have two heads when I tell them I teach Computer Science.  No one will think I’m teaching word processing when I mention the word computer.

In between, I will likely work on my programming skills, perhaps learning yet another language, and I’ll be figuring out how to approach my new role.  I always tweak my courses, both in response to student feedback and by adding in new things I’ve learned about.  Yes, summers are for relaxing, but they can also be for gaining new perspectives and learning new things.

A great #makered week

Last week, things really started to gel for both my 8th grade Creative Computing class and my CS II class.  On Thursday’s #makered chat, I posted this:

This is an 8th grade student going to town with a Hummingbird Kit.  The assignment was to create something physical with a Halloween theme.  And while her robot probably will only loosely be Halloween-y, she’s ready to work on this for the next few weeks.

8th Grade Student and her 3Doodler success
8th Grade Student and her 3Doodler success

Another student wanted to make a Haunted House, so she laser cut the front of a house, and then used a drill to cut out the windows and then started using the 3Doodler to enhance some of the details on the front.  She asked if this house could be a prototype for a whole city.  Um, yeah, I said, That would be awesome.  She said, oh man, this is what I’ve always wanted, to be able to do stuff like this.

Meanwhile in CS II, I’ve been trying to corral what is a pretty feisty group of students.  There are only 7 of them.  They have been bonded through their experience in CS I, and they have a tendency to want to goof off; however, this week, they finally got to work on some object-oriented programming, again with a Halloween theme.  Below are two of the projects.  My CS II class is at the end of the day, and is followed by a free period for students. Many of my CS students just stay and keep working.  It’s pretty cool.  At the end of last week, I was feeling pretty darn good about my students.  And I have more good student news to share.  Stay tuned!


What all my CS students should read

This is an old post, but it popped up in my feed last week.  In it, the blogger describes how he went to a hackathon with a friend, a person he described as a programming god, and just felt totally inadequate.  He watched his friend and realized that his friend didn’t know everything either, that the friend just Googled the problems he ran into and then figured it out.  The next hackathon he went to, he was the programming god, because he followed his friend’s lead.

Both of these people are CS majors in college.  Going from CS major to work at Google (or any programming-oriented job) is a big leap.  You know the foundations, but you do not know exactly how web security works.  When I first started learning to program, I did a combination of things.  I used other people’s code and modified it to do what I wanted.  In order to do that, I had to understand the code.  I went through books, step by step.  And finally, I took some online classes.  I do wish, sometimes, I’d had some direct instruction from a real person in that process, but the reality is, the landscape of computing changes so rapidly that keeping up requires a chunk of just figuring stuff out on your own.  Often, you have a specific problem to solve in front of you, and you need answers.  You can’t wait until the 6-week mark of a course where they cover that topic to get the answer.

I know some faculty hate when students Google the answers to the problems they’re given.  Code for most basic CS exercises can be found anywhere on the web.  And some of those basic CS exercises are necessary foundations, but the solution to a lot of “cheating” is to have harder problems.  Have students design their own problems.  Partner with people in the school to solve real problems.

I have students who are planning to attend a hackathon in a couple of weeks.  I shared this article with them, and I also explained that what we’re doing in class is not what people in the “real world” do.  There are frameworks and tools that real developers use that we don’t, because just those tools themselves are hard to understand much less the coding.  And I want to focus on coding.  And, more importantly, I want to focus on learning.  I want to end with a section from the last paragraph of the post, where describes the hard work learning takes, and the understanding that there’s much to learn:

The barriers to becoming a software engineer are real. People born in technical families, or who were introduced to programming at an early age have this easy confidence that lets them tackle new things, to keep learning — and, in our eyes, they just keep getting further and further ahead. Last year, I saw this gap and gave up. But all we really need is the opportunity to see that it’s not hopeless. It’s not about what we already know, it’s about how we learn. It’s about the tenacity of sitting in front of a computer and googling until you find the right answer. It’s about staring at every line of code until you understand what’s going on, or googling until you do. It’s about googling how-to, examples, errors, until it all begins to make sense.(emphasis mine)

On Learning Something New

I’m a week in to learning to play the guitar.  My index and middle finger hurt and I can safely say that I pretty much suck.  But, I’m a week in.  I know I shouldn’t expect to be playing like Taylor Swift by now.  And that, in itself, is something to recognize, for both students and teachers.

I’ve observed a couple of things so far in my practice.  First, I recognize that it would probably be easier/better if I had a teacher, preferably someone who’s an expert at both playing the guitar and teaching.  I’m not getting the same kind of feedback from the app that I would get from a person.  I get no tips for finger placement or holding the guitar.  I’m getting no, “That was good. Try to keep doing it that way.”  So I’m probably a) learning slower and b) creating some not so great habits.

Second, I’ve noticed how foreign all of this is. Music is not foreign to me.  I can actually read music.  I sang in my church choir.  I played piano a little, and at one point I tried to learn to play the harmonica.  But I’ve never played a stringed instrument.  I’ve never had to tune my own instrument.  I don’t have a feel for how to move from one chord to another or even sometimes how to strum.

Someone posted to the SIGCSE mailing list reminding people of how much students have to learn in order to start learning to program.  So much of the inner workings of the computer are hidden now and we have to expose them and teach them.  Plus they’re learning a new language, new software, a new way of thinking.  It’s like approaching learning an instrument.  You have to learn how it works and its language (musical notes).  Try learning something entirely new sometime, and feel the discomfort and utter foreignness of that.  Then you’ll have a sense of how your students feel.

Doing something different

English: An easy way to teach yourself guitar,...
English: An easy way to teach yourself guitar, learning how to play in your own time. (Photo credit: Wikipedia)

I had a long weekend this weekend.  Friday, I went to a conference, where I ran a section of the Maker Playground.  It was great fun.  We scanned people in and printed them out, flew some mini quadcopters around and made paper circuits. Saturday, we went to a fantastic wedding, a couple I’ve known for about 7 years or so, and it’s finally legal for them to get married!  So, that was a great celebration.  Sunday, I did nothing, despite it being a beautiful day.  I was physically and emotionally exhausted from a long week.  Geeky Boy was in town and we hung out together.  Otherwise, I sat on the couch and played Civilization.

Today, I came out of slugdom and started straightening up areas of the house.  I decided that I needed to focus on me for once.  The last few weekends, I’ve prepped for classes, written papers, or other work.  I needed to do something to improve the space I spend time in and feel like I was doing something non-work-related.

I made some chicken stock from scratch and while it was cooking, I borrowed Geeky Girl’s guitar and started learning to play.  I got an iPad app to guide me through the process.  It’s a little like Guitar Hero with a real guitar.  I practiced for about an hour.  And yes, I suck.  But it’s so different from what I normally do, and I have to focus so much that I can’t think about anything else.  Essentially that’s why I play video games, but I get bored with them after a while and get tired of staring at a screen.

My goal is to learn a song or two by the end of the school year.  I think everyone should try to learn something completely new every 5 years.  I’ve had to learn new programming languages almost every year, but those map fairly well onto existing knowledge.  I also wanted to challenge myself to take the time to do this even when life is busy.  It’s easy enough that I would have a hard time making excuses (unlike exercise where weather can throw a wrench into all my plans).  We’ll see how it goes, and if I get any good, I’ll post a tune here.

Food + Algorithms = Learning

IMG_20140924_084037452_HDRAs I’ve mentioned, I’m focused on making sure students understand underlying concepts without the need for code.  I really believe that if they know what a loop is conceptually, they can create a loop in any language.  Yesterday, I tackled both the concept of an algorithm and basic programming concepts by using food.  I broke the students into groups of 3 or 4 and gave each group a set of supplies.  For the morning class, we had bagels, cream cheese, and strawberries.  The afternoon class had crackers, cheese and pepperoni.  Each group got a plate, necessary utensils and napkins.  Then each group selected a person to be the robot.  I conferred with the robots and explained that they needed to be stupid.  They don’t know what cheese, bagels or crackers are.  They know basic directions and that’s it.

IMG_20140924_084335344As you can see from the pictures, the students had fun, especially when the directions went awry–as they did in every group.  In the morning class, we had time to test out the process using me as the robot.  That was instructive for many of the students as well.  In some groups, the robots helped out a little too much.  I didn’t.

In both classes, we discussed what was difficult about the process.  The fact that the robots could just be told to pick up a bagel or cracker was difficult.  They realized quickly how much humans know compared to computers.  I asked how they overcame their difficulties.  It was interesting how many different programming concepts they used to complete their tasks.  Some groups defined their objects.  They described what each item was and where it was located (object-oriented programming, ftw!).  Some defined functions, like spreading.  They all repeated actions in a loop.  Some simply said, “Repeat.”  Some used ctrl-c, ctrl-v, which I thought was hilarious and awesome.  They all used conditions, mostly in a “while” loop: “move hand down until you hit an object.”   And we talked about how to orient a robot using things like coordinate plans or just left and right, up and down.  I also suggested that their plate could serve as a clock, so they could say, put your hand at 3 o’clock.  I went through basic programming concepts after the activity, and I was able to connect each concept to something a group did during the activity.

IMG_20140924_134349079_HDRThe homework had been to read some material about algorithms and write what they think an algorithm is and how it relates to programming.  After the activity, I asked if they would revise their answer.  Most said yes.  Many said, just saying it’s a list of instructions isn’t enough.  They talked about figuring out how many steps to break the problem down into, that some of those steps need to be small and detailed.  Some even talked about having algorithms within algorithms, so that you might have an overarching set of instructions, but smaller sets within the larger one.  They also talked about what the robot knows and understands versus what humans understand, and that they needed to figure out how the robot is seeing things or understanding things, so that they know how best to give instructions.   In one class, that discussion led to questions about how real robots work.

What I’m now looking forward to is seeing how this plays out withIMG_20140924_134422706 actual programming.  One thing I’ve noticed this year, both because I’ve made some changes, and because I have more students, is that girls like to talk about what they’re learning.  Some of my students have even said as much, so I think I’m going to build in time after every concept to have a conversation about it.  I think it allows them to create their own ways of remembering and understanding the concept.  They use their own contexts and metaphors.  And I’m there, of course, to make sure it’s accurate.  I knew this intellectually before, but seeing it play out is really interesting.

Problem Solving: Peeling Back the Layers


Problem solving flowsheet
Problem solving flowsheet (Photo credit: aka Jens Rost)


One of the things I enjoy about working on a project like my dog door logging project is that problems crop up that challenge me.  This is something I find fun, but my students sometimes find frustrating, so I’ve been thinking about how to present the issues of problem solving in a way that will be more appealing to my students and will encourage them to dig as deep as they need to to solve the problem and not give up.


I tend to approach problems in a step by step fashion.  As I’ve built this dog door project, I’ve done it one step at a time rather than trying everything at once.  First, I tested the tilt sensor itself to see if it would work, printing it’s state to the monitor.  The wiring and programming for the tilt sensor have been well documented (thanks, Adafruit!), making this step fairly straightforward.  Understanding the programming language and how circuits work allow you to change things up if needed, but the basic tutorial gets things off the ground quite nicely.  Early success is important!


The next step was to figure out how to save the data from the tilt sensor. This involves thinking about a couple of things.  First, what does the data coming out of the sensor look like? Is it a string? A number?  Here’s where tutorials sometimes break down.  The tutorial I used lit a light when its state changed.  I needed to print text somewhere, preferably in a format I could use elsewhere to create a graph.  I had in step one, printed to the serial monitor, adding a single line to the tutorial code.  I actually ended up making my own string, so that “Up” printed to the screen when the “door” was “Up”.  Basically the tilt sensor registers a high or low value of electricity, similar to an LED receiving a high or low value of electricity, so I just converted the high or low value to the string “Up” or “Down”.


There’s a lot to unpack in just that one solution.  I think we underestimate that when teaching students.  Understanding what’s coming out of a function is challenging for most.  Knowing that printing to a file requires a string or a number and that other data types might not work is a pretty big step.  And then you have to figure out how to convert your data to the right type if necessary.  Also, you have to know that some sensors might actually give you numbers and then you don’t need to convert!  Crazy.


So I’m printing to the screen, but not saving the data anywhere.  How do I do that? How do I do that with what I have on hand?  To the Google machine!  As I mentioned yesterday, I discovered that the Arduino can store a small amount of data (512 bytes).  This was a test of two things: 1) that the data can be saved and 2) that I could read the data later and see that it was useful data.  Again, the documentation on this was good, but I had to know how to search for that.  I searched “how to save data on an Arduino” by the way.  And I got this, which led me to this.  And just this step is a challenge for many students.  There are different kinds of memory.  The amount is tiny, so one has to think about how many characters to use.  It’s a good lesson, but could be frustrating.  And there’s a whole other process for reading the stored memory out, which requires writing another program.   Phew!


In search of a more robust solution for saving and retrieving data, I went to the SD shield, a shield I’ve used before with some frustration.  Most of the time, I couldn’t even get the Arduino to recognize the SD card, which has to be formatted exactly correctly for anything to work.  I got past this step at least.  In theory, I’m writing to the SD card now instead of local memory (a one-line change plus some imported libraries and pin attributions, maybe 5 lines total).  But, the file is empty every time I look at it.  No errors, just not doing what I think I’m telling it to do.  And these are the issues faced by most of my students.  Things are “correct” but something isn’t right.  My card could be too big.  The documentation does say that SD cards that are bigger than 16GB are not supported.  Whatever that means.  My filename could be wrong, but I think I’d get an error.  Could be any number of things, programmatically or electrical or hardware.


And then I have to solve the problem of how to get the device onto the dog door itself.  This is going to pose an issue.  The best way to do it would be to solder everything together, and I think that’s the direction I’m headed.  We shall see.


But you can see how many layers of things one must dig through to begin to solve what seems like really simple problems.  To me, this is the crux of what we teach in CS.  We help students methodically step through solving a problem (often a problem they designed) and then recognize the smaller problems they need to solve one at a time in order to achieve the larger solution.  It’s breaking down problems into smaller parts, algorithmic thinking, and a touch of creativity, all things we’re trying to convey in CS.  But it’s not always easy and I think we need to recognize the frustration that might come with discovering another mystery with each solution, the feeling that maybe there’s no bottom to this.  Thinking through my own strategies for solving this particular problem reveals all the things I know that help me, things I might need to help my students learn as they bump up against these kinds of problems: different data formats, how data is read by a computer, memory types and sizes, formats for disks and files, not to mention electrical circuits and programming which are the main things we think we’re working with.  I find it fun to peel back the layers, and I hope to make it fun for students, with a little bit of coaching.


CMK 14: Some Final Thoughts on Learning

CMK Motto?
CMK Motto? (Photo credit: lorda)

I’m on my way to the next conference, CSTA, but I wanted to get some final thoughts down about CMK and learning. Everyone learned something at CMK. They learned what they needed to know to get their project done. And often they learned things they didn’t even know they needed to know. That was certainly true for me. Sure, I knew how to program, but I didn’t know how to use an API. And each API is different, so even if I’d used one before, that knowledge wouldn’t necessarily apply to the one I was currently using. And it turned out I had to learn about different formats for latitude and longitude. The API used decimal degrees while most maps show them in degrees, minutes, and seconds. I had to learn to mathematically map one range of numbers onto another range. I had to map, for example, humidity that ranges from 0-105ish to colors that range from 0-255. I did all the math for that, but ended up using a built-in function to make things a little simpler (since I had to map about 5 different sets).

And I built some existing skills. I used objects to keep track of all my different locations and their associated data. I had to build my own class for that and figure out the best structure. That’s something I don’t get much practice at. I also ended up storing the data in a flat file, which I’ve done a lot in the past, but it’s always a challenge getting it just right.

When you teach (or learn) in a project-based way, this is how learning goes. You can’t lay out everything you need ahead of time because you don’t know what you’re going to need. Even if you read a whole book on programming before you start programming, it’s going to miss lots of key stuff. As teachers, we can’t hope to lecture in a way that lays all that ground work before kids start getting their hands dirty. The way to do it is to let them get their hands dirty, and then figure out concepts as they go. The way I do this in class is to do short, small quick things. I explain a concept for maybe 5 minutes, then we spend the rest of the class building something to demonstrate that concept. Then we review. Larger projects we just dive into because the small, quick bits have hopefully laid enough groundwork. CMK modelled this approach, and let us experience it first hand. Now we need to model it for our students.

(posted at 10,000 feet)