When finishing off coding for my audio player task, I kept finding myself getting carried away with extra features I wanted to add, and I found it difficult to stop myself and prioritise other work. This taught me that I should do what I’m least excited about first and then get to the exciting stuff afterwards, so I don’t fall behind with other work like I did with exercise one of the JavaScript task. Hopefully, I can change this habit, but I also hope I will get time to play around with these extra features in the future. I also found working in person in the support sessions makes it much easier to get coding work done than at home, but not always written/research work.

We revisited the Fizz Buzz challenge that I completed last week and went through the different solutions people came up with. The final version we ended on, used a for loop instead of a while loop, like I had used. We did this because you can handle initialisation, condition, and incrementation all in the first line, which is more efficient than a while loop. However, I prefer the readability of the while loop. It also logged every value in each iteration instead of logging a list of all the values at the end. Although the group’s final solution was more efficient and probably ‘better’, I was still happy with the version I had created the previous week.

In this week’s lecture, we were introduced to the rubber duck theory, an idea that when a programmer is debugging code, they should explain each line of their code to a rubber duck. I’ve practiced this idea before, but with friends who don’t have any coding knowledge instead of a rubber duck, and it’s been very useful. I also found this funny as I have a collection of rubber ducks that now have a new use.