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?

  • $\begingroup$ Usually my lab specifications put plenty of cs "meat" into the core assignment itself. Is this for free-choice or unguided projects? $\endgroup$
    – Ben I.
    Jul 1, 2017 at 22:56
  • $\begingroup$ 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. $\endgroup$ Jul 1, 2017 at 23:03
  • $\begingroup$ I find that when students get good at some aspect, they spend a lot of time at it because it is known. Also, when there are new areas they don't know, they elaborate on aspects that they do know. $\endgroup$
    – user737
    Jul 3, 2017 at 1:09

3 Answers 3


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.

  • $\begingroup$ 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. $\endgroup$ Jul 2, 2017 at 13:56
  • 1
    $\begingroup$ The purpose of programming exercises isn't to produce a program, but to produce learning. I need to tell my students this more often. $\endgroup$ Jul 2, 2017 at 15:31

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.


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

  • 3
    $\begingroup$ 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. $\endgroup$
    – Buffy
    Jul 1, 2017 at 23:03
  • $\begingroup$ @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. $\endgroup$
    – auden
    Jul 1, 2017 at 23:06
  • 1
    $\begingroup$ 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. $\endgroup$
    – Buffy
    Jul 1, 2017 at 23:09
  • $\begingroup$ 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. $\endgroup$
    – Buffy
    Jul 1, 2017 at 23:12
  • $\begingroup$ @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. $\endgroup$
    – auden
    Jul 1, 2017 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.