My Favorite Year Teacher

Sorry for the weak title and movie reference.

It's teacher appreciation week -- one of our lesser celebrated weeks. I'm waiting for the annual letter we get from the chancellor. Given the level of teacher bashing over the last few years, I've recently found their emails amusing.

I though I'd take the time to thank a few of my most influential teachers. To paraphrase: whatever good I've been able to do, it has been because I have stood on the shoulders of giants.


Alan Goff - 7th grade English - Wagner JHS

Great teacher, great storyteller.  Every now and then class would be spent with Mr. Goff  telling us a story of his childhood. From his school days when he discovered how to make explosive "goffolini" bombs and had to deal with  the bully "GodDilla" to when he blew his hand off with said bombs to his time in the merchant marines. I think I learned more about bringing characters to life from listening to Mr. Goff than anywhere else. I'd like to think I'm somewhat entertaining in class and it started with Mr. Goff. Mr. Goff also shared with us the range of his interests. For me this led to a life of trying to learn something about everything. Thanks.

Mr. Goff passed away a number of years ago and I never had a chance to thank him. I still regret that. A few years ago, when Batya was graduating from Wagner. I drew the short straw and had to go to the awards ceremony. I love going to Batya and Natan's concerts and other things they do, but I hate these award ceremonies. When the vast majority of the students get awards, there really isn't anything special about them - I wasn't thrilled to go. It turned out that Batya won the Alan Goff Memorial Medal for writing. I didn't even know there was one. Brought a tear to my eye.

Herb Greenhut - 7th grade History - Wagner JHS

Wow, what can I say about Herb. He was the first teacher to challenge me to really think. Every year he would start the semester by impersonating a famous figure. Someone his students would never have heard of but their parents would have. For us I think it was William Jennings Bryan. Another year it was Thoreau. All his paperwork was under the pseudonym and he'd play us on for days. He'd engage us in debates as if we were adults.

Herb was a straight shooter. We were young but he never sugar coated things. Herb got us to question things like no teacher had before.

I could go on and on about Herb. He influenced generations. By the time I was in his class in the seventies, he was a veteran and he continued on until right before his death a couple of years ago.

Both my son and daughter had the privilege of being in Herb's class during his final years. He had retired from the school system but still taught at our synagogue. I asked them both about Herb. Their response "he makes us think." Thanks

As I said, I could go on and on about Herb but I found this piece here that does a better job than I'd be able to.

Richie Rothenberg - 12th grade AP CS - Stuy

The only way you could describe Richie would be a mensch in the truest sense of the word.

Richie was my teacher at Stuyvesant. He was a great teacher, but I got more from him as a colleague years later. Richie was always on the side of right and always did the right thing. Never a self promoter and never the "hip" teacher,  he just went about his business of being a great teacher. If there was something he could do to help a student, he did it. Many times, the student never knew.

Richie passed away at 50 in 1997.  The day it happened, school basically shut down. Normally a small memorial plaque is placed up near a room in memory of a teacher. This wouldn't do for Richie. Students, teachers, and alums contributed money and Madeleine Segall-Marx, artist and Stuy parent, contributed a year of her life creating Celebration:



It can be found at Stuy on the fourth floor. Fifty boxes (7x7 + 1 double box). Each representing some aspect of Richie's life.  I still spend time gazing at it.

These three have left us. I never had the opportunity to tell Mr. Goff how influential he was and that's something I regret. Herb became a friend, Richie, a friend and colleague and I'm grateful that I was able to express my gratitude numerous times.

Robert Dewar -- Systems I and II - Courant

Robert is the one college professor on my list and I will reach out to him very shortly just to share with him the impact he's had on me. I was in Robert's class during my sophomore year. If I remember correctly, we finished the syllabus in the first couple of weeks and the rest of the class became "what neat stuff will Professor Dewar teach us today." There was nothing pedagogically "right" about our class. Just 12 or so people around a table talking but it worked. I think I learned more about CS in those classes than most of my others combined. I think a lot came from the transmitted passion for learning neat things about a range of topics.

It's hard to capture what made each of these teachers special. That's the problem with the whole teacher evaluation movement. Richie was the closest to being a traditional teacher but they all had different styles and different personalities. They all helped shape me into the teacher and person I am today, so again to each of them, I say thanks.

Continuing the Journey

