1. Got blocked on a simple problem
A recent problem that I came across was during exercise 5.4 in Sprint 5. It was a simple game that contained 9 dots, which we can either change it’s colour to blue or green with a click or double click, or make the dot invisible by right clicking. The problem I had with the game was writing a code that would count the number of dots that have changed to blue/green/invisible. At first the instructions seemed quite straight forward, create a for loop that would count how many dots have been changed and have a function count the changed dots and update the count. Seems pretty simple…until I wrote the code and then the dots stopped changing and the counter didn’t even work. I tried many problem solving techniques including: pseudocode, asking my cohort and teacher for help, reviewing solutions to the problems and working backwards to find what step I am missing. Throughout this process I was very frustrated because I couldn’t seem to understand where I was going wrong in the code even after using many methods of trouble shooting. Eventually, with help from my cohort suggesting a closer look at the var code, I managed to figure out what I was missing in the code. I learnt that there is always help when needed and solving a problem can be a long frustrating process but that next time I will be aware of that mistake.
2. Solved a problem in an elegant way
I don’t think I have solved any problems in an elegant way yet. It’s mostly a lot of frustration about knowing what I want the code to do and not knowing how to write the code to make that happen. Then just lots of stumbling and trial and error until I get it to work.
Pseudocode: I’m getting more confident with pseudocoding, it helps me get a clearer idea of what I'm trying to get my code to do. It's just frustrating because then I hit the roadblock of "okay, this is what I what the code to do, so how do I do that?".
Trying something: I feel like this is the whole learning process is to try something, which I'm getting pretty good at. Not sure if the something will always work, but so far it's been good.
Rubber ducky method: I haven't really tried this method yet.
Reading error messages: I'm getting more used to understanding what an error message is trying to get me to fix or review. During free code camp in sprint 4, reading the error messages really helped me to isolate what code to focus on that I was writing incorrectly.
Console.logging: I have not used this method.
Googling: It’s a hit and miss when googling for help. I’m still not able to explain what the problem is so when I google, the answers aren’t specific to my question.
Asking your peers for help: I’m fairly confident with asking my peers when I get stuck, it helps that we are working on the same material so we already know the context of what we want the code to achieve.
Asking coaches for help: I am ok with asking the teachers for help, but usually after the other methods don’t work. It’s just nice to get into the habit of trouble shooting using different methods.
Improving your process with reflection: I feel like I am not consciously reflecting but I do become more aware of the syntax or code error and become less likely to make the same error again because I am more aware about it.
.map() A function is applied to each element in the array to return a new array where the elements have been changed. Think of it as taking a set of pictures (array) and applying an Instagram filter (function), the new array returned will be the same set of photos except they now have filters on them.
.filter() This function will only return items from the array that match your filter criteria. For example, if you are online shopping and you have an array of all the clothing items, and you “filter” jackets, if there are jackets in the clothing array (jackets == true), then the result will return a new array of only jackets from the entire array of clothing.
.reduce() Returns the array to a single value.