The Progression Paradox, or Getting Ahead of Ourse

Published October 02, 2007
Advertisement
Learning resources identify a problem/challenge and then supply methodologies, techniques, best practices, rules of thumb and whatnot for avoiding/overcoming/solving it. The nature of the problem can vary from fatal - the program doesn't run, for example - to structural - the program is hard to maintain and extend - and so on. The one is obvious to all; the other, in this case, is meaningful only to those sufficiently advanced to have encountered it.

When writing a learning resource suitable for complete beginners, then, how do you address the challenge of presenting a technique or practice that solves a problem the student has not yet encountered? This is why most introductory C++ texts read so horribly; using inheritance to solve the "problem" of making different mammals "speak" is meaningless because most beginners aren't interested in that issue (and probably never would be, if it weren't for classes/textbooks). Similarly, refactoring x- and y-axis velocities into a single vector type is meaningless to beginners because they haven't experienced the downsides of not doing so yet.

How do you present a good practice like refactoring without getting ahead of your audience?
Previous Entry Showing vs Telling
Next Entry Time and Motivation
0 likes 5 comments

Comments

Jotaf
First, make them experience the downsides of the bad method (as an exercise). Then, show them the right way and they will be stricken with awe when they realize your power and awesomeness :D
October 02, 2007 12:38 PM
TANSTAAFL
think like your target audience.

beginning programmers tend to:

-put everything into a big main function/script.
-make all variables global.
-make poor choices of variable names(too short, cryptic, reused inappropriately).
-repeat code instead of putting common tasks into functions/classes.
-have an array of x values and an array of y values that are related rather than write a struct to contain a 2d point and make an array of those.
-have no indentation strategy.
-have no capitalization scheme.

at best, we can hope that he has familiarity:

-some manner of input from the keyboard or mouse.
-some manner of output to the screen.

and really that's all we need: some method of input, some method of output. the rest we can build on.

a big moment for any beginning programmer (and even any programmer of experience in a previously unexplored environment) is when the user is able to put some sort of graphic on the screen (it has often been a single pixel in my case), and has been able to move it around with the arrow keys. from there, one is only a couple of steps from an etch-a-sketch program or a single player tron lightcycle thingie.

October 02, 2007 02:03 PM
Oluseyi
Quote:Original post by TANSTAAFL
beginning programmers tend to:

-put everything into a big main function/script.
-make all variables global.
-make poor choices of variable names(too short, cryptic, reused inappropriately).
-repeat code instead of putting common tasks into functions/classes.
-have an array of x values and an array of y values that are related rather than write a struct to contain a 2d point and make an array of those.
-have no indentation strategy.
-have no capitalization scheme.

I did nearly all of these for the revision 1 version of the game, except that indentation is syntax in Python, so you can't get away with that. But I repeated code, and I'm only just pulling it out and refactoring into functions/types. Hopefully I've done a good enough job illustrating the pitfall and the solution.

Quote:a big moment for any beginning programmer (and even any programmer of experience in a previously unexplored environment) is when the user is able to put some sort of graphic on the screen (it has often been a single pixel in my case), and has been able to move it around with the arrow keys. from there, one is only a couple of steps from an etch-a-sketch program or a single player tron lightcycle thingie.

[smile]
October 02, 2007 02:41 PM
Oluseyi
Quote:Original post by Jotaf
First, make them experience the downsides of the bad method (as an exercise). Then, show them the right way and they will be stricken with awe when they realize your power and awesomeness :D

LOL. Like I mention above, I think I've done this, but only the target audience will be able to tell me if I've done well enough.

Anyway, I've taken several days off. I think I should use my current pseudo-downtime to iterate on the code a bit...
October 02, 2007 02:42 PM
Facehat
I think as someone else mentioned, its probably best just to let them fail so they understand why the various best practices are actually good ideas. Honestly beginners are going to write atrocious code anyway, so its probably best just to give them the tools they need to create the biggest baddest atrocity they possibly can, and then slyly offer them the solution after they spend a while thinking "oops" :-). I wouldn't even really talk much about The Right Way To Do Things in the beginning -- just tell them how to put an image on the screen and make their speakers beep, things like that.

Besides, I think the best way to learn something is to play with it. And it's hard to be playful when you're spending a ton of time thinking "wait, is it ok to write this this way?". I think it's better just to make the mistake then it is to spend a lot of time worrying if you're going to make a mistake.

Plus, teach them advanced topics too early and i think you'll give them a tendency to over-design things. Things like inheritance are really easy to screw up spectacularly.
October 02, 2007 03:02 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement