Tuesday, December 31, 2013

Teaching computer science

After 8 years of teaching business and technology courses, I've learned a few things about teaching computer science.  I've tried a lot of different approaches and there are a few things I've found to be effective and important in the classroom: respect, enthusiasm, practice, evaluation, and regular feedback.  This is no means a prescription for a perfect classroom, but I've found that a lot of this really works for me and the students I've worked with.


Try to learn the students' names as quickly as you can.  Remembering someone's name is a show of respect.  If a student is going to listen to somebody talk for 3 hours a week for 15 weeks, the least an instructor can do is remember his or her name (besides, saying, "Hey... guy" doesn't really work past the first week or so).  Obviously this may not be practical all the time - lecture halls with hundreds of students make it just a little harder - but it really helps an instructor to connect with the students.

It's also good to try to convince them that you are interested in helping.  The students *should* succeed. They should understand why learning certain things is important.  They should know the practices that good programmers engage in, and why some practices lead to bad programming habits (hint: O(n^7) solutions are usually bad).  They should know how things will work in a job some day.  A good instructor should help them accomplish these things.

Grades should be secondary.  An "A" doesn't mean a student is smart any more than an "F" means a student is dumb - it just means that the "F" student, for some reason, didn't accomplish some required minimum class requirement.  The requirements are there for a reason, for sure, but the major goal should be to ensure that students learn as much as possible - not pass or fail students.  It's not about grades - it's about really learning.

Enthusiasm / Fun

In my mind, effectively teaching computer science is equal parts logic, coding, and sales.  You have to do all three.  When you're teaching undergraduates, it's one thing to present the material effectively - but you have to make them believe in it.  You have to sell it.  You have to make them want to complete the assignments, because there's a reason for it.  You want to make them excited about computer science and software engineering.  If you can do that, the students will work harder because they'll know this their work isn't just going to be going through the motions to meet some mundane criteria.

It also helps to make the class fun.  There are lots of ways to do this - you can create assignments that are interesting and rewarding.  You can make lectures entertaining and more engaging.  You can create interesting grading systems or assignment approaches.  You can incorporate outside material.  Trying different things out and seeing how the students respond is a great way to make the class more enjoyable (and if all else fails, just point to starting salaries for CS graduates).

Practical and Relevant Practice

I think assignments are important - and a lot of them.  Even though you tend to work on large projects in a software engineering job, one or two big projects for the term don't teach students about what it's really like to have a job.  The big difference is that in a typical job, you're expected to work on your project every day; in school, you don't have the same motivation, reward system, or status checks to effectively accomplish this (i.e., nobody is paying you, and nobody is yelling at you).  Some students might work on a large project every day because that's just the way they operate.  Most of them will end up cramming it in closer to the due date or at the last minute.  This doesn't help them learn - it's like cramming for exams.  Much of it is forgotten shortly after the assignment is completed.

I've found it much more effective to give smaller assignments, but more of them.  I think at least one assignment every two weeks is a pretty good frequency (one per week is better, but hard to keep up with).  That's because it keeps the students coding.  You need more than just demonstration of concepts - you need regular practice to really learn how to be a software engineer.  Lots of smaller assignments keep the students regularly engaged.  It's more work to grade, but I think it's important.  It keeps the students' minds consistently thinking about coding.

There are definitely ways to break large projects or assignments up into smaller pieces - in fact, if you think about it for a moment, this is exactly what happens in a job as a software engineer.  By doing this students can accomplish a larger project, but presenting it in smaller pieces will give the students a more manageable way to finish the work.

I'm extremely skeptical of puzzle solving problems.  Google stopped doing these types of questions in interviews for a reason.  I know a lot of instructors love to assign them but I don't know what students really learn from them; I really believe there's more value in knowledge, technique, and writing maintainable code than there is in "clever" solutions to cryptic problems.  Chances are, coding an algorithm to solve a sudoku puzzle isn't going to come up in the day-to-day work in a future job or academic pursuit, but it might trip up some strong developers who aren't good at that sort of thing.

Regular Evaluation

I used to give weekly quizzes in my classes - both as an exercise in repetition (you tend to remember things better if you repeat them after learning) and as regular evaluation.  In the last year I've changed this a bit.

Not long ago Harvard announced that "required" final exams would no longer be required.  Of course the big controversy was no longer having final exams, but I drew a slightly different conclusion from this policy: one big comprehensive exam just wasn't an effective teaching tool.  I've discovered something that is a much more effective teaching tool: a series of comprehensive exams.

As an instructor, this is something that is a huge pain to deal with but I've found it to be extremely effective for students to learn the material.  In a 15 week term 4-5 exams is a pretty good number.  The important thing is that each exam is comprehensive - it changes the student mindset.  No longer can students study for an exam and then forget the material shortly after.  It inspires students not to quickly learn the topics, but to KNOW the topics.  Students don't love it, but I've found it to be effective for knowledge retention.

So much of computer science builds on earlier topics; for example, you need to understand how a linked list works before you can learn binary search trees, and you need to understand queues before you can understand breadth first search algorithms.  By continuing to test students on all the material throughout the term, knowledge retention can be improved.

Regular Feedback

There are two sides to this: student feedback and instructor feedback.  Student feedback is typical - usually suggestions and comments in assignment grades, exam feedback, etc.  Instructor feedback is often less frequent, but is just as important.  It's hard to hear you're not awesome all the time, but it's important.

You can ask students several times during the term how things are going.  The school where I'm currently teaching does end-of-term evaluations, but I don't think that's timely enough to correct your pace or methods.  It's important to regularly get a feeling for how the students are responding to the material and your style.  It's easy to ask the students in your class a few questions in small, informal, anonymous surveys to get their opinions and comments on the course.  Is the course moving too quickly?  Too slowly?  Are you feeling challenged?  One time a student responded that I tell too many jokes - so I tried to make it a bit more serious (unfortunately I'm just not so good at serious, but I really did try).  This can give you great feedback to course-correct (no pun intended) and can really improve student engagement.  Students like it when they feel like you're listening to them (much like professors).


