3 ms·

https://appsbykids.org/ https://appsbykids.org/ is a hastily thrown together site showing some of my work with kids. I've been running volunteer computer clubs

https://appsbykids.org/ https://appsbykids.org/ is a hastily thrown together site showing some of my work with kids. I've been running volunteer computer clubs at schools my daughters attend, pre-covid anyway. I've also run a summer immersion program for basic software design principles using the Scratch language for Girls Who Code. We've played with Adafruit Circuit Playground dev boards, written a "choose your own adventure" engine with Python, and added pixel graphics to some simple Javascript games, where the kids drew animation frames in a barely functional editor I wrote. The first thing I'd call out is that 7 is really young. 5th grade is the point where kids can start to "get it" beyond basic maze problem solving things (e.g., code.org's Minecraft puzzle - hop Alex around the creeper and into the house). Since you're a dev, and he's enthused about it already, he can probably flex those muscles a little early. Beyond age, the complexity of what you're doing matters a lot. Kids want to see something get on the screen right away, and they want to make a code change that changes what it does. Building a program from scratch is a chore, and something as simple to us as nested if statements will throw them for a loop. The most success I had was building a simple program without them, and letting them experiment with changing values. That may sound like cheating, but it gets the gears turning, and before too long they're able to follow along with making a broader logic change, and soon enough even following along with you adding a new feature. I was in a classroom setting with a bunch of kids, and they tended to like being in small groups and comparing notes, or play each others games. Sideways thinking is important. For example, the main draw of Circuit Playground is making the LEDs do things, but they also have an accelerometer. A good exercise was figuring out how to read the tilt position, and figure out which light was lowest, and light up just that one. Instant fidget spinner. Building on that, I threw them for a loop by using the same principle where the tilt was input to a computer program. Suddenly the thing they were programming before to flash lights was now a game controller. Keep it fun, let him screw around too long on things he builds instead of learning software engineering at an "acceptable" rate. He can learn fast, but complexity will probably be a struggle, so growing slowly is just fine. Encourage him to explore concepts from different angles. Hope that helps.

lmilcin 6y ago
Yes, tinkering with existing program is really fun. I did this with his first ever project (which was a robot programmed in block language that is even simpler that Scratch) and made entire program for him, with him sitting by me and discussing how I am adding new steps to the program and what they are changing, each time running the program on the robot with another step implemented. Then he got his turn to have fun with the program. We stopped with that robot after couple of sessions when he was able to program some functionality up to my specification. For example, there was no sensor that would say the arm was closed, so to preserve the worm drive I asked him to change all places in program where the arm is getting opened to instead close it first and then open for an exact amount of time so that it does not hit the limit, which he was able to do on the first try, which gave me confidence he more or less understands what the idea is. Now, the games we do are getting a little bit complex (a lot of messages flying around), so what I do is basically write most of the code and shape the structure of the program and figure how do to some stuff so he doesn't get lost managing complexity. I make sure he understands what the things are doing and he modifies whatever he wants (and then we discuss what happened or how he can get what he wants). I am now unsure whether I want to stick to some more complex projects or whether it is better to have more small but wide variety ones. For now what I plan to do is to throw a bunch of ideas and see which ones he is most excited about.

lmilcin 6y ago

Yes, tinkering with existing program is really fun. I did this with his first ever project (which was a robot programmed in block language that is even simpler that Scratch) and made entire program for him, with him sitting by me and discussing how I am adding new steps to the program and what they are changing, each time running the program on the robot with another step implemented. Then he got his turn to have fun with the program. We stopped with that robot after couple of sessions when he was able to program some functionality up to my specification. For example, there was no sensor that would say the arm was closed, so to preserve the worm drive I asked him to change all places in program where the arm is getting opened to instead close it first and then open for an exact amount of time so that it does not hit the limit, which he was able to do on the first try, which gave me confidence he more or less understands what the idea is. Now, the games we do are getting a little bit complex (a lot of messages flying around), so what I do is basically write most of the code and shape the structure of the program and figure how do to some stuff so he doesn't get lost managing complexity. I make sure he understands what the things are doing and he modifies whatever he wants (and then we discuss what happened or how he can get what he wants). I am now unsure whether I want to stick to some more complex projects or whether it is better to have more small but wide variety ones. For now what I plan to do is to throw a bunch of ideas and see which ones he is most excited about.