We Need to Talk About Markdown

The Markdown Exercise is intended as a way to practice refactoring existing code that already passes tests, but could be more idiomatic or succinct, or generally improved.

However, a large number of students (936 on the Python track & counting in the representer) blow right past those instructions and submit the unaltered code.

One way to address this is to write a response (from the representer or analyzer) that says something to the effect of

Markdown is intended as a refactoring exercise, but you have not substantially changed the starter code. Consider what changes you could make to clarify the code or make it more idiomatic, while still passing the tests.

Another way might be to write a test that fails and gives the same feedback - which would be more prominent, because the student would have to ‘pass’ that test before they could mark their solution complete.

Of course, the test method would be prone to ‘gaming’ - where students focused on faking out the diff. Nevertheless, I do think it is problematic that so many students miss the point (and opportunity) to practice a refactor.

Thoughts? Suggestions? Rants of your own?

I prefer this approach as it ensures someone using the CLI will understand what’s going on.

I’m in no way concerned about people gaming the system as they’re only cheating themselves. So I’d focus on a solution that makes genuine students understand what’s wrong.

Maybe the exercise needs refactoring “hints” as part of the description too?


We could also have a tag for the exercise as a refactoring exercise which adds some addition info to the README automatically.

Potentially we could also add tooling to ensure that the submitted file isn’t the same as the “stub” too, but that’d be a bigger project that wouldn’t get done soon.

Yes. I like that! Perhaps we do part in the README (or addendum), and part in the Hints? It could really benefit from a video approach - or even a cross-track intro video that talks about the practice of refactoring…

It would also be great to have a tag/category of exercises that are refactors. I mean - we don’t want to go nuts, but having a few more exercises around refactoring could be really interesting.

I’m trying to think of/find an approach that would let me diff an AST of the stub vs the students solution within pytest, and then ‘fail’ the ‘test’ if there is less than… 5% diff or maybe less than that? It’s still fuzzy in my head. I haven’t found anything solid yet – but that’s where my brain is headed. We’ll see. I might be forced into a straight diff. :stuck_out_tongue:

1 Like

that’s me, honestly I felt intimidated and neglected the exercise.
Didn’t feel the challenge just frustration because I didn’t take time to actually understand it better. Maybe this one could benefit from some hints

1 Like

Some hints would be nice. There’s also always the option of requesting mentoring!

As a rookie student myself, I felt that this exercise opens too early, IMPORTANTat least on the JavaScript track, and that can be confusing, specially for people who are fresh into coding and haven’t come into contact with refactoringas a concept. That allied with the fact it presents you with template strings, makes it seem even more complicated then it is, and I think it might be a factor in how people (maybe) are treating it. The fact that you can you can just submit it as it is was, ironically, what shed some light for me personally, as I had a chance to look at solutions that were completely different.
Considering the color theme of the code submissions, I’d sudgest having a yellow-coded for unnaltered code subs, in general (tho I imagine thats a hella big addition). For this exercise, being able to see some different solutions before needing to pass the test is also heaven-sent. Being able to do that introduced me to regular expressions, so maybe adding that concept to the excercises’ intro might be nice.

P.S.: Despite the python tag, I felt like it’s be more appropriated to give my feedback here than starting a new post, but I could be corrected.