A time I was blocked on a simple problem:
I was having an issue when a function that I had written which I was pretty certain was correct wasn’t working. There was something which was making a part of the function be reset. I first questioned the function I had written and did some research on how passing an object into the function as an argument worked. I was questioning myself whether I had written and I couldn’t find any information where it described what I was experiencing. I used some problem-solving techniques such a the rubber ducky method ( nothing was standing out as broken ). I felt frustrated when trying to figure this out and took a bit of a break to reset and then came back to it. In the end I checked the test that was being run on this function I had written and I saw that the object was being ‘reset’ at the bottom. I had assumed this wouldn’t have been done as it wasn’t mentioned. From this I learnt that when something is returning empty I need to go through and make sure its not being mentioned anywhere else on the document.
A time I elegantly solved a problem:
During the Kata problems I was able to complete the super fizz buzz function somewhat elegantly. I had to create a function which took a list of numbers, and when the number is divisible by 3 it returns ‘fizz’, when its divisible by 5 it returns ‘buzz’ and when its divisible by both 3 and 5 it returns “FizzBuzz”. To complete this challenge I used google to find the division remainder operator as I knew that it existed. I also used some console logging during the process to double check what I was working with. I felt good during this process as it was all coming together and I found the problem to be comfortable. Through this function I learnt about using the division remainder operator (%) which will be helpful in the future and also triggered me to look into some of the other operators.
Reflect on how confident you feel using each of these problem-solving techniques/processes:
Pseudocode: I’ve tended not to use this so much within the file but I have been verbalising what I need to do and what I want the function to do. I will make more of an effort to slow down and implement pseudocode into my code from now though.
Tying Something: This is where I will normally start when problem solving. Getting something down and working off of it to get the solution is effective for me.
Rubber Ducky: I have used this method internally, but I’ll be on the lookout to get a little figure or something that I can use the rubber ducky method on.
Reading Error Messages: This is a big one for me when problem solving and probably the most helpful when working with JavaScript. I’m constantly looking for error messages and what information they are giving.
Console Logging: Second to reading error messages, console logging is my second most popular problem solving method. I use this to see what’s being done in certain parts of functions, whats being returned and the type of data which is being returned.
Googling: Once again, without google I think developing JavaScript would be very hard and not very enjoyable - im constantly looking in to different object methods and getting resources on using the correct syntax.
Asking Peers for Help: I will typically use this as my last port of call. If I’m completely stuck and cannot figure something out then I will pass it on to my peers for help. This is also helpful for other students that might be facing the same issues. I will probably rely on this more once we are on campus and it is easier to ask for help.
Asking Coaches for Help: For me this would go hand-in-hand with asking my peers for help. If my peers can’t help me, or if I need explanation on something then I will pass it on to the tutors for help.
Reflection: I tend to reflect when I step away from the keyboard and think about the problem at hand. Through the last Kata activities I did however write some notes and reflect on the problems, but only once they were completed.