I really liked this article. It gave me a whole lot to think about regarding how I look at programming, in terms of both how I program, and how I try to teach programming to others. In many discussions about education in computer science, I have argued that the primary thing which makes you "good" at programming is experience. This article really struck a nerve because it seemed to say the same thing, but it gave an explanation as to why that is the case (which I could never really explain.)

One of the things that really struck me was the realization that I had been entertaining a too narrow definition of the term "design." I had thought of design as a process of breaking down a programming problem into classes and their interaction (in object-oriented design), or into procedures and subcomponents (in procedural design.) I thought of it as a very high level thing. Now that I think about it some more though, it seems that all levels of structure in a program can be thought of as design. There is design involved in how you structure your functions, and how you use a for loop to iterate through a list, or a boolean flag to test for a bad element in that set of data. These were things that I relegated to "implementation details", but they are just as important a part of the process.

So, what apparently makes a better (more experienced) programmer is the set of building blocks they are aware of when tackling a problem. The blocks range from small things like boolean usage or loops, to larger constructs such as design patters, or a client-server model. As you gain more experience, you program more, and your set of blocks becomes larger and more varied. I think one dangerous thing that happens though is that it is easy to forget with experience that you have all these blocks stored away in your head, and someone with less experience doesn't. This is especially notable when people TA, and are surprised (or frustrated) that someone does not understand a simple thing which the TA considers to be obvious or trivial.

I also got a lot out of the explanation of how describing a programming strategy of breaking down a problem, or a top-down vs. bottom-up approach often isn't enough for students to be able to work with. The description of programming discourse was good as well, and I have certainly been in the situation of seeing some code that was just not good, but having trouble explaining exactly why.

Finally, I thought it was really good how the intent of this article was not limited solely at teaching programming. I can see how in other areas in computer science the same ideas hold true. For example, proof techniques in theory are very similar, in that people who have experience are familiar with the structure of proofs, and have seen lots of them. It certainly hit home to me when the paper described the scenario of a student who understands a proof perfectly when described by the professor, but is unable to derive a proof for something alone.

This article also raised the issue of teaching computer science as a tool for making a person a better thinker and problem solver. I think this is extremely valuable, because the purpose of computer science (and education in general) is not merely to produce a product, but to improve the person who is learning. While a CS major certainly learns a lot of facts, and new languages to express themself to a computer, the goal of improving the way you think and approach other problems is a very good one.

Anyway, I think this article touches upon a lot of interesting ideas. Implementing them, however, is where the challenge lies. Assuming that an experienced person has all these building blocks, how does an educator facilitate construction of these blocks in students? Examples of programs and proofs help, but I think the motivation behind vital decisions is often not focused upon enough. I think exercises such as the thoughtful programs are an excellent idea (both for teachers and students, I believe), and should be able to help develop such ability in students.

Enough rambling from me. :->

You make a great point about scaling desing down to the the implementation level from the high level of abstraction at which we usually view it. It will make your thoughtful programs that much better if we explain our design decisions not just on the large scale ie: describing our choises in terms of classes, but at the low level ie: why a for loop works better than a while loop in a particular instance.

Perhaps this method will carry over into students' problem solving abilities as they will be able to start at the ground level and then work their ways up instead of starting with a shakey foundation.