Shortly after our event at Foursquare, I was chatting with Kevin Friedman (Stuy '96). Kevin's startup is Cojourneo and since it has an educational bent, he thought I might be interested in hearing about it.

I certainly was.

Rather than visiting Kevin, I thought it would be fun to have him come down after school, present Cojourneo to any students that wanted to stay late and then field questions.

Cojourneo is an interesting product. There's been a lot of hype around on line education in the past year, but it seems to me that Cojourneo's a little different. We've got efforts like Coursera and Udacity that are trying to bring university style offerings to the masses while places like Codecademy seem to be more vocational in nature. All three efforts are "class" based. That is, you are taking a class over a period of time. Despite some resources to make these classes shared experiences -- specifically things like discussion groups, they mostly seem to have students watching videos or working through on line material on their own. 

Cojourneo's approach is to organize around "journeys" which aren't necessarily academic in nature, one of the journeys they have going now is Surviving the Startup Journey, but Kevin mentioned that they could have things like book clubs, travel journeys or any number of other types of journeys. They're also different in that they're really trying to create a shared experience -- you take the journey with a small circle of people, not solo - I love this aspect.

By no means am I an expert, but I like a lot of their ideas.

A bunch of students gathered and we were off. I had no idea how the talk would go but I figured that the kids hadn't had an opportunity to speak one on one with someone in the early stages of a startup so it would probably be valuable. 

Kevin presented the product, talked about some difficulties and decisions along the way and generally tried to give the kids the flavor of what it was like to start a product and a company. The kids tried to reciprocate by providing feedback on the product. 

Most of the questions focused on the business side rather than the technical. Kevin was asked about funding, monetization, building a user base, scaling, and any number of other ideas. 

All in all, I think it was a valuable experience and look forward to bringing more alums down to talk to the current crop.

Anyone can cook

Anyone can cook - Chef Gusteau

These days the rage seems anyone can code.

On line attempts to teach coding and computing abound.

We've got Udacity and Coursera trying to bring college level academic offerings to the masses on one extreme and more down to earth "learn to code" efforts with Codecademy getting the most press.

While I applaud any effort to make knowledge more accessible, there are a lot of unanswered questions as to the effectiveness of these latest attempts. Recent posts by Dan Meyer and Audrey Watters have started to raise questions and in my opinion some of the hype has worn off.

At some point, I plan to talk at length about the Udacity and Coursera offerings as well as attempts to increase on line course offerings at the high school levels. I'll talk about the difficulties and dangers that lie ahead.

Today, I'd like to talk about the more vocational offerings such as what Codecademy is doing.

The premise seems to be that anyone can code and that everyone should code. I've been thinking about this for a while and I keep coming back to the question, "what's the endgame?"

Teaching Javascript, HTML and the like narrowly focuses on creating web pages. Even if we forget about difficulties of on line learning that include lack of an interactive feedback loop, lack of follow up,  a narrow curriculum, and the fact that programming beyond the basics is not easy, what's the goal? While I find making an interactive web site cool, I don't know how much it benefits the masses.

One could argue that the mental exercise of programming is a benefit and having a better understanding of how a computer works is a good thing. I'd agree, but what we really could benefit from is a different paradigm in terms of how we approach using computers. A new approach would make even rudimentary scripting skills of greater value to all.

Most of us use computers as program loaders. That is, we sit down, load our word processor, edit something, and exit the word processor. Load our web browser, search the web, exit, load the next program, do something, etc. We might have multiple programs up at the same time, but we use them in isolation.

This is how most people's computing experience has evolved.

With this mindset, I'm not sure how useful coding will be for the masses. People might benefit from some rudimentary scripting a la Excel macros or Google App Scripts, but power users already do this. I don't think that the ability to program within the constraints of scripting individual applications will be a game changer.  To make rudimentary programming skills valuable we must use computers in a way that allows us to use simple techniques to tie together powerful applications.

A few years ago, right before our Christmas break, I stopped over in the Math Chairman's office to wish him a good holiday. Danny was hard at work. He was frantically trying to change the math web site before he left.

The math site was a mess. It consisted of a few dozen loosely arranged folders each with multiple sub folders. Danny was looking in each folder for old sample final exams, each saved as a Tiff file. He would load the file into Photoshop, convert it to another format and save it. He would then change the corresponding HTML file to reference the new file. He had been at it for hours with no end in sight. I said "Danny, I've got this, go home."

I went to my office, wrote a small shell script, maybe 10 lines, hit enter, got on my bike and rode home. When I got there, the job was done.

Now Danny's a really smart guy and he's technically savvy. The difference is that I was taught to try to tie programs together through the command line while he was taught to do things in the Windows/Mac way of loading one program and using it in isolation. I used a simple shell script to tie together a number of powerful Linux applications (find, imagemagick, sed) rather than pointing and clicking over and over again.

I've seen this "program loader" mind set time and time again and in surprising places. My good friend and colleague Gary Rubenstein has done a lot of work debunking the "educational reformers" that are currently in power. Gary had been using Excel to do all his analysis until I pointed out that he could download his data and use simple Python scripts to greater effect. Why was I surprised that Gary wasn't already doing this? Well, in addition to being an amazing math teacher, Gary holds a Masters degree in Computer Science and had worked as a professional programmer in a prior life.

Of course, our life isn't made any easier with closed file formats and vendors that try to isolate their data, but if we could re-educate people to use computers across applications, that would make rudimentary programming useful to all and then indeed there would be a reason for everyone to code.

Checking in with the family

"... the standardized courses don't shed much light on future opportunities and they make it hard for students to identify what they're most interested in. The CS department, on the other hand, is great at demonstrating all the things that are going on in the modern comp sci world." -- Asa, one of our current CS students.

Asa's comment was in response to an event we held last Tuesday. We brought 100 current students up to FourSquare along with 100 of our CS alums for a mixer. Other than the fact that we aren't a department, I'm hoping he was spot on. 

Stuy CS from 1976 to the present

A couple of months ago, I started to try to organize the graduates I've had the privilege of teaching over the years. I put out some feelers and the response has been great. So far we have about 400 members. I like to refer to us as the Stuy CS family since I'd like to think there's a stronger bond than that typical between a teacher and his students.  I'd also like to think there's a common thread across the years that ties the older and younger graduates together.

To kick things off, I thought it would be a great idea to get the alums together with the current students. We've got people all over the tech map, from giant companies to startups. I started putting a list together here. I thought it would be great to expose our current students to the range of possibilities that await them.

Immediately, the family came through. Noah and Dave volunteered FourSquare as host for the event. They provided the food and the site. The alternative would have been to have the event at Stuy. This would have cost us and would have been somewhat mundane. Just being at a place like FourSquare seemed to really excite the current crop of Stuy students.

The evening of the event, I was a little nervous -- about 100 alums signed up, but would they show. I've been told that general alumni events can typically have a very high no-show rate, particularly when the event has no cost and registering is as easy as an email.

The kids and I arrived early -- school lets out at 3:30 and the event didn't start until 6:00. As 6:00 approached, the alums started to dribble in. By the time we started, we had a packed house!!! It was great seeing everybody again.

We had alums from every year. From 1995, my first set of graduates, to last years senior class. We also had a few older alums, including me and  my classmate and friend Steve from '84 and Gerry ('76) , who I met when he volunteered to help Stuy CS back in the 90's. He's become a good friend to both me and the program in the years since.

