4 ms·
I just pair programmed with a student to help them get their code working. The first thing I did was delete unused variables and non-critical code that was dist
by hoosieree 4y ago
I just pair programmed with a student to help them get their code working. The first thing I did was delete unused variables and non-critical code that was distracting from the core algorithm.
After removing most of their print statements, it was obvious what the program was doing at run-time.
It's much harder to delete your own code than someone else's, especially when you're unsure of what's important.
- kqr 4y agoDeleting stuff, compiling often, and proper indentation -- things beginners don't think they should waste time on, but which actually would solve most of their problems.
- ColonelPhantom 4y agoEspecially as compiling often and proper indentation are often taken care of by running a linter and an autoformatter. I'll add "learning how to use a debugger", though.
- kqr 4y agoIn my interactions with beginners, adding more tools has never helped them learn faster. That goes for linters, autoformatters, debuggers, and version control. Manual formatting and printf debugging goes a long way, and takes only foundational understanding of the problem, not the manual for another tool. (Don't get me wrong: I love those tools. For a person who already knows them, they're a productivity multiplier. But a complete beginner usually doesn't have that knowledge.)
- hoosieree 4y agoIt's good to have a teacher who can recognize the moment when print-debugging is no longer sufficient and a real debugger will solve the problem immediately. Introducing debuggers too early leads to lots of "why do we need this? I can just print..." It's a catch-22 though, because ideally you'd learn the debugger in an intro course, but intro course problems can usually be debugged with simple print statements.