What's Next

Just a short follow up on the last post.

In thinking about how I frequently programs, once I have a plan, I work on one part of the project, and then ask myself "what's next?" That is, what is the next step towards completion.

It reminded me about a guest speaker we had a about a year and a half ago at one of our "professional development" days. For the past two years, our school has had "writing across the curriculum" as one of it's goals. While it's a laudable idea, I find the rationale for this goal to be poorly communicated to our faculty and the implementation weak at best.

Regardless, the guest speaker, William Zinsser, made a few good points.

The most important reason for most of us to write is to convey ideas or arguments. In short, communication. Many students have problems organizing and ordering their thoughts and as a result, their writing is all over the place. Zinsser simplified it to the following:

1. What does the audience know?
2. What do they need to know next?

That drives your next sentence. You continue this 1-2 punch until you've communicated your ideas.

This makes loads of sense, but here I was 40 years old and it was the first time I heard writing explained this way. What really struck me, however was that this concept wasn't new at all. Every ninth or tenth grader goes through this process time and time again.

Think about geometric proof. We have some given information and a conclusion we wish to prove. At each step along the way its:

1. What do we know so far?
2. What's the next step to get us closer to the conclusion?

Same idea.

The same can be said for program development.

Of course this makes tremendous sense since all thee things: writing, proof, and programming, are methods of communication.

Just something to think about.

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 for Homework part II and the start of the new term

Starting the new semester tomorrow and I've got a whole bunch of interesting topics to blog about. Some about pedagogy, some technical, and some that I can't really catagorize.

For now, though, just a brief follow up on using Subversion for homework collection.

The basic model used in New York City for teacher improvement and evaluation is the official "observation." Either your supervisor or the principal sits in on one of your classes. Afterwards you meet and discuss the lesson and a report is written up. Basically, there are two possible outcomes: satisfactory or unsatisfactory.

Untenured teachers are generally observed three times a semester. Tenured teachers, once a year.

In all cases, this system is severely flawed. The supervisor sees a 40 minute snapshot out of context and is supposed to evaluate the teacher and make recommendations for teacher improvement. It's generally of limited value at best.

Because of this, years ago, I started to ask my students to evaluate me. For quite some time now, I've used a custom written web app that allows students to complete long questionnaires over a period of weeks. The system allows me to know who submitted an evaluation while maintaining anonymity.

I've found these evaluations to be incredibly valuable and I've used them to try to improve my classes and my teaching over the years.

Having just wrapped the semester, I've gone through my students responses and the vast majority liked using subversion for homework. As I figured, some felt that it was a little confusing at first and there was a learning curve but most felt it was either as good as any other method and many said it was superior.

This combined with the fact that it makes me more efficient confirms that it's a win.

It was also interesting that I had hardly any suggestions for alternative ways of collecting homework.

Recently, I've been using Git for my personal development work and I'm planning on experimenting with it in one of my classes, so we'll see how that goes.

Now, on to the new semester!!!!!