For my part, I was extremely touched that everyone showed. As a teacher, you'd like to think you've had enough of an impact that your students would give back, but we rarely get any evidence as to the effects we've had. I've been fortunate enough to be in contact with a number of my alums through the years and a number of them have been kind enough express gratitude (often times more than I deserve) but to see everyone show up en masse really meant a lot to me. The only down side was there was so much going on, I really didn't get to spend time with anyone -- it was like hosting a wedding or bar mitzvah -- everyone's there, but you don't get to see anyone. I hope we can remedy this with more events and smaller events in the future.

If any of the "family" is reading this, you've also got to give me some props -- even though I haven't seen many of the alums in years, I recognized almost everyone and remembered far more names than I probably deserved to.

We spent the evening mixing students and alums and the FourSquare crew threw in tours of the facilities. Afterwards, many of the alums stayed back to discuss how to move Stuy CS forward. How the alumni community can help Stuy CS and it's current students and how it can become a resource for fellow alums. I think there are a lot of things we can do as a community, and I'm excited about what's to come in the near future for us as a group.

For the students, feedback has been terrific. I've gotten comments like:

I was wavering between whether or not I would continue CS in college and as a career, but now I'm fairly certain.

and

I really enjoyed the compsci event, it was very helpful to talk to alumni because they reminded me that there is life after college. I also liked the community within a community feel of the event.

The students pretty much universally loved the event and  I really think they got a lot out of it. 


We had parent conferences last Thursday and Friday and parent after parent confirmed this. Just about every visitor I had mentioned how much their son or daughter got out of meeting the "family". People  who were in their shoes a few short years ago and are now doing great things in the tech community. 


From what I can tell, this was a unique event, at least to Stuy, no one's ever done anything like this before in any subject area. It looks like it was a slam dunk, at least with respect to value to the students. 


Now the "family" just has to decide where we can go from here.

Field Trip!!!!!!!!

When kids are knee deep in nlog(n) algorithms and working on recursion, it's easy to lose track of the amazingly neat things that are right around the corner for them.

I've recently been working on organizing our Stuyvesant Computer Science alumni network and am putting together a page with some of the places our graduates work here.

It can be hard to see how one goes from sorting and searching in Java to working at places like Google, or FourSqurare or creating your own startup like DigitalOcean, Usable Health, TimeHop, or PropHop.

We try to show how close they are to doing really cool things, like the other day when we developed some solutions that lead to seam carving, but there's still a large enough gap between what they are learning and where they will be that it's hard for them to see how close they are.

With this in mind, yesterday, we took a field trip.

Being an NYU Alum myself  (BA '89, MS '95?), the CS people at Courant and I have periodically tried to form a partnership but there were internal problems at NYU that prevented us. Over the past few years, however, things have changed and we're well on our way.

Thanks to the efforts of the always amazing Evan Korth, Michael Overton, Rosemary D'Amico, Romeo Kumar, Shawn Abbot, and others, we were able to bring about 100 Stuyvesant juniors to NYU for a day of computer science.

We had four amazing presenters.

Ken Perlin batted leadoff talking to the kids about a variety of his interests. Basically a smorgasbord of places one can go to with CS. Ken touched on things ranging from expressing emotions from an animated  avatar composed of five polygons to paradigm shifts relating to ebooks.

Rob Fergus then gave a talk on image deblurring. Where Ken's talk provided a range of topics, Rob focussed in on one. The kids were really able to see how what they're doing now is just one step from solving some really neat problems.

JinYang Li was next. Her talk focused on systems touching on infrastructure issues and parallel processing. This provided an overview of one specific field in computer science.

Batting cleanup was Nathan Hull. Nathan talked about IOS developement. The most hands on topic of the day. Nathan really emphasized the fact that the kids could just download the tools to do either IOS or Android development and with online resources, they could teach it to themselves.

All this was followed by a great lunch.

It was a great range of talks and the kids left having a much better idea of what CS will be like in college and the range of things they'll be able to do.

Right now, I'm working on another event which will bring our students together with Stuy graduates working in the industry to give our kids more exposure to the step after college but more on that in a few weeks.

Let me Google that for you

Piloting a new course this semester - Intro to Computer Science part 2. Between the existing Intro part 1 and this, we should be able to do a pretty thorough job in preparing our kids for the future.

We decided that we wanted the kids to make deliverables in the form of web pages - plain old html written by hand. Part of the idea was to demystify things, part was to let the kids show off their work, part was to have something that they can generate programatically as the course progressed, and part was to give them a tool they might find valuable beyond their computer science classes.

We also wanted to help teach the kids how to find information and how to learn things on their own. Despite the fact that our students use computers all the time, they possess a widely varying skill set. With that in mind,  here's what we tried to do:

After a brief introduction to what a web page is (just a text file with markup) and showing them the bare
minimum of markup:




I recommended a simple editor - gedit - while resisting all my inner urges for all things emacs, and then showed them an image of a web page:

The end goal was to make a page that had all of the elements in the above image but I also asked:

• How did they go about finding out how to make the page?
• Where did they search?
• what turned up bad results (and what were they)?
• what turned up good results (and what were they)?

I was very pleased with the results. Just about all the kids are now able to make a web page with the components in the image above. More importantly, this is what came out of our discussion:

• Everyone used Google exclusively as a search engine.
• The range of queries ranged from things like "html tutorial," "making a web page," and just plain "html" to maybe not so good things like "gedit web page."
• No one used social search or used facebook.
• They mostly all found sites such as w3schools. 

I'm hoping this is a good first step in having the students find things on their own and not be afraid to try things. I think it's an encouraging start.

CS Stress

I've been mostly underwater for the last couple of weeks.

End of term issues combined with the Academy of Software Engineering announcement has pretty much eaten up all of my out of class time.

It's going to be a week or so before I can finish writing the posts I was planning on, but it looks like a storm is brewing around Stuyvesant and Computer Science so I thought I'd put up this short semi-related post.

Stuyvesant has a reputation of being something of a pressure cooker. The day can be as long as ten periods and it's not uncommon for a student to take three or more AP classes, even before the senior year. The question of student workload and stress has been a hot topic for a number of years.

