Being Blocked on a Simple Problem

I got stuck while trying to assign an object as a property to another object.

There was a parent object called 'linda'. That object had a property called ‘children’. As the value for that ‘children’ property, I wanted there to be an object that represented one child with a name of Ben and an age of 2.

I first tried it as follows:

This didn’t achieve the result I needed, instead I got a syntax error: “ Unexpected token ‘:’ ”

"Hold on" I thought, "I’m sure I can get this to work."

I quickly tried the following and used console.log to check the value of ‘linda.children’

This time I got an error saying that ‘ben’ hadn’t been initialised. That made sense to me as the 'linda' object referenced the 'ben' object before that line of code had been executed.

Losing my patience I moved the 'ben' object declaration up above the linda object declaration.

Now the code did what I wanted it to do - I had my linda.children value set as desired.

Then I looked back at my original error message. I had originally failed to put the ‘ben’ object inside curly brackets, which is how we denote objects. In lieu of those brackets, the compiler hit the ‘:’ instead and stopped executing.

I learnt (as I have learnt before and will probably learn again) to take just 3 seconds to understand the error message before writing any more code.

Solving a Problem Elegantly

A problem I managed to solve elegantly was Super Fizzbuzz.

Fizz Buzz is a simple introductory programming problem where a function should return fizz if a singular input number is divisible by 3, return buzz if it is divisible by 5 and return fizzbuzz if it is divisible by both.

If you understand loops and conditionals, it’s not too hard to solve.

Super Fizzbuzz, the problem I solved elegantly, is an extension of the original problem.

“Now” it says, “what if we input an array containing multiple numbers into a function instead.”

One solution would be to loop over the array and inside that loop include, all over again, the same process we did in fizzbuzz… then each time saving the result to an array.

After the loop is done, the function spits out the array of results.

A better solution would be to call the original fizzbuzz function we already made, inside the loop, so that each item in the array is simply sent to our existing fizzbuzz function.

This significantly reduces the amount of repeated code we create and therefore makes any future changes to the code easier to make.

I spotted the opportunity before writing up my code, but if I hadn’t, taking the time to refactor my code (rewriting it without necessarily changing it’s functionality) would have allowed me to improve the quality of the code in this way.

My Problem-Solving Process

I don’t have a strict process for problem-solving in code but it might look roughly like this.

Before starting, I want to break the problem down as much as possible. At first I was surprised at how granular I had to be in my planning, but it makes sense because our instructions for the computer must be exact. Before writing code I write line by line, what needs to happen.

Before, during and after I write the code, I may just try stuff out. I might check that something works as I expect, like the way a variable is stored in memory, or a way of accessing data in an array or object. Or I might try something in hopes that it will simplify my code or make it more modular.

When I’m stuck I might use console.log or debug my application. This simply gives me more information about what is happening inside my application as it runs - a window to peek through. I still find this a bit slow and regret having to put console.log() all through my code. Perhaps there are ways to work faster with console.log().

Reading error messages and copy-pasting them into Google is helpful. I didn’t like doing this when I first started learning to code; it felt like cheating, but it is actually the work of programmers, junior and senior alike.

Throughout the coding process, I am also trying to understand every part of the code that I touch. Simply googling my nagging questions or checking the official documentation is often enough to get the most learning possible out of a project or task.

The ‘rubber ducky method’, trying to solve your problem by talking it through with an inanimate object, or simply muttering under your breath (take your choice of weird), is effective because it makes you take a step back and see the wood for the trees. The solution is often right there in front of you.

It also prepares me for the next step of asking for help from a friend or mentor. There is an art to asking for help. Roughly, a checklist to ensure effective help-seeking looks something like this:

• Read the docs first
• Try a few things yourself first
• Explain what you are trying to achieve rather than what you’re trying to do
• Explain what you’ve already tried
• Describe the symptoms based on what you’ve observed is happening, not your guesses based on what you’ve imagined is happening
• Include all relevant context such as your code and perhaps release versions, etc
• Be precise and state your one exact question you need answered as clearly as possible
• Be receptive to feedback and assume the good intent and good character of anyone who has taken the time to acquiesce your request