Continuing from Dan’s crazy ideas #1 and Dan’s crazy ideas #2…
Okay. This idea is CRAZY! As in, box? What box? That kind of crazy. You ready for it? Here goes:
Create a category of puzzle where the goal is to debug and fix someone else’s broken code.
Umm… Hello? This is Codin-GAME, as in fun! What’s so fun about debugging someone else’s mess?
Yeah, I know. Just give me a minute to explain. I think the idea has some merit.
Concept
Unless you live in a bubble, or you plan to become a full-time code competition participant, you will need to work with code written by other people… a lot! Puzzles geared around detangling unfamiliar syntax usage, paradigms, and algorithms can provide practice in this invaluable skill.
In addition, I can attest that I frequently pick up new techniques from looking at code written by others.
Proposal
To force the thou shalt fix the code, and avoid the I’m just going to rewrite this mess, I propose a new form of IDE / puzzle in which the majority of the code is read-only, and only a small subset of the program (1 - 10 lines?) is editable. The user is free to add / modify code in that window, and possibly another editable section elsewhere to enable addition of functions and classes.
This format could have many uses. Here are just a few:
- Teaching: Illustrate a particular algorithm or technique.
- Entertainment: Create some particularly clever, or stupid, or obscure, etc. code.
- Competition: I think this would work particularly well in Clash of Code.
Clash of Code
I’d like to elaborate on this one a bit. One of the common problems with CoC is that the pool of puzzles is too small, and some of the better competitors have them mostly memorized (or worse, somehow automated).
If this form of puzzle were to be implemented as a CoC, then it would provide literally hundreds of puzzles. Pretty much every non-functional puzzle submission could be a candidate for a future debug puzzle. You could even automate the process by looking for sequential submissions where only a small change in the code causes a failing puzzle to pass.
A major drawback to this idea is that all competitors would need to compete in the same language, so that the competition is fair. They would probably need to agree on a language ahead of time. One proposal for how to do this is for each user to select a list of languages in which they are willing to compete, and then the server could select a puzzle from the intersection of competitors’ language selections.
Sooo… How crazy is it? Let me know what you think.
- danBhentschel