There's frequently tension over how many courses and which courses a student should be allowed to take.  Usually, this revolves around the school placing a limit on the number of classes, or more specifically, the number of A.P. classes a student can take. Most recently, the conversation looks to be turning to the number of classes a student can take overall.

Given that most A.P. classes fall within a Stuyvesant student's required sequence of classes - that is, Calculus is just "the next math class" and A.P. U.S. History is slotted in place of a students regular U.S. History course, limiting the number of classes a student can take, A.P. or otherwise could have a major impact on Computer Science at Stuyvesant.

What's most disturbing is that limiting student options in terms of courses may not do anything to decrease stress and workload. No one has looked at what is actually going on in student's required classes.

I decided to collect some information from our students. I sent out a survey to five of our seven A.P. C.S. classes (three of mine, two of JonAlf's -- the other two classes don't have a mailing list). I asked them to rate the work load and stress factor for A.P. CS, their typical Stuy course and their typical Stuy A.P.course. So far, I've gotten 80 responses (out of about 150 students emailed). Here's what we got (ratings were on a 1-10 scale):

	A.P. C.S.	Reg. Class	A.P. Class
Workload avgs	4.97	6.65	7.13
Workload dev	1.94	1.41	1.52
Stress avgs	4.67	6.39	6.94
Stress dev	2.24	1.63	1.64

I know this isn't really hard data, but it seems that our A.P. C.S. classes are considered to be both easier and less stressful than other classes at Stuyvesant. Given that our kids do very well at C.S., we're probably doing something right and it will be a shame if student opportunities become limited. I'll certainly write more on this as the situation develops.

For you educators out there, is stress an issue at your schools and how do you deal with making room for students to take CS at your schools? 

Pretty sneaky, Sis

I've always lamented the fact that we don't have the time or structure to really teach our kids to program.

In their early classes, they learn syntax, algorithms, and  some ways of storing data and while they  will probably work on some larger projects as they study CS, kids seem to be mostly left on their own in terms of how to take a project from problem or idea to completion.

This frequently leads to poorly designed projects that are harder for the kids to write, debug, and modify. They end up with huge functions/methods no overall plan or design and everything's pretty much a mess

To try to address this, and having finished  most of the A.P. curriculum and not wanting to diverge from the other teachers, I figured we'd develop a class project before I gave the class time for their final projects.

I'm not a huge game person, but since they decompose well, we decided on writing connect 4 - a game that can be described as tic-tac-toe but with four in a row, on a larger board, and WITH GRAVITY!!!!!!

Actually, the choice of project didn't matter that much so long as it was the right size -- this was more about how we develop a program than about the actual program itself.

I started by giving my classes about ten or so minutes to talk among themselves to design the program -- no guidance was given. About seven minutes in, I asked them to reflect on whatever they were discussing - if they were discussing a data structure, why? If class design, why? What was so important about whatever they were discussing that made it their first order of business.

After a while, we started to share thoughts as a group. Most suggestions revolved around details -- how to you check for a winner, how do you make a move. This made sense - we've spent much of the term dealing with writing code fragments to do things and not too much time thinking about overall design.

This lead to a healthy discussion of looking at things from the top down as well as bottom up.

By the end of the class, we had identified the key classes we'd need (Board, Player, UI, Game Driver) and had some idea as to how they would relate to each other. By the next morning, we added a data structure for the board.

Over the next few days we filled in the missing pieces. We moved up and down levels of abstraction being careful to discuss why we designed things the way we did and adapting pieces as needed.

By the end of the project we were able to accomplish the following:

• Students saw how to have classes refer to each other - that is, the Player class had an instance variable to hold the board, while the Game class had instances for Players as well as the Board). 
• We were able to use different user interfaces for the program -- starting with simple console input and then moving to a GUI -- all we had to do was extend the UI class.
• Likewise, implementing a computer player (albeit a rather limited one) was trivial.
• I also tried to show frequent testing and the idea of developing one concept at a time.
• We discussed the idea that while design is important, there's a point where you can over design. Be aware of the scope of a project, what can generalize, and what shouldn't.
• With a good design, it was also trivialize to change things like game rules, how to move, board size. etc.

Based on preliminary feedback, I think the students have a much better ideas as to how to break down, design, and build up a project from design to implementation.

If any one's interested, the code is available here.

We'll see if it helps with the final projects, but I'm optimistic.  Spending time highlighting the design and development process while building a project can only help.

Anyone else have interesting mid-size projects they do with their classes?

Stanford classes -- what I'd do next

Now that the ML and AI courses are at an end, here are some of the things I would do moving forward.

Both courses already have a basic track where students just watch the lectures and do the in lecture quizzes and an advanced track where students also complete weekly assignments. I think we can be certain that there were students who just watched a few lectures, many who completed every assignment, and those who fell at all points in between.

On top of this, there were students who made use of the on line discussion groups and those who didn't.

This means there ware a wide range of experiences to be had.

With this in mind, here's what I would do.

Suggestions dealing with basic site content:

More practice problems, particularly in AI


While there were in video quizzes each week that provided practice, it would have been nice if there was a link to additional optional problems (preferably with solutions available).  This would be easy to implement. The ML class would also benefit from this, but since you could retake the weekly assignments and get some variation on the questions, it would be as necessary.

Better reference materials

Reference sections would be nice as well. The AI staff posted related sections from the text, but there were a number of great on line resources I discovered by reading the discussion groups. Perhaps some of these could be linked to from the main site.

Grading


