<h3>Boldly Go...</h3>

<p>First, I'll just say yes, it is a <strong>good</strong> idea to introduce things (let students see them) before they have to deal with them in detail. There is actually a <a href="https://rads.stackoverflow.com/amzn/click/1479171824" rel="nofollow noreferrer">Pedagogical Pattern</a>, <em>See Before Hear</em>, 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 <em>Spiral</em> 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. </p>

<h3>Research</h3>

<p>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 <em>even suspect</em> 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. </p>

<p>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. </p>

<h3>An alternative: Patterns</h3>

<p>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 <em>what should be done</em> but the <em>why this is the right thing to do</em> (resolution of forces). </p>

<p>Another pedagogical pattern that pushes your syntax idea to the max is the <em>Fixer Upper</em> 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. </p>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2017-09-11T11:50:49.833Z
2017-09-11T11:50:49.833Z
Buffy
<p>I have not seen research, but this is my practice.</p>

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

<p>I see it like, <em>learning to read, before learning to write</em>.</p>

CC BY-SA 3.0
2017-09-11T07:44:20.180Z
2017-09-11T07:44:20.180Z
ctrl-alt-delor
<p>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.</p>

<p>As an example will students ultimately learn <code>import</code>/<code>export</code> better if they're given code that has <code>import</code> 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?</p>

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

<ul>
<li>Are there certain ways to classify students where some group will benefit or detriment from being introduced to syntax early?</li>
<li>Do certain age groups handle early introduction of syntax better?</li>
<li>Is there some minimal skill set after which early introduction of syntax will begin to add benefits?</li>
</ul>

CC BY-SA 3.0
2017-09-11T07:46:25.030Z
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
CC BY-SA 3.0
2017-09-11T18:09:56.007Z
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
<best-practice><syntax>
Is it a good idea to have students see syntax much earlier than they write it themselves?
# Is it a good idea to have students see syntax much earlier than they write it themselves?

(Asked by: username_0 on 2017-09-11)

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?

**Tags:** best-practice, syntax

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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.  

---

## 2 answers

### Answer by username_3 on 2017-09-11. Score: 4

### 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](https://rads.stackoverflow.com/amzn/click/1479171824), *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.


---

### Answer by username_1 on 2017-09-11. Score: 3

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*.


---

