> Hold it in your head! Or you won't have a clue what all your code, together, is doing.
Do you mean to say: if you can't hold it all in your head, you're overcomplicating things? Because if so, I agree.
I just finished giving an introduction to programming course, using Processing. I tried teaching my students to write structured code from the start, splitting functionality into smaller methods as much as sensible. That way they never have to juggle too much functionality in their head at once.
On the first day I had them call built-in methods. Then I introduced the concept of variables and types, then I introduced defining your own methods, and only after that did I move on to booleans, if/else, for-loops and arrays.
It seems to have worked well for getting them to structure their code from the start, using methods more or less the same way you would use chapters, headers, sub-headers and paragraphs to structure a paper.
I know this isn't the best way to program, obviously, but this analogy is (relatively) easy for them to understand and loads better than the ball of muddy spaghetti you often see with people who just start out. It's also probably fairly easy to make the jump to other more advanced forms of code organisation.
I also completely agree with your other two points by the way, I kept repeating similar statements throughout the course:
- By splitting functionality into small methods, it's easy to test if something does what it is supposed to do (and I could easily correct them: "Hey, this method drawBall() is also doing hit detection. That's not what the method is supposed to do, restructure the code!").
- "The computer only does what it is literally instructed to do. What do you literally want to do? What are you literally instructing the computer right now?"
When I see students posting on /r/programming, what they usually seem to have a problem with is problem decomposition. i.e.: What are the steps needed to solve this part of the problem? Or algorithm design, critical thinking, or whatever you want to call it. How do I get from A to B, basically.
Remembering back to my first year, it seems that some people "get this" and some do not. Which is nothing against them -- everyone is different.
> - "The computer only does what it is literally instructed to do. What do you literally want to do? What are you literally instructing the computer right now?"
I feel like after you really know a system you almost start thinking only in terms of its components. "Hmm I want to do X...somehow I just automatically thought to modify function Y and call it in module Z."
Do you mean to say: if you can't hold it all in your head, you're overcomplicating things? Because if so, I agree.
I just finished giving an introduction to programming course, using Processing. I tried teaching my students to write structured code from the start, splitting functionality into smaller methods as much as sensible. That way they never have to juggle too much functionality in their head at once.
On the first day I had them call built-in methods. Then I introduced the concept of variables and types, then I introduced defining your own methods, and only after that did I move on to booleans, if/else, for-loops and arrays.
It seems to have worked well for getting them to structure their code from the start, using methods more or less the same way you would use chapters, headers, sub-headers and paragraphs to structure a paper.
I know this isn't the best way to program, obviously, but this analogy is (relatively) easy for them to understand and loads better than the ball of muddy spaghetti you often see with people who just start out. It's also probably fairly easy to make the jump to other more advanced forms of code organisation.
I also completely agree with your other two points by the way, I kept repeating similar statements throughout the course:
- By splitting functionality into small methods, it's easy to test if something does what it is supposed to do (and I could easily correct them: "Hey, this method drawBall() is also doing hit detection. That's not what the method is supposed to do, restructure the code!").
- "The computer only does what it is literally instructed to do. What do you literally want to do? What are you literally instructing the computer right now?"