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.

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?