Debugging is such an important skill and it is something that pupils rarely spend enough time on. I am sure I am not alone in the experience of, "Miss, why isn't it working?" They really ought to know better, my response is always, "I don't know, why isn't it working?" followed by other, more helpful questions!
I do think a great deal of this reluctance is just laziness: they would much rather I told them so they could move on.
I use IDLE for Python and only use a fully-featured IDE from Year 11 onwards. Although Python and IDLE have their idiosyncrasies, I like their pared-back nature. This avoids the distraction of too many menus and buttons and too much help from IDE tools.
I think it is a truism that most non-trivial programming errors are caused by false assumptions so the first thing I demonstrate and suggest is, look for where you have made assumptions and output those values. Have a look at this code:
Look at what is output: everything up to and including line 11 works fine. The error is somewhere after line 11.
You are expecting to go into that second loop.
What controls whether you do or not? The values of count and number.
Your assumption is that count is less than or equal to number so print count out and you will find that is not the case.
If you can't see what is wrong with your program, explain why it is correct to someone else. Nine times out of ten, you won't finish explaining because you will see your error!
I do this a lot with both algorithms and programs and have some specific exercises for pupils to complete as well. I think it is important to step away from the computer at times.
Work through your code, line by line and write down all the variables and output.
Just in case you don't know it, here is a summary of the division method of converting from decimal to binary:
Repeatedly divide the decimal value by 2 until you end up with 0.
Every time you divide, keep the remainders and then copy them out backwards (hence the binary = str(remainder) + binary line.
You could use the exam board trace tables or just something like this on the right:
Every time a variable value changes, I cross out the previous value
You will notice that the answer comes out as 4 in binary, not 8.
This isn't a trivial piece of code and isn't for beginners
Having found the error, you need to find the cause. Look at where whole and remainder are being calculated and notice that you divide whole and then find the remainder of it divided again... swap those two lines...
If you write a solution to a complex problem in one go without incremental development and testing, you are likely to come unstuck. The meaning of complex depends on your experience, of course.
Decompose the problem and write a solution to simplest part first, test it and then move on.
Example 1: Write a program that asks the user to enter a two-digit number. Add all the digits together and ask the user if that number is divisible by three. If it is, the original number is divisible by three.
1. Ask the user to enter a two-digit number and output the individual digits
2. Output their total
3. Get the user input and output whether the number is divisible by three or not
Example 2: Find the average of five input numbers
1. Ask the user to enter a number and convert it to an integer
2. Write a loop that repeats five times
3. Put the input statement inside the loop
4. Add each number to a running total and output this after the loop
5. Calculate the average and output it.
This might seem like overkill but you can tailor it to your needs.
If you have been staring at broken code for ages, take a break. Come back to it with fresh eyes.
It is notoriously hard to write debugging exercises but they are really important. I would suggest you look at the common mistakes your pupils are making and turn them into exercises. For example:
In this example:
the program outputs grade which is not defined, it should output result
there is only any output if the result is a fail. This is because the print statement is in the else clause... remove the indent.
50 is recorded as a fail, it should be a pass...
You might want to split those up into separate examples, depending on your cohort.