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.

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? 

My Favorite Student

Fred Wilson and me at #SOTC2012

Last week I was given the honor of attending the State of the City address. The mayor was announcing a new school for the fall. An Academy for Software Engineering. This has been in the works for a while and has a long way to go but the announcement was a major step. The project really got its start a couple of years ago. I'd been working hard for years prior trying to get the city to help me grow the program I developed at Stuyvesant, but until Fred got involved, there was no movement. Fred has to receive much of the credit for any good that we do as a result of this and I'd like to publicly thank him. If you don't follow Fred, you can read his post on the school here.

It was pretty neat to be on stage for the announcement, but those of you who know me know that I'm not a self promoter and these types of events aren't "me."

 What I found really special, were the emails and tweets I got from my former students over the next day or so. As a teacher, we'd like to think we are in some way a "force for good" in our student's lives and we rarely get to really see what impact we do or don't have. To hear from so many and such gracious comments brought tears to my eyes. Thanks guys.

I've been thinking a lot about my career as a teacher recently. I decided to leave industry over twenty years ago. As teachers, particularly teachers with technical backgrounds we leave a financially lucrative field to enter one with very few financial rewards. It's also a field very much under attack, particularly in recent years. The current line of thought seems to be that teachers are to blame for everything bad in education and government and private interests, everything good. As a senior teacher, I'm particularly worthless, at least according to what I've heard on the radio over the past year.

So, what do I get out of the deal?

Well, when I hear form my graduates, I know that I've made a difference. 

Also, the friendships I've developed over the years.

Stuy '84, '95, 2013, 2015 and families

A few weeks ago, we were catching up with a few of the Stuy '95 crew. We do it far too infrequently. They were students, they're now friends. I've had the privilege of seeing many young people grow to adulthood, get married, have children and in a small way I've been able to share in their lives. This is the upside of my career choice.

Maybe this is a result of being a computer science teacher who tries to keep a foot in the tech world. Maybe something else.

From the college student who stops by just to say hello to the graduate living across the country who drops a line to say how they're doing. That's the upside of the teaching profession.

Recently I thought it would be a good idea to organize the Stuy CS family. Collect email addresse and get a network going. I posted on facebook and sent out a few emails two days ago. So far, 240+ signups.

A while ago someone asked me who was my favorite student?

They're the ones that I'm still in touch with many years after they graduate.

Where's Waldo - Text style

Ok, it's a word search.

We're always looking for interesting applications to build lessons around. Over the years, I've tried different things when teaching 2 dimensional arrays. Simple game boards, representing a crossword puzzle, tables of various sorts, etc.

This year, JonAlf, one of my amazingly talented colleagues, decided to go with building a word search. I decided to steal the idea. It's a great one.

I thought I'd use this post to go through the project and why I like it.

Ultimately, the students end up with a program that will generate an n by m word search filled with random words from a dictionary. We gave the kids a skeleton of the base class. The only actual code we had to supply was the method that loaded a dictionary file into memory. You can check out the assignment here and the finished code here (we updated the repository as the project developed).


The first part of the project are pretty mundane. The kids write a couple of constructors and toString. Basically just practice traversing a 2D array. The project starts to get interesting at part 2, when they write the methods that add words into the grid. First horizontally:



After they write the method to add words vertically, we can start to refine things. We notice that the routines are essentially the same. The only difference between adding a word horizontally and vertically is  what we add  to the row and column each time. For one, there is a delta column of + 1, for the other it's a delta row. Further, they realize that adding diagonal words just needs both deltas. This leads us to factoring out the common aspects of the code and writing something like:



All of a sudden, they've written one piece of code that can add words in 8 orientations.

After filling the rest of the grid with random letters, we turn our attention to building a random puzzle.

This part of the project involves using an ArrayList of words. Our students frequently mix up array and ArrayList notation early on so by having a project that uses both but in clearly delineated areas, the students can be more comfortable with each.