I'm pretty sure that having weekly assignments that were actually graded helped keep me honest.  The fact that the ML course was submit as many times as you want and the AI course was one shot didn't matter. I put the same effort into both classes. In a way I preferred the ML course.  I was frustrated a few times when I mis-entered something on a homework or forgot to convert units and got a lower grade than I thought I should have (I know, the grade doesn't really count).

I'd actually kind of like the AI course to move more towards the ML class model. The grades don't really count for anything anyway, and if they did, there are so many X-factors.

For example, if some one has to do the weekly assignment early due to obligations later in the week, he or she can't make use of clarifications. Likewise, students probably had widely varying amounts of time to dedicate towards the course. Contrast that to the traditional undergrad student probably has a similar workload to the other people in their classes. In the ML class, it all really didn't matter.

Office Hours:


I wasn't a huge fan of the office hour questions in the AI class but I very much liked the idea of seeing the profs directly answering weekly questions, it helped connect the instructors and the class. This was lacking in the ML class and should be added.


On running the class in the future:

What made these classes different from other on line lectures was that these were "live" with a staff releasing new content, opening and closing assignments, and adjusting as the course progressed. Each class also had a large number of people taking the class at the same time. Far different than say someone arbitrarily to watch videos from an Open Class Ware course.

I'd like to believe that the live staff, real deadlines, and large cohorts had a significant psychological effect.  I've started on line courses in the past but rarely finished them. I think the weekly deadlines and "live" aspect of the course got me to start early each week and forced me to stay up to date.

With this in mind, Stanford could just run the courses again in a similar manner, possibly with some one else acting as "instructor" to field office hours and oversee the course.

In addition I'd allow people to take the courses in the following ways:

Solo:


Since many people probably didn't avail themselves of the discussion groups, there's no reason not to allow someone to start at any time. All that would be needed is the ability to have them submit projects, quizes, etc. If the system could do that, Anyone could take the course at any time, albeit without interaction with others.

Cohort:


People could sign up with a start date or number of students in mind. When that's reached, a cohort group can start the class. The discussion pages could be modified so that a cohort can go to it's own discussion page and the system can dole out lectures and assignments on a pre-determined schedule. This would allow the course to start at a range of times while making sure that students had a community of learners to support each other via discussion groups.

Facilitated:


Similar to Cohort but someone would sign up as a facilitator. They would moderate the discussion group and control the flow of lectures and assignments. There could even be a way of "licensing" facilitators so they could run official versions of the classes. This way, a local group or school could run the class on their schedule.


So, there you have it. How I'd modify Stanford's great educational experiment. Next time, I'll share my thoughts on on-line education and how it's (mis) used in our high schools.

ML and AI Courses - how they were taught

This is the first in a three part series.

Part 1 talks about my take on how the courses were presented.
in Part 2, I'll discuss my take on how to improve the experience
and finally, in part 3, we'll look at on line education with an emphasis on the high school market.



As some of you know, I've been taking the on line Machine Learning and Artificial Intelligence courses offered by Stanford this semester. I took my AI class a hundred years ago and I never formally studied ML so I figured this would be a fun way to keep current.

Lots of people have already "reviewed" the courses, compared the instructors, assignments, and what have you. Now that the courses are almost over, I thought I'd try to look at it a little differently, wearing my hat as a high school CS educator rather than just a consumer.

I've enjoyed both courses tremendously and I'd like to thank everyone involved in making them available to the public.

Teaching style:


Every teacher has their own style.  Here's my take on our three instructors. I don't think any one style is universally better than any other, rather different styles speak to different students.

Peter Norvig: 

While watching Professor Norvig's videos, I felt that he was the learned sage imparting information. He's the wise man in the village that everyone turns to for answers.

Andrew Ng:

I felt like I was with a tutor or a coach, everything was gently presented and at the end of the lecture I looked back and said "wow, I got all of that, it made sense." As he was the only lecturer for the ML class, I'll explain in more detail in the next section.

Sebastian Thrun:

I can't come up with an analogy for Profressor Thrun, but I could feel him saying "let's try something neat, make some mistakes, explore neat things, and learn a whole bunch as a result." It took a while to get used to this, particularly when being asked questions before given enough information to approach them. Once used to the technique, however, I really enjoyed his approach to teaching.

Conclusions: I would love to have the opportunity to sit in on live classes with all three as sitting in on a class can be very different from watching a video, but being on the east coast, I don't think that will happen any time soon.

Lecture style:

In the ML lectures, Prof. Ng gently guided the viewer through the topics. Generally first by describing the various parts of the topic in question and then by bringing it all together, completely describing the algorithm or technique.

There are points in the lectures where Prof Ng states that the material is hard and that he had a tough time with some of it. This empathy and his assurances go a long way. I found the lectures easy to absorb and didn't generally have to think too hard. By itself this might have limited the educational experience, but combined with the assignments, it worked great.

The AI class had a different approach. The class was frequently tasked with solving problems before material was presented. This turned me off early on. As the class progressed, the professors started to emphasize the fact that your quiz scores didn't matter (they appear on the web site but aren't calculated in the final grade, not that the final grade matters anyway) and that these questions were to get you thinking about the topic more deeply. Once I started looking at the approach from this point of view, I enjoyed the class much more.

That said, I found the ML class lectures much more self contained and found myself looking for additional resources to learn the "base" material at times in the AI class.

The AI lectures forced  me to think more than the ML class which is probably a good thing since there were no programming projects to take up the slack.

Conclusions: Styles differ but both can be effective. I could make as much or as little a mental effort as I wanted for the ML class and I'd get out of it what I put in. The AI required more effort to get anything out of it -- the approach forced you to think where the ML class encouraged you to think. In the end, I put comparable amounts of time into both and got about the same amount out of each.

Homework and Projects:


Both classes had weekly homework assignments. Without these, I would probably have slacked off on the videos.

In the AI class, these were submitted over the course of the week and then graded. Results and explanation videos were provided after grading was done. The process was fine but I found the interface occasionally frustrating. There were some complaints on the message boards about losing points due to mis-entry or insufficient accuracy of answers. I  had a few problems with both but since I wasn't obsessed with getting a perfect score, it didn't bother me too much.

I'm not sure how great the assignments were in terms of assessments but attempting them and then watching the video explanations turned out to be a strong pedagogical approach. I would recommend including the explanation videos in the regular sequence for the in lecture quizzes. I frequently gleaned a tidbit or two from them even when I answered the questions correctly.