One big problem I found with my undergraduate education was that too many instructors didn't seem to want to teach, let alone enjoy any aspect of it.  I had some great instructors, sure - I'm really honored to be working alongside many of them now.  The ones that I really remember are the ones that had a passion for teaching.  It wasn't just something they had to do - it was something they enjoyed.

A lot of these other things are easier if you really enjoy teaching.  I love teaching.  I enjoy helping students.  I get a lot of satisfaction out of explaining how things work.  Because of this I try hard to improve my classes every semester.  I think that being passionate about education - truly desiring to do it well - can really make the difference for any instructor.

Sunday, December 29, 2013

I love the Fitbit Force.

I've been wanting to check out this Smartwatch trend that everyone (read: some tech bloggers, and Samsung... oh, and those tens of thousands of people on Kickstarter) has been talking about.  I was in Best Buy the other day and I picked up a Fitbit Force ($129.99) and a Pebble ($149.99) with the intent of keeping whichever one seemed to be more useful / practical.

Pebble Smartwatch
Fitbit Force

I decided to open and try the Force first.  Full disclosure: I've had a Fitbit Flex for a few months and I really love the Fitbit system.  They do a great job of tracking and visualizing data without going overboard or making the system too complicated.  Overall I think the Fitbit apps and devices are simple and easy to use - the Flex just sits in a wristband (or your pocket) and tracks your movement throughout the day, and tracks your sleep at night.  It's mostly passive.  I've found the information they provide is a great way to sense when I've been lazy (usually) or active (if I'm running from lions or something).  It's also good for letting me know when I've been sleeping badly and should try to get a bit more sleep (which is almost always).  I don't get into the calorie counting or water monitoring - but for tracking sleep and activity, I think it's really a great little device.  

The Force is pretty simple as well.  The Flex showed you your progress with a few taps on the wristband.  It was pretty simple, with just a 5 summary dots to show you 20%, 40%, 60%, 80%, and 100% of your goal for the day.  The Force goes a little bit further and provides more detail.  It has a dedicated button that you can use to cycle through the different metrics (Fitbit calls them "stats"): Clock, Steps, Distance, Calories, Floors, and Very Active Minutes (one I really need to work on).  I concentrate on Clock, Steps, Floors, and Very Active Minutes so the display is pretty simple.

The silent alarm is also a really great feature; you can configure it for a regular Monday - Friday wake up and it will vibrate at a set time.  In my opinion it's a nicer way to wake up than a noisy alarm clock.

I don't know that the Force or the Flex are terribly accurate in the number of steps counted, but that's not the point - it's really better for showing you trends.  I.e., if they're not accurate, they're likely to be consistent in their inaccuracy, so a day with 6000 steps is going to be less productive than a day with 9000.

It's easy to put on and not obtrusive - it's small enough that I don't notice it under most shirts, though I do have comfort issues if my sleeves are tight.  One small complaint I have is that the clasp is metal so it rubs uncomfortably on my laptop when I'm using the computer.  I feel like a plastic clip would be better here, but probably also less durable.  It's not a big deal, just an annoyance when typing.  Lots of people seem to have issues with the clasp, but I think mechanically it's fine. 

I wasn't sure the device would be worth the $30 price difference from the Flex, but after using it for a few days, I think that it is.  The screen looks a lot better in person that it does on a screenshot on the Internet.  Sure, it's a simple dot matrix display, but it's well animated and easy to read. 

I like the Fitbit Force as a replacement for the Flex, but when comparing it to the Pebble, it needs a few things to be a great Smartwatch:
  • I've read that they're working on call notifications on the Force (but only for the iPhone).  This makes sense and would be pretty useful - I can see if I want to pick up the call without pulling my phone out of my pocket.  It's a great feature to have.  Hopefully it comes to Android soon.
  • As it stands, you can select which "stats" are included on the wristband in the iPhone / Android app.  If the wristband can do call notifications, I can't really see a reason it shouldn't be able to also include stats such as:
    • Number of unread text messages
    • Number of unread email messages / GMail messages
    • Total number of unread email messages / GMail messages
    • Number of unseen Facebook notifications
    • Number of Twitter direct messages
  • I'm not sure if it's possible or even sensible to do new email / text message notifications, but maybe the ability to set it up so that it only sent notifications based on a filter or preferred sender list would be practical.
I'm sure it doesn't do as much as the Galaxy Gear or even the Pebble... but honestly, it might be enough.  The screen is good, though it's not high-resolution.  I like the simplicity.  Using the button to cycle through the information I need is a simple, easy way to interact, and the number of "stats" wouldn't be too overwhelming, especially if you could pick them on the iPhone / Android app.  

Sure, you wouldn't be able to answer calls or view email detail, but is a wristwatch really the best way to do those things anyway?

I'm hoping to try out the Pebble over the next few days and report back.


Update (2013-12-31): I've proposed some of this on the Fitbit "New Idea" forums: https://community.fitbit.com/t5/Product-Features/Fitbit-Force-Smartwatch-features/idi-p/37723 - vote for it, maybe they'll make it happen!