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.

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.