4 ms·

I don't think there should be a difference, it's just a matter of scale. When they start off coding, it might mean an entire week spent in a single python file

by malux85 11y ago

I don't think there should be a difference, it's just a matter of scale. When they start off coding, it might mean an entire week spent in a single python file: The 50,000 foot view might be "Printing Restaurant Menu", the "line of code" view, might be getting the price of pizza. We're not talking architecture, or operating systems, or networking, or boolean circuit logic, or anything, we're just printing their favourite food menu - a practical example of shifting perspectives. Once they can shift easily, then we expand it in both directions - Now print menus for 10 restaurants. Now find the most expensive pizza. I think these lessons can go hand in hand with Math -- too often the main complaint with Math is that it's too abstract (When am I ever going to use this?!) whereas if the Math lesson about averages tied into the coding lesson for printing the menu (Now find the average cost of all pizzas) kids might be able to see it as useful

amelius 11y ago
Let me make an analogy: we're not going to teach kids how the food industry works before we're teaching them how to bake a cookie. We're also not teaching them about city planning before they had a chance to put some lego bricks together. I think the important thing here is that kids need to see the necessity first. Only then can they start to deal with more abstract concepts. And actually, I don't think this applies to only kids. I think it is the reason that "learning by doing" is so much more effective than anything else. To give an example related to programming. I have seen CS students use preconditions and postconditions (i.e., assertions), on functions, without understanding why they were using them. They just wrote those assertions because the teacher said they had to do it. Of course, the assertions are useful, but only for large, more complicated, programs. But since the assignment programs were all small, the usefulness of this particular software engineering instrument completely eluded them.
- steven2012 11y ago
  100% agree. Trying to teach them to break things up into modules won't make sense to them, unless they write a 1000 line program, and then go to change it and things break. They have plenty of time to learn good software engineering practices, decades in fact. They don't need to be a genius at first strike, they just need to learn how to code. Trying to teach them perfection at the beginning is a huge mistake.

by malux85 11y ago

amelius 11y ago

Let me make an analogy: we're not going to teach kids how the food industry works before we're teaching them how to bake a cookie. We're also not teaching them about city planning before they had a chance to put some lego bricks together. I think the important thing here is that kids need to see the necessity first. Only then can they start to deal with more abstract concepts. And actually, I don't think this applies to only kids. I think it is the reason that "learning by doing" is so much more effective than anything else. To give an example related to programming. I have seen CS students use preconditions and postconditions (i.e., assertions), on functions, without understanding why they were using them. They just wrote those assertions because the teacher said they had to do it. Of course, the assertions are useful, but only for large, more complicated, programs. But since the assignment programs were all small, the usefulness of this particular software engineering instrument completely eluded them.

steven2012 11y ago
100% agree. Trying to teach them to break things up into modules won't make sense to them, unless they write a 1000 line program, and then go to change it and things break. They have plenty of time to learn good software engineering practices, decades in fact. They don't need to be a genius at first strike, they just need to learn how to code. Trying to teach them perfection at the beginning is a huge mistake.