The only downside to the AI class quizzes and homeworks is that they were all in video form. A PDF of the midterm was published and something similar, at least for the weekly homework assignments would be a plus.

The ML class also had weekly assignments. They were in the form of an interactive five question quiz. You could attempt them up to 100 times and your top score would count towards your grade.

The real value added to these assignments was the explanations when you answered one wrong. There were even a couple of times I answered a question or two incorrectly on purpose to see the explanations provided.  This style of assessment provided a feedback loop that could really help a student to be sure they understood the work.

The one thing the AI class lacked that the ML class included was programming assignments. Probably a good thing for me since I don't think I would have had the time to be able to complete both courses with that added burden. That said, I loved the ML class programming assignments.

For the most part, they were extremely well constructed, stepping the student through all of the weeks topics. By the end of each project, we had a working system and a good understanding of the weeks concepts. You could take shortcuts and finish the assignments by merely copying and coding up formulas but if you did it right, you'd learn a lot.

The only assignment that I felt was less than stellar was the SVM project. Even then, it had redeeming features. For part of the project we had to process emails and build a table of word counts. Not directly related to SVMs but something that's frequently done with data to be processed and therefore still worthwhile.

Conclusions: The programming projects really reinforced the lecture content in the ML class and I would imagine that adding them to the AI class would benefit students. Even without them, one could go to the actual Stanford class'es web site and work on their projects.






Other random thoughts:


Both courses used the web site, email, and twitter to periodically communicate information, but the AI did one thing the ML class didn't. They periodically sent messages of congratulations and encouragement. They also repeatedly mentioned how well we were all doing in the lectures and in the office hours. Prof. Ng also provided encouraging words, but they seemed more self contained and generic.


On the other hand, I wasn't happy with the large numbers of hints and deadline extensions that the AI class offered. I felt that it rewarded people who left things to for the last minute and gave them an advantage over students who were more diligent or had to complete the weeks work early and could not take advantage of the last minute hints and extensions. Ultimately it doesn't matter, but that's the type of thing that pushes my buttons.

Conclusions: Again, both courses were great, but the AI course seemed to do a better job in connecting with the class, that is, making me feel like I'm part of the class rather than just watching.


Wow, that was long. I hope some one finds this interesting. In the next installment, I'll talk about what I would do if I were moving these projects ahead.

Reboot

A couple of weeks ago, I attended the K-12 workshop at the Grace Hopper Celebration of Women in Computing Conference. It was great to reconnect with some old friends, make some new ones, and talk shop for the weekend.

One result was that I promised to start blogging again.

I've got a number of ideas for posts lined up. Some on pedagogy, some technical, and some cultural. Hope you enjoy them.

Earlier today Ben Chun tweeted about this post: http://worrydream.com/SomeThoughtsOnTeaching/.  To summarize -- teachers should practice what they preach. In the post, Bret Victor wonders if there are calculus teachers who spend their evenings doing calculus.

I know a number of math teachers who spend a considerable amount of their free time working on problems and refining their math skills, I also know many who don't.

I know wonderful, inspirational teachers in both camps. I've also known weak teachers that fall into both categories. Great teachers in both categories also spend large amounts of time working on how to best deliver instruction.

Before I started developing the computer science program at Stuyvesant, there were one or two sections of A.P. Computer Science. They were taught by a terrific teacher -- one of my mentors and role models, but he was a math guy and not passionate about CS. When I took over, the enrollment immediately shot up. Not because I was any great shakes, and Dave, the previous teacher was legendary. Rather, the students knew I loved CS. Part of that love was that I enjoy solving problems with computers, coding and what have you. The students can tell.

The fact that I code is a byproduct of my passion and part of the whole package that defines me as a teacher and a person. Whatever success I achieve is a result of this package. It's something I enjoy, and it also keeps me current with the field.

I've seen "naturals" who are just great teachers and get by without a passion for their subjects. More often than not, there's a ceiling in terms of what they can give their students either in terms of content, or more importantly, in terms of inspiration. Some times the ceiling is high enough that there isn't a problem.

Over the years, my "practice" has taken different shapes. Early on, while my students were working on USACO problems. I figured I had better be able to represent, so I started doing them. Later on, I would write systems to support my teaching.

More recently, I've been lucky enough to be surrounded by a number of like minded educators. We frequently share little projects we work on.

This semester, I've been taking the Stanford on line AI and ML classes -- both have been lots of fun.

This is just what I do and who I am and it is reflected in how I teach.

Of course, time and job constraints make coding difficult during the school year. With ~150 students, lesson planning, grading, and ancillary responsibilities take their tolls.

So, I guess I'm an example of what Bret Victor was talking about. I'm not sure I fully agree with his thesis, but it seems to work for me.

They teach programming, don't they?

One evening, many years ago, when I was in college, I had an epiphany. Maybe not as enlightening as the epiphany I had while watching "The Mummy Returns"  many years later, but that's a story for another day.

While working on some class project, I realized that soon, within a couple of  years, I'd be working for a real company and I'd actually have to write code that REALLY works. Not just something that gets past the grader, or answers all the test cases. Something well designed, well written, maintainable, and reliable.  Scary thought.

I've thought about this a lot since I started teaching computer science. We teach programming languages, algorithms, and assign projects. Maybe the students hear something like "comment your code," or "use good variable names," but we never really give them the tools to take a project from description to completion.

Too often young programmers rush to the keyboards and write copious amounts of code without any plan and with little discipline. In short they do everything they can to set themselves up for a difficult road ahead.

There are probably a number of reasons for this. When we teach introductory  programming, assignments are so short and simple that we can't easily model good programming techniques, and if we do, it's difficult to get students to "buy in" since it's hard for them to see the value. As complexity increases, we're faced with limited time to actually cover the prescribed course content, leaving little room for a protracted unit on "program development."

I'm certainly not going to be so bold as to say that I have the answer to the problem, but I've tried some things to help address it.

