I'll push back against this slightly: learning what good code is requires debugging bad code, whether by way of a symbolic debugger or judicious use of printf() or breaking an algorithm down into its steps so that you can figure out its asymptotic behaviors.

I harped on checking someone's ability to debug code back when I interviewed candidates, in part because I found that people who could debug effectively could also sniff out bad code. It was something of a bonus that I also happened to select for candidates who could explain their debugging strategies and what that meant for the software they were working on.

▲

bluefirebrand 2 hours ago | parent [-]

I don't really draw much distinction between debugging and writing code. You really can't do one very effectively without the other imo

But you're right. The better indication of capability is debugging skill than writing skill.

	▲	nrr an hour ago \| parent [-]
		It's kind of the same distinction between backups and restores, wherein the restores are what's important, but they're impossible without the backups to restore from. One of the first things I do in any new-to-me project is set breakpoints in the integration tests and start stepping through the code so that I can establish some mental context. However, if there aren't integration tests, I begin writing them so that I can walk around with my debugger.