I have done a poor job on two really important concepts and looking to see i anyone has a lesson plan they thing really worked.
The first is just the concept of variables in general and then the details of
local vs. global variables
declaring (var), Assigning (=) and logic (==)
I taught all the bits but it seems to need a single lesson to go over the whole bit.
The second is Abstraction!!!
It seems the central concept here is “managing complexity” but there is also a more practical aspect which is something like functions that call functions. The former seems to be most applicable to the design phase where the student plans for what functions they might write and the conceptualize managing the complexity with “layered” functions. The latter is more like drawPlanet and drawAllPlantes and then draySpace. I think what is missing is a strong lesson plan on design where a students plans for what functions they might write and how those will manage complexity.
A third is Debugging
It wasn’t until just this week that I noticed the debugging tools in appLab where you can pause the running program at a specific line and step through. I that new?
Debugging tools are not new. They are introduced in Stage 11. They don’t talk about them extensively but do show how to set break points to pause execution, step in and run one statement at a time, and to see values of variables at a particular instance.
…yep. These are the biggies! Hard to teach in any circumstance. There’s also the question of the tricky balance between how deeply you need to know these concepts for CSP v. to make any cool thing you want.
I would love to figure out a way to facilitate some discussion around these more advanced topics. Certainly I could talk, or write, about them for hours. Which I’m going to avoid right now
The challenge with teaching local versus global variables is explaining “why”. Why aren’t all variables global? In the small, relatively simple programs our kids are writing for APCSP, it’s hard to understand why global variables are frowned on, generally. Which makes the local vs global discussion feel arbitrary, some made-up rule just to complicate things. It’s not hard to demonstrate how global and local variables behave, but it’s not easy to explain the “why” when kids are working on short, self-contained programs by themselves, where they can easily control variable names and assignments.
As for abstraction, I think the AP (and code.org) get a little too philosophical. My kids understand why one should write a function to save on repetition, and simplify program structure. They can easily answer the question, “what’s the value of a function?” But if I ask them to explain why a function is an example of an abstraction, they get twisted up in the vagueness of the meaning of “abstraction”. It reminds me of the discussion of symbolism in literature, and what the light at the end of the dock in Gatsby means
Most of my teaching of debugging was over-the-shoulder, and hands on. Showing kids how to use things like console.log to figure out what the variable was really set to, and commenting out blocks of code to figure out what part of their program was actually having trouble. When I did find an interesting problem in a kid’s code I’d often throw it up on the big screen, and have the class try to figure out what was going wrong. And there was a lot of peer debugging going on, with seat mates.
I like David Malan’s explanation about how we think about Countries…broken down all the way to the wood that makes up the houses of the towns of the counties of the states, etc.
The Big Idea is that Abstraction lets you think about problems at the right level of detail for that problem, without having to worry about all of the other details it’s built upon. When you’re thinking about countries, you don’t have to worry about the wood making up the houses. Obviously you wouldn’t have a country without the wood, but when working on problems at the full country level you rely on the lower level details being in place - you can “abstract those details away”.
One way to think about abstraction is: you have to know that certain things work at lower levels of detail but not how. To make decisions about a country you have to know that houses are a thing that people need to live in, but you don’t need to know how they are build. Your brain couldn’t handle thinking about solving problems for a country if you had to worry about how the lumber was being milled at the same time.
There are 3 similar analogies for Abstraction that you can draw from student experience in the Code.org curriculum. The Big Idea of Abstraction spans:
The Internet. For high level protocols like HTTP or DNS, they rely on lower and lower level protocols working reliably…all the way down to the individual bits getting physically transferred from one place to another. HTTP doesn’t need to know how the bits are being sent from one place to another, just that they can. The whole internet sequence of lessons worked from the bottom up: after students solved one problem of data transfer, we “abstracted it away” – assumed that it worked as designed – and solved the next problem on top those assumed details. e.g. you can’t have packets without IP addresses working first. You can’t send large messages without reliable packet transfer working first, and so on.
Data. Bits are the lowest level of detail in a computer, but they are meaningless without some definition about how to use them. When working with digital images for example, you really don’t need to worry about the bits. You need to know that they are made of bits but not how in order to use photoshop, for example. But in thinking about the data itself: In order to represent an image, you need a way to represent color. To represent color you need a way to define colors with numbers. In order to represent numbers you need a way to represent numbers with bits. Each of those is a problem to solve. This was the inspiration for the Encode an Experience activity - thinking about the layers of abstraction that start with for example “A Birthday Party” and whittle all the way down to the bits. It’s very similar to David Malan’s example of thinking about a country, in that way.
Programming. We write functions to abstract away lower level detailed problems. To draw a digital “under the sea” scene, you need to think about composing water, and fish and seagrass. To make many fish, you need to know how to make one. To draw a fish, you need to think about the shapes and colors that make it up. and so on. Next think about seagrass, etc.
One slight nuance is that in computer science we often do actually have to worry about all of the mundane details at some point. So Abstraction is more of a practical thinking and problem solving skill to help you make sure you’re dealing with the right amount of detail for any given problem. In order to make the internet, or encode a human experience, or draw that digital scene, your brain cannot handle all of those details at the same time. So you have to break the problem down into progressive layers of abstraction in order for YOU yourself to solve a series of problems that can build up to a solution for the larger one.
thank you for the thoughtful response. I completely agree on the global vs. local. The one local variable that helped me explain it (after the fact - I will be soo much better at this next year) is “i” in a for loop. If you have multiple for loops and “i” was global and not declared locally then the loops would get all goofed up.
Agreed again on Abstraction. I have boiled it down to “managing complexity” for my students and have just started to think of it more as a design consideration.
That is how I have done debugging as well. I think next year I will provide buggy code and explicitly teach the debugging tools in the full version of AppLab. I found many of my students wanted to be in the full version earlier than the lessons called for. Fortunately, the design of the tools allowed for this.
Thanks again for helping me to think through this.