We'll take a few class days to take a project from beginning to end. Something that can be done incrementally but isn't particularly difficult.

This semester, I attempted this with my AP students. We wrote a series of text filters in Java. I lifted the topic from Kernighan and Plauger's "Software Tools." We wrote versions of character count, word count, detabbing a file, run length encoding and a simple version of tr. Nothing too heavy, but it allowed us to focus on the development piece rather than coming up with clever algorithms and data structures (which is what the rest of the class is for). The problem may be a little contrived, but I hope the benefits outweighed any issues with the choice of problem.

We start by talking about the importance of understanding the problem, which includes finding out what "the client" wants and not making our own assumptions. Some times, I try to leave a little ambiguity to give us a platform to discuss the "what the client wants" issue.

From there comes design, which might be mixed with writing some code to make sure we understand certain aspects of the problem and the environment we'll be working in.

Once we have a design and a plan we can start incremental development. This is what I think is most important for the youngsters. I try to model and emphasize the idea of coding one "concept" at a time. Frequently testing that concept and only moving on once it's completed.

I'll also talk about things that have worked for me along the way. I always like to put consistent comment blocks at the top of my functions, trying to keep functions a "screen length" or shorter, my preferences for naming, indentation, etc. Of course, I'm careful to emphasize that my way works for me, but it's just one approach. I try to present alternatives when possible.

Other ideas I try to emphasize is actually reading ones code and having others read it. Last semester I experimented with "pair programming" and while I have no idea how good it is as a professional development technique, I like it from a pedagogical point of view.

I think presenting these ideas while actually developing the project helps to drive in the concepts.

I'd like to think adding units like this helps to develop stronger programmers. Any teachers out there -- your thoughts?







In an unrelated note, yesterday was valentines day. We don't really do anything to celebrate it, but in anticipation of her new loom, Devorah had to clear off some room in the apartment. She stumbled upon love letters sent between my parents back in the fifties. If you'd like a small taste of the past, you can see here post on squidknits here.

Although we have gained all this immediacy with the electronics age, it sometimes feels that somethings been lost.

Subversion in the classroom

Ok, not subversion, rather subversion, the version control system.

I've used subversion as a way for students to hand in their projects for years. I haven't used it with my intro classes as I think the learning curve is a little steep and the benefits few, but for A.P. and beyond (juniors and seniors) it's worked very well as a method of collection and I think it's good to get the kids in the habit of using versioning systems.

A versioning, or revision control system let's an individual frequently save versions of their files, in our case, on a central server.  One can easily go back to earlier versions as well as manage changes made by multiple developers. Once one's in the habit of using a revision control system, it can greatly improve  productivity.

For my classes, I would create a repository for a project, give the kids a little version control primer, and they would create projects in the repository.

There are usually a few bumps in the road.

At first the kids go kicking and screaming. They create the repository, and neglect it until the last minutes. I'd wake up on a project due date, check out the repository and seem maybe 4 out of 60 projects only to see them mystically appear as the closing time approached.

As we move through the year and work on more projects, things get better.

Students start to update their projects more frequently. Not as frequently as I like, partly because SVN gets really slow on our system, but it's still an improvement.  Invariably, it saves a student or two when they accidentally delete all their files. Also, when things become  a real mess, being able to go back a few versions is a godsend. A much better alternative than what they had to do in the past, which was restarting the entire project.



What I find really interesting is how wonderful a tool svn is from my point of view as an educator.

By looking at the log files, I can see who made changes and when. By looking at the diffs, I can look at the projects progress much as an english teacher might look at drafts.

 Version control for projects turns out to be a win across the board.

Recently, I've been using SVN for homeworks as well. Homework collection has always been difficult for me as I'm disorganized and forgetful. SVN has made things much easier. At the start of the semester, I made a homework repository for each student. They then check it out at home.

Whenever a student does a homework, he or she just names it according to our conventions (HW1-name, HW2-name, etc.), put it in their checked out repository, add the file(s) and commits. With tortoiseSVN under windows it's trivial.

This lets me easily see all of the homeworks for a student as well as all submissions for a specific assignment. Again it's an overall win.

Next semester I'm going to be experimenting with GIT as a replacement for SVN.

If you're looking for a way to collect and track assignments, I'd highly recommend using a revision control system.

Towers of Hanoi

Closed out last week teaching the Towers of Hanoi. It's a wonderful topic. Not because it's so interesting in and of itself, but as a platform from which you can explore any number of interesting topics.

Many books appropriate for the AP (AB) curriculum mention the towers, but to my knowledge most only scratch the surface. I randomly grabbed two books that I consider good from the shelf before writing this. One that I actually use when I teach AP comp sci and another more appropriate for a follow up course. Both discuss the towers, but merely show a solution and talk about the run time a little.

So many possibilities left out.

I usually do these lessons with my sophomores but since many of my AP students (juniors) hadn't ever seened the problem, I felt it was worth covering.

By looking at a few small examples, 1 disk, two disks, three disks, four disks, it's easy to notice the symetry in the solutions ultimately leading the this short routine:

 1:  hanoi(n,src,dst,tmp) {
 2:    if (n==1)
 3:      System.out.println("Move from "+src+" to "+dst);
 4:    else
 5:    {
 6:      hanoi(n-1,src,tmp.dst);
 7:      hanoi(1,src,dst,tmp);
 8:      hanoi(n-1,tmp,dst,src);
 9:    }
10:  }  

Now, the fun can really start:

We want to talk about the correctness of our algorithm and also how many moves it will take, that is, the run time. First, we'll use inductive ideas to show our algorithm is correct. This "proof" (we do it somewhat informally) can be enlightening. As sophomores, the only proofs students have seen are those statement/reason things they do in math class. Here we can introduce them to the idea that proof is just an "irrefutable argument" and apply it in a more practical setting.