For this piece, the code is again straight forward. Students run a loop that gets a random word from our dictionary and tries to place it in our grid at a random location choosing one of our possible orientations randomly. We get to see another nice little refinement again when we move from the typical first take at building a random puzzle which uses a three (or more) way if statement to select how to add words:



to using our more general addWords method described above:




When we're all done, we had some time to project the word search on the board and fun was had by all.

Peter, another one of our CS teachers had a great suggestion that I think I'll try. Start a competition to have the students modify the program so that it generates as densely packed  a wordsearch  as possible (giving higher scores first for longer words, then number of words).

Between the way the project broke down, the topics covered and the little refinements, I really enjoyed working with my classes on this project -- I'm hoping they enjoyed it as well.

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.

Sorting from the top and from the bottom

I've been meaning to write this post for a couple of weeks, but some times life just gets in the way.

I've always thought it important to arm students with as many different tools with which to attack problems as possible. As such, the courses I teach use a number of different languages, each highlighting a different paradigm and thought process. The hope is that by the end of the sequence, they can look at problems from many different angles.

In my advanced placement classes, we recently studied sorting algorithms. It think the quicksort is a good example of a problem that can be looked at from multiple points of view.

In my experiences talking to teachers and students who cut there teeth using languages like Java, C, or C++, much of the discussion deals with the actual partitioning of the array. Comparing elements, swapping them and arriving in the middle. One might end up with something like this as a first cut:

 1:  public void qsort(int[] a,int l, int h)
 2:  {
 3:  if (l>=h)
 4:    return;
 5:  
 6:  /* Just use lowest index as pivot for now */
 7:  int pivot = a[l];
 8:  int low=l;
 9:  int high=h;
10:  
11:  /* partition the data set around the pivot value */
12:  while (l<=h)
13:  {
14:    while (a[l]<pivot)
15:      l++;
16:    while (a[h]>pivot)
17:      h--;
18:    if (l<=h)
19:    {
20:      int tmp=a[l];
21:      a[l]=a[h];
22:      a[h]=tmp;
23:      l++;
24:      h--; 
25:    }
26:  }
27:  
28:  /* sort items below and above the pivot */
29:  qsort(a,low,l-1);
30:  qsort(a,l,high);
31:  
32:  }

A fair amount of time and detail is spent dealing with the low level movement of data within the array . This is important – good stuff, but it takes the emphasis away from the higher level elegance of the algorithm.

The quicksort can be described as:

1. If the size of the list is <= 1, return.
2. 1. Select a pivot element
   2. Generate the list L of items smaller than the pivot
   3. Generate the list H of items larger than the pivot
   4. the sorted list is qsort(L)+pivot+qsort(R)

Having seen some scheme in their intro class, our students have a tool with which we can describe the quicksort in terms much closer to the description (allowing for the fact that this doesn't deal with multiple values equal to the pivot correctly):

 1:  (define makefilter
 2:    (lambda (op x)
 3:      (lambda (n) (op x n))))
 4:  
 5:  (define qsort 
 6:    (lambda (l)
 7:      (cond ((null? l) '())
 8:            (else (append (qsort (filter (makefilter > (car l)) l))
 9:                          (list (car l))
10:                          (qsort (filter (makefilter < (car l)) l)))))))

This allows us to discuss the quicksort at a much higher level and focus on things like selecting a good pivot or the analysis of the run time. I believe this makes it much easier to really understand what's going on.

Having discussed it in this functional context, we can also look at the same thing in a scripting language such as python:

1:  def qsort(l):
2:      if len(l)<=1:
3:          return l
4:      else:
5:          return qsort([x for x in l[1:] if x <= l[0]]) + [l[0]]+\
6:              qsort([x for x in l[1:] if x > l[0]])
7:  

Again, the focus is on the algorithm, not the array or list manipulation.

Looking at the problem from both the more abstract side, which in this case functional languages allow, and the more concrete, as we did in Java gives our students more tools with which to attack problems.

Just some food for thought.

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.