<p>There is another sort of rabbit hole, one that your best students can fall in to. I once had a situation in which students were programming with a certain library that provided a simulation - a virtual world. They had certain exercises designed to teach specific thought processes; think recursion, or design patterns, but it could be lots of things. Some of the best students figured out that they could get the right answer, not by programming within the simulation, but by re-programming the library itself to make the exercise trivial. They got the right answer by rewiring the foundation. But the intent was to help them rewire their brains. </p>

<p>It is hard to condemn such students, of course. They were very clever. They learned <em>something</em>. But the worry is that what they learned helped them avoid learning something else that may be more important in the long run. </p>

<p>In this case the solution was that I tightened up the simulator (which made it better/more secure), but I also needed to assure that they did in fact learn the lesson of the day. It isn't that they did anything wrong, or learned the wrong thing, just that they may have failed to learn something important. </p>

<p>The same situation would apply if a student, asked to write a program with some hard bits, modified the compiler to make those bits easy. Good that they teach themselves something about compilers, but bad if the hard bits held some important insights that programming around them left them in the dark about. </p>

<p>I sometimes have to tell a few (usually good) students that the purpose of programming exercises isn't to produce a program, but to produce learning. Usually, if I needed the program I could write a pretty good one myself. </p>

CC BY-SA 3.0
2017-07-02T13:56:16.443Z
Not only could you write a pretty good one yourself, but you'd also not have to grade it. The purpose of the teacher in the classroom is to teach. If they can accept that then their on the road to learning.
Gypsy Spellweaver
CC BY-SA 3.0
2017-07-02T15:31:43.627Z
*The purpose of programming exercises isn't to produce a program, but to produce learning.*  I need to tell my students this more often.
Norman Ramsey
CC BY-SA 3.0
2017-07-02T13:37:01.930Z
2017-07-02T13:43:40.623Z
2017-07-02T13:43:40.623Z
Buffy
<p>Wish I had a good answer, but I can sympathize with your Scratch example. </p>

<p>What I started doing was just giving up on the first day we did Scratch. I would show them the drawing tools before we did any coding. Spent about 5 minutes showing how to make sprites and backgrounds and then gave them the rest of the period to play, with the understanding that was the only day that they had to just play around and doodle. Day two, we start coding. </p>

<p>Worked fairly well. It was at least better after I started doing this than before. I think the novelty of it wore off when they were allowed to goof off for a day. </p>

<p>Haven't taught Scratch in a few years, but I noticed the same thing happening with Jeroo. Kids love painting the island with flowers and water. The last lab in the set is one where they get to build their own lab, and make their own island. I think having that to look forward to helps. </p>

CC BY-SA 3.0
2017-07-02T00:36:18.267Z
2017-07-02T00:45:04.887Z
2017-07-02T00:45:04.887Z
Ryan Nutt
<p>Well, in terms of your second example - inefficient code, because it's "easier" - try doing a code golf style game. Whoever gets the shortest code on an assignment, project, lab, or whatever goes on a leaderboard, for extra points. This may help improve coding knowledge.</p>

<p>As for the other problem - well, if it's on the student's time they are doing this, then it's theirs to spend. Perhaps show them how they can iterate - starting by creating a quick stick figure for a character and then improving it once the key stuff - the code - is done. Make sure you also have clear expectations - it needs to be neat, but not a work of art.</p>

<p>Also, if they are "going down a rabbit hole" by adding extra features to a project in the code, I would encourage that, again perhaps on a leaderboard of some sort (for "most well-done" project, or something like that).</p>

<p>So, in summary - it depends on the rabbit hole. Make sure there are clear expectations and challenge them to push themselves with leaderboards/competition/extra credit.</p>

<p>Edit: As Buffy points out in the comments, there is too much of a good thing. In industry, there is no need for "extra features" - you do what the client wants, no more, no less. And code golfing taken too far can lead to terrible pieces of code - of course as the teacher, one would have to accept only "golfed" solutions with good variable names, etc.</p>

CC BY-SA 3.0
2017-07-01T23:03:41.363Z
Be aware that adding features not asked for can get you fired in the real world. If the assignment is to "be creative" then it isn't an issue, but note that extra code is code that (a) needs to be maintained in perpetuity (almost) and (b) may introduce bugs into the features that are required. So, if you are asked to do X, then do X as well as you can and seek guidance before you decide to do Y also.
Buffy
CC BY-SA 3.0
2017-07-01T23:06:15.270Z
@Buffy, sure. I guess I meant it as in the classroom, when you are still learning, putting extra effort in is by no means a bad thing.
auden
CC BY-SA 3.0
2017-07-01T23:09:21.193Z
Also, be careful what you encourage in your golf game. Shortest code isn't necessarily the best. Most readable code, best variable and method names, etc would be encouraged pretty much universally, but shortness at the expense of maintainability is a problem, not a feature. "Most comments" is bad, code that doesn't need any comments is good. Most tests could be good or bad, depending, but just the count is less valuable than the coverage. Best coverage in tests - good.
Buffy
CC BY-SA 3.0
2017-07-01T23:12:56.877Z
If I generalize your answer a bit it is definitely a positive thing. But the teacher needs to be clear on what is valued and what is problematic. So your "golf game" wins with the right rules. Extra effort good. Maintain balance, better. Rabbit holes, bad. When you are doing programming for another (a teacher or boss) you work to their standard. When you write for  yourself, be as creative as balance and constraint will allow.
Buffy
CC BY-SA 3.0
2017-07-01T23:16:46.997Z
@Buffy, I assume that the teacher has enough discretion to properly carry out these challenges/leaderboards. Of course there is too much of a good thing.
auden
CC BY-SA 3.0
2017-07-01T23:19:34.190Z
Oh, if every student were like you, teaching would be so good. But so hard. We (teachers) would never get any sleep just keeping up.
Buffy
CC BY-SA 3.0
2017-07-01T23:27:05.170Z
@Buffy, thank you, but not quite true, I think =) There's tons of things I still have to learn. I hope my edit properly conveys what you were trying to say.
auden
CC BY-SA 3.0
2017-07-01T23:41:26.243Z
Lots of things we _all_ need to learn, but the discussion is getting too long. Keep on keepin' on.
Buffy
CC BY-SA 3.0
2017-07-01T22:58:38.410Z
2017-07-01T23:25:32.027Z
2017-07-01T23:25:32.027Z
auden
<p>Without guidance, students will sometimes spend a large amount of time on a computer science assignment in a portion of the assignment that does not engage CS skills and knowledge. An example is a student who spends a lot of time creating costumes using the drawing tools in Scratch. The problem can include code, however, such as a student who has established expertise in simple conditionals but continues to build out an adventure game using repeated application of the same pattern without gaining any conceptual ground.</p>

<p>What practices do teachers use to successfully retain the student engagement driving a student to exert ongoing effort but redirect their effort to realize greater gains in learning skills and knowledge intended by the teacher?</p>

CC BY-SA 3.0
2017-07-01T22:56:37.087Z
Usually my lab specifications put plenty of cs "meat" into the core assignment itself.  Is this for free-choice or unguided projects?
Ben I.
CC BY-SA 3.0
2017-07-01T23:03:33.043Z
I've observed the problem in projects and problems that have small and large opportunity for student-direction. Even when the student deliverable is well-constrained, I've seen high- and low-achieving students express anxiety around leaving a sprite costume unfinished or less than perfect.
Bennett Brown
<classroom-management>
How to communicate expectations around "rabbit holes"?
# How to communicate expectations around "rabbit holes"?

(Asked by: username_0 on 2017-07-01)

Without guidance, students will sometimes spend a large amount of time on a computer science assignment in a portion of the assignment that does not engage CS skills and knowledge. An example is a student who spends a lot of time creating costumes using the drawing tools in Scratch. The problem can include code, however, such as a student who has established expertise in simple conditionals but continues to build out an adventure game using repeated application of the same pattern without gaining any conceptual ground.

What practices do teachers use to successfully retain the student engagement driving a student to exert ongoing effort but redirect their effort to realize greater gains in learning skills and knowledge intended by the teacher?

**Tags:** classroom-management

> **Comments:**
> **username_1**: Usually my lab specifications put plenty of cs "meat" into the core assignment itself.  Is this for free-choice or unguided projects?  
> **username_0**: I've observed the problem in projects and problems that have small and large opportunity for student-direction. Even when the student deliverable is well-constrained, I've seen high- and low-achieving students express anxiety around leaving a sprite costume unfinished or less than perfect.  

---

## 3 answers

### Answer by username_2 on 2017-07-02. Score: 5

There is another sort of rabbit hole, one that your best students can fall in to. I once had a situation in which students were programming with a certain library that provided a simulation - a virtual world. They had certain exercises designed to teach specific thought processes; think recursion, or design patterns, but it could be lots of things. Some of the best students figured out that they could get the right answer, not by programming within the simulation, but by re-programming the library itself to make the exercise trivial. They got the right answer by rewiring the foundation. But the intent was to help them rewire their brains.

It is hard to condemn such students, of course. They were very clever. They learned *something*. But the worry is that what they learned helped them avoid learning something else that may be more important in the long run.

In this case the solution was that I tightened up the simulator (which made it better/more secure), but I also needed to assure that they did in fact learn the lesson of the day. It isn't that they did anything wrong, or learned the wrong thing, just that they may have failed to learn something important.

The same situation would apply if a student, asked to write a program with some hard bits, modified the compiler to make those bits easy. Good that they teach themselves something about compilers, but bad if the hard bits held some important insights that programming around them left them in the dark about.

I sometimes have to tell a few (usually good) students that the purpose of programming exercises isn't to produce a program, but to produce learning. Usually, if I needed the program I could write a pretty good one myself.

> **Comments:**
> **username_3**: Not only could you write a pretty good one yourself, but you'd also not have to grade it. The purpose of the teacher in the classroom is to teach. If they can accept that then their on the road to learning.  
> **username_4**: *The purpose of programming exercises isn't to produce a program, but to produce learning.*  I need to tell my students this more often.  

---

### Answer by username_5 on 2017-07-02. Score: 4

Wish I had a good answer, but I can sympathize with your Scratch example.

What I started doing was just giving up on the first day we did Scratch. I would show them the drawing tools before we did any coding. Spent about 5 minutes showing how to make sprites and backgrounds and then gave them the rest of the period to play, with the understanding that was the only day that they had to just play around and doodle. Day two, we start coding.

Worked fairly well. It was at least better after I started doing this than before. I think the novelty of it wore off when they were allowed to goof off for a day.

Haven't taught Scratch in a few years, but I noticed the same thing happening with Jeroo. Kids love painting the island with flowers and water. The last lab in the set is one where they get to build their own lab, and make their own island. I think having that to look forward to helps.


---

### Answer by username_6 on 2017-07-01. Score: 1

Well, in terms of your second example - inefficient code, because it's "easier" - try doing a code golf style game. Whoever gets the shortest code on an assignment, project, lab, or whatever goes on a leaderboard, for extra points. This may help improve coding knowledge.

As for the other problem - well, if it's on the student's time they are doing this, then it's theirs to spend. Perhaps show them how they can iterate - starting by creating a quick stick figure for a character and then improving it once the key stuff - the code - is done. Make sure you also have clear expectations - it needs to be neat, but not a work of art.

Also, if they are "going down a rabbit hole" by adding extra features to a project in the code, I would encourage that, again perhaps on a leaderboard of some sort (for "most well-done" project, or something like that).

So, in summary - it depends on the rabbit hole. Make sure there are clear expectations and challenge them to push themselves with leaderboards/competition/extra credit.

Edit: As username_2 points out in the comments, there is too much of a good thing. In industry, there is no need for "extra features" - you do what the client wants, no more, no less. And code golfing taken too far can lead to terrible pieces of code - of course as the teacher, one would have to accept only "golfed" solutions with good variable names, etc.

> **Comments:**
> **username_2**: Be aware that adding features not asked for can get you fired in the real world. If the assignment is to "be creative" then it isn't an issue, but note that extra code is code that (a) needs to be maintained in perpetuity (almost) and (b) may introduce bugs into the features that are required. So, if you are asked to do X, then do X as well as you can and seek guidance before you decide to do Y also.  
> **username_6**: @username_2, sure. I guess I meant it as in the classroom, when you are still learning, putting extra effort in is by no means a bad thing.  
> **username_2**: Also, be careful what you encourage in your golf game. Shortest code isn't necessarily the best. Most readable code, best variable and method names, etc would be encouraged pretty much universally, but shortness at the expense of maintainability is a problem, not a feature. "Most comments" is bad, code that doesn't need any comments is good. Most tests could be good or bad, depending, but just the count is less valuable than the coverage. Best coverage in tests - good.  
> **username_2**: If I generalize your answer a bit it is definitely a positive thing. But the teacher needs to be clear on what is valued and what is problematic. So your "golf game" wins with the right rules. Extra effort good. Maintain balance, better. Rabbit holes, bad. When you are doing programming for another (a teacher or boss) you work to their standard. When you write for  yourself, be as creative as balance and constraint will allow.  
> **username_6**: @username_2, I assume that the teacher has enough discretion to properly carry out these challenges/leaderboards. Of course there is too much of a good thing.  
> **username_2**: Oh, if every student were like you, teaching would be so good. But so hard. We (teachers) would never get any sleep just keeping up.  
> **username_6**: @username_2, thank you, but not quite true, I think =) There's tons of things I still have to learn. I hope my edit properly conveys what you were trying to say.  
> **username_2**: Lots of things we _all_ need to learn, but the discussion is getting too long. Keep on keepin' on.  

---

