# Is it a good idea to have students see syntax much earlier than they write it themselves?

I was wondering if there was any research on whether or not students generally perform better later if they're introduced to the syntax they'll be learning far earlier than they actually use it.

As an example will students ultimately learn import/export better if they're given code that has import statements in it long before they actually create their own modules; or will introducing the syntax too early be more likely to overwhelm students if they haven't been taught what it does? If the former is it likely to distract or worsen the students from learning the current objectives?

If there is more specific research than just yes/no I'm definitely interested. For example things that would be useful to know:

• Are there certain ways to classify students where some group will benefit or detriment from being introduced to syntax early?
• Do certain age groups handle early introduction of syntax better?
• Is there some minimal skill set after which early introduction of syntax will begin to add benefits?
• Welcome to the site. Nice question. I have added an answer; just my opinion. Hope you get a more research based answer though, as I am interested in the result. – ctrl-alt-delor Sep 11 '17 at 7:46
• Seems this could equally be asked on a language stack - with regard to either vocabulary, or grammar. More likely to be research in natural language teaching, I expect. – Sean Houlihane Sep 11 '17 at 18:09

### Boldly Go...

First, I'll just say yes, it is a good idea to introduce things (let students see them) before they have to deal with them in detail. There is actually a Pedagogical Pattern, See Before Hear, that suggests that it is a good idea to let students see things before you even lecture on them. This isn't true about just syntax. The essence of the Spiral pedagogical pattern is that you teach things repeatedly to different levels of detail over a course and a curriculum. I'm pretty sure you would think it foolish if the first time the students hear the word "compiler" is when they need to build one.

### Research

But to address the question of "Research" is a different issue. I think the kind of thing you might mean by research would likely be unethical. Educators, like doctors, have a "do no harm" directive. You can't run an experiment in education in which you even suspect that some technique might be worse than another, but apply the two techniques to two groups. You run the risk of doing harm to one group. You can only apply techniques that you believe to be best practice.

The only kind of experiment that would be valid is to poll teachers on their practice and then either (a) ask them how their students do or (b) somehow measure their students actual performance. The first is just opinion based and the second is very difficult to arrange, partly because it can be disruptive to the educational process. Another reason why such research is usually not repeatable (hence basically invalid) is that there are too many variables in education: between teachers, students, environments, etc.

### An alternative: Patterns

Patterns, are a kind of "experiment" in that they are a means to capture the practices of experts, vetted through a process (the patterns process) by other experts. The process is quite involved requiring many re-writes to have a pattern accepted. This is true of all patterns of course (design patterns, org patterns, etc.), not just pedagogical patterns. The pattern not only includes the what should be done but the why this is the right thing to do (resolution of forces).

Another pedagogical pattern that pushes your syntax idea to the max is the Fixer Upper pattern in which you give students a fairly large program that (a) has good structure overall, but (b) you have broken in some well determined ways. The student task is to repair the program. This can be a first day exercise, in fact. The students first look at any syntax is a complete program that they need to work through.

One of the reasons that this sort of thing "works" is that (a) much of what you want to teach them they may already know or will pick up instantly, but (b) which particular things that is differs for each person. Letting students see an organic whole lets each of them draw on his/her strengths in understanding it, leaving you only the task of filling in the holes as needed. Each person needs to learn different things from the class; not all the same thing.

Another reason that the opposite thing does not work is that everyone learns differently. If you make the assumption that people learn by seeing or hearing something and then immediately "knowing" it you are treating the brain like a disk drive. I doesn't work that way. The brain works by reinforcement. So, if your teaching style is to teach everything only once and completely, then you guarantee that you will reach only a tiny fraction of your students, and many of those don't need the instruction anyway.

I have not seen research, but this is my practice.

• I teach print before, teaching how to implement print.
• I teach use of classes, before implementation of classes.
• I teach import (in python), before teaching how to make modules. I just tell them “import turtle tells python how to be a turtle.”

I see it like, learning to read, before learning to write.