The closing keynote at CSTA was by Michael Kölling, creator of Greenfoot and BlueJ. The gist of his talk was that learning to program is not the same as being a professional programmer and the tools one uses for each should be different. In fact, he said that the tools you need to learn are the opposite are what you need when you’re programming professionally. Block-based programming languages are great for learning, but the tools for text-based programming tend to move quickly into the professional programming area and are too hard to use for learners. There’s not much in between.
Kölling then demoed a new tool that is that in between space. It eliminates the issues of missing curly braces and semicolons and automatically groups blocks of code together (boolean statements, for example). It seems like a very promising direction. I enjoyed much of what he said, and have been arguing for years (sometimes with programming parents) that learning to CS is not learning software engineering.
Four years ago at my first CSTA conference, I had lunch with a woman who claimed that every CS teacher should work in industry for 2 years before they teach CS. I found it very frustrating because I believed that teaching CS is very different thing and requires different skills than what one might get from working in industry. The tools change and depend on what part of industry you’re in. If you’re building apps, your tools are going to be different from someone in web development. It doesn’t make sense to me to teach those tools to a freshman in high school.
In evening, I hosted a #makered chat where we discussed the intersection between CS and Making. It was a lively discussion. My sense of things is that Makers use coding a lot and in fact, we sometimes hear that those who don’t code much feel like they’re not doing “real” making. I don’t think that’s true. Many maker programs (like mine) have come out of CS programs or are incorporated into it. However I’ve heard some CS people not want to deal with hardware or electronics (much less paper, glue, and glitter). I was thinking about this intersection more, and here’s how I think it works:
Computer science and making both include coding, but Computational Thinking is the umbrella for both, I think. CT doesn’t need coding necessarily. The Rube Goldberg machine we made involved a lot of computational thinking (the logic alone was quite challenging), but no real coding. Thinking broadly makes the relationships make sense and eliminates some of the territorial-ness some people feel about both CS and Making. Maybe there’s an even broader category we could use, but computational thinking makes the most sense to me.