Troy Lamerton

Problem Solving

16 April 2016

I encountered a simple problem this week while programming the basic movement of the racer game. The move button was definately clicked, the move function was called, but there was an error and the car wouldn't move.

I had implememnted many changes since the last test so I couldn't be sure where the error was coming from. The first thing I did was revert a lot of these changes to the last working version. One by one I reintroduced the changes until I got the error. Aha! It was to do with accessing the position of a car. After slowly reading through all the related code twice, I noticed a subtle typo 'positon'...

Going through the problem solving process I felt determined to find a solution. I think I was too confident in parts of my code that when checking them I read over the 'positon' typo without seeing it. I learnt that sometimes it's best to check the basics before assuming the problem is something complex.

Another problem I encountered this week was in trying to reduce the lines of code for the two player racer game. It looked liked I would need to write code for player one and player two seperately, referencing the correct players variables. I realised I could call functions with a player number and then use this player number to access an array.

Using Google I refreshed how to make an array of objects. Now the functions were able to take the player number and use it to move the player etc. From this I reinforced the idea that there is almost always a way to avoid repeating oneself in programming.

There are many problem solving techniques and below I rate my confidence with each of them.
Pseudocode: I made use of pseudocoding to plan the logical steps of a few functions this week.
Trying something: When a project is quite simple I don't mind trying something out to see if it works. Larger projects I am more cautious and use other methods.
Rubber ducky method: I haven't tried pretending to talk to a rubber ducky yet.
Reading error messages: This is extremely useful for me. I often understand what the error means and I use this to know what the problem is.
Console.logging: Always when I can't find the error I place a lot of console.logging, but usually it just rules out a few things without pointing out the cause.
Googling: In this learning phase, a lot of our problems have been solved before. I've found Googling to be useful and am confident in how to ask the right questions.
Asking your peers for help: I solve most issues with the above methods but will ask my peers before asking coaches.
Asking coaches for help: Once I've exhausted all other avenues, I ask coaches how to solve the problem.
Improving your process with reflection: I don't yet have a habit of reflecting on my process. I feel like I benefit from reflection immediately after completing something, but not so much the next day.

Manipulating Javascript arrays
.map() is for creating an array by adjusting every element, in the same way.
.filter() creates a new array from all the element in our array that follow a given rule. This could be used for filtering a general list of people to only the people that said yes to having a drivers license.
.reduce() is great for adding up all the values in an array. It runs a function on the first value and then runs it for the result and the next value, and so on.