The Muppets Guide to Problem Solving

• Introduction to Problem Solving
• Pseudocode
• Trying something
• Rubber ducky method
• Reading Error Messages
• Console.logging
• Googling
• Asking your peers for help
• Asking coaches for help
• Improving your process with reflection

Problems are either simple, straightforward to solve, or absolute head scratchers. We can use different techniques, depending on the problem.

The sprint 4 curriculum is a full stack of new JavaScript technical challenges to solve.

In JavaScript you create boxes to place values in. These boxes are called objects and have labels for the values. In the challenges I kept forgetting to refer to these labels. I learnt to use a technique called pseudocode which is actually fake code so a machine can't interpret it. It is like writing a script outline for a play. I now find it an elegant and descriptive way to structure code before writing in code.

As I worked through the challenges, there was a need to write code that could be repeated over different objects. These are called functions. I found that there are different ways to write functions depending on what website or forum you Googled. Functions are a building block of code, and should be a simple as it's a basic concept in code. But with the different voices, the simple problem become more complicated. I spoke to Joseph, my facilitator and he suggested using a basic function structure to solve the challenges and look positively at what I achieved in the day. I realise the value in seeking mentorship from coaches when I have tried other approaches.

Pseudocode can also be defined as:

an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a programming language, but is intended for human reading rather than machine reading.

One approach is to start with simple statements with the goal of the code with statements. Then rewrite to represent the structure of the code. See this example. Then these pseudocode statements can be rewritten in the code language syntax you are using. This is one of my current favourites, as it prepares and starts my coding thought process, hence the 4/5 confidence rating.

This is a good one but only when used with other techniques in my opinion. First you try the trying something method. Then if that doesn't work, you try something else.

Although Ernie sings to his rubber duckie toy, the rubber ducky method may use an actual toy or not, or even another person. The idea is that you explain the problem to the "rubber ducky" in detail and then at some point you realise what to do next. I haven't used this method yet as I try the other other methods.

Error messages seem to be the most useful first step to solving a coding problem, and they are the first things I look at. But they often seem complicated hence a neutral 3/5 rating.

The `console.log` combined with pseudocode is probably the biggest revelation I've had in the last week of coding.

I feel confident to go to Google to ask questions, but I discovered there is an art to asking questions to narrow the results. For example How to Use Google to Solve Your Programming Questions.

Rating 3/5

I could definitely do this more! I feel more confident asking now that I have been in the cohort for a couple weeks.

With writing the reflection notes, I feel like I can always come back to these notes and blogs later and improve my coding and coding style.