From there we look at run time, that is, how many moves will it take to solve the n disk problem. It's easy to see the pattern of T(N) = 2T(n-1)+1 . Students will usually see that we can rewrite this as T(N)=2^N-1 which we can also prove by induction.

Now we can see the ramifications of the run time. At 1 million moves per second, it works out to close to 600,000 years. This in and of itself is revealing, we can't just "get a faster computer." Here we can discuss Moore's Law and the physical limits on our computers, making sure to make appropriate reference to Grace Hopper and her nanosecond.

This leads to a discussion alternate approaches such as parallel processing, but that doesn't work if our problem can only be solved sequentially.

The rest of the class is used discussing other hard problems and other approaches including heuristics, probabalistic, randomized, and anything else that comes up.

So, there you have it. From this one simple problem we get to introduce students to:

• Alternate forms of proof (specificall induction)
  
• Intractable problems
  
• Unsolvable problem
  
• Moores law and the limits of our computing power
  
• Alternate approaches to computing  
  
  
  
  • Parallel programming
    
  • Protein based computers
    
  • Randomized algorithms
    
  • Probabalistic algorithms
    
  • Heuristics
  
  

Talking Shop

During my first few years teaching computer science, I frequently felt isolated. As pretty much the only CS guy I really didn't have any one to "talk shop" with. It's hard to bounce pedagogical ideas off of your colleagues when they teach subjects that are tangentially related, at best.

I now consider myself extremely fortunate that I have four terrific friends and colleagues teaching CS with me. Now we have the same advantage that other teachers have enjoyed for years.

Today I started one of my favorite topics in my AP classes, recursion. Our students have already done recursion during the scheme unit of our intro class so today was at some levels, a review. Most of the students were fine with the basic concepts, but I wanted to make sure they had a solid foundation before we moved to more advanced problems.

I realized even though I "got" recursion back when I was starting out as a CS student those many years ago, no one ever really explained how the call stack worked. When you're calling functions and methods all over the place, how does the system know to return to the right place at the right time. It was alluded to when we expanded a recursion:

fact(4) –> 4*fact(3) –> 3*fact(2) –> 2*fact(1) –> 1*fact(0) –> 1

but never in the general sense of function calls. I thought it might make sense to try to "demystify" the computer and explain how things really worked.

I outlined a basic memory layout, stack, heap, data segment and roughly defined a stack frame (storing parameters, local variables, and a return address). We then looked at a code snippet such as:

a()
{
  b();
  c();
}

b()
{
  c();
}

c()
{
}

main()
{
  a();
  b();
}

and traced through the stack. We then did this with a couple of simple recursive examples. Only time will tell if this was helpful, but I think it was worth the time.

What I particularly enjoyed was later that day when I was talking shop with my fellow AP teacher. He wasn't planning on explaining the stack in this kind of detail but he liked the idea and planned to use that part of my lesson. I look forward to hearing how it went.

I have likewise borrowed ideas from his and our other colleagues classes.

Any CS teachers out there, I'm sure we'd all love to hear classroom techniques that have and haven't worked.

Looking for interesting questions

For the winter break, I assigned this set of A exam questions (actually, just the three that don't deal with the case study) to my AP classes. I wanted to assign something that wasn't particularly heavy but I didn't want my students to forget everything over break.

As with most AP exam questions, they're long, wordy, and somewhat brain dead. They take a long time to read, but they frequently take you step by step through what they want you to do.

I remember the first time I really thought about this. It was back when the exam was given in Pascal. The curriculum required that classes cover one of the nlogn sorts but didn't specify which one. One of the free response questions literally walked the students, step by step, through the merge sort. Part one had them split an array in to two parts, part two had them write a routine that merged two sorted arrays (and explained step by step how to do it). You could get a perfect score and still know nothing about the algorithm, or even about writing a recursive routine (since the question told you exactly what to do).

I hate these types of questions. The exam tests coders, not computer scientists. Programming competition problems (such as from the USACO) are much more interesting, but from a beginners point of view they have their own problems. Beginners might not have enough tools to attack them, and at times they're all or nothing – they're not set up to develop a simple, working solution that you can then improve on.

So, I'm always looking for interesting questions for my students. Problems that a student can attack with a minimal skill set, but can be refined through analysis or upon studying more advanced techniques.

I guess the first problem of this nature that I usually do with my AP students, usually deals with counting frequencies of test student test scores, identifying students by their four digit ID number. Most students start by creating a huge list all the tests for all the students, but some, and soon all, realize that by using the ID number as an index into an array, they can solve this type of problem much more efficiently. Looking at this technique early also sets the stage for looking at topics such as radix sorting and hashing later on.

This weekend I stumbled upon this problem and we'll probably look at in in class some time this week. I like it because you can easily get a naive solution, but it lends it self to a step wise refinement that works well in the classroom.

A few years ago, I also discovered a wonderful article by David Ginat, titled "Effective binary perspectives in algorithmic problem solving" which you can get if you are an ACM member here.

Both the stuff in Ginat's piece and the bowling ball article are nice because they can be handled naively with brute force approaches using arrays, but with a little cleverness you can do much better.

Of course, as students progress through our classes, we have more flexibility as to types of questions. For example, once we do search and other recursive algorithms a few weeks from now, I can present problems that lead to dynamic programming solutions.

I'd love to hear any interesting accessible problems you've come across in your computing careers.

Welcome

Over the past twenty years or so, I've mulled, discussed, and argued various aspects of education, computer science, and of course computer science education with friends, students, and colleagues.

This past summer, I had the privilege to get to meet and briefly work with comp sci educators from around the country and started to thing that there were other like minded people, but we didn't have a forum with which to communicate.

I also started to think that maybe some of the things I've discovered over the past twenty years might be useful to some one  if only it were available.

So, there you go. The plan is to regularly post about items of interest that I've come up  with ranging from pedagogical techniques,  to facilities management, to interesting class topics, to anything else that seems relevant. I'd imagine that some of my other interests, notably food, biking, and family will also creep in.

Hope others find this interesting and relevant.