This weeks learning journal is more programming based then usual. I traditionally try to keep these posts appropriate to non-CS students, so I refrained from using any code. I tried to keep the technical wording to a minimal because I think the lesson I learned this week can still apply to students taking business administration as well. Always, always double check work before submitting it!
At the beginning of week 3, I caught my first major mistake at UoPeople. I submitted a programming assignment that had a fairly critical bug in it during week 2, and didn’t catch it until the first day of week 3. Of course it was too late to correct the mistake by then.
The way I caught the bug was by reading the answer to the assignment before I sat down to do the assessments. My program was supposed to roll a pair of dice until they hit Snake Eyes (two 1’s), and then repeat the process a thousand times, printing out the average number of rolls to get Snake Eyes.
I noticed that the answer code’s output said the average was around 30 rolls, and mine was much lower. I knew right away I had made a mistake but didn’t know for sure where it was. My first thought was that the dice must not actually be Snake Eyes, when the program thinks they are.
So my first reaction was to use a line of code to check the value of my dice at the time the program thinks it rolled Snake Eyes. It turned out I was right; the program thought Snake Eyes had been rolled, but only when one of the dice was a 1, and not both. So of course this must mean something is wrong with the logic that controls my loop.
It was a sloppy oversight, but the bug was that my condition for re-rolling the dice was that both dice could not be equal to 1. The condition should be that one, or the other dice can’t be equal to one. The former logic means that the dice will stop being rolled if only one dice is equal to 1, but of course we want both, which is why the latter is correct.
Once I corrected the problem, I thought it would be interesting to share the bug on the forum, and see if anyone else had trouble seeing it. Only one student bit unfortunately so I didn’t get much feedback.
I didn’t feel bad about the mistake, but I did feel like I was careless to have submitted work like that. In my confidence I wrote the code for both the assignment and the challenge in one go. I didn’t bother checking the value of the dice because in my head at the time, the code made perfect sense. On the surface it seemed to work correctly, and I actually suspect that a student or two might miss the error in my program when assessing it.
I felt careless because it’s a mistake I know how to prevent. I should have been printing the value of the dice to the console from the beginning to ensure my code was working as expected. Moving forward, I’ll have to make sure to force myself to be more attentive to small details like this.
From the experience in my learning journal this week, you can see how easy it is to make small, but critical errors. The prevention was easy, because I already knew the steps that I should have taken to ensure I had no errors in my assignment. However, probably due to too much confidence, I skipped important steps that I would normally do when programming.
Confidence is important, but it can also be a pitfall. For me, I was too caught up in the bigger picture of my assignment, that I had missed a small, but detrimental detail. The worst fact, is that it would have only taken a matter of seconds to prevent my mistake. This is why we should always be diligent in our work (performing all of the appropriate steps, and double checking) no matter how confident we become.
Cheers,
Dan