A motorbike, when in motion, follows certain laws of physics. For example: similar to riding a bicycle, it is very easy to maintain balance when the thing is going fast. The balance comes from some magnificent gyroscopes: two fast rotating wheels. In order to stay upright one has to put your trust in the machine (and physics), go fast (within the speed limit), and let go of the illusion of control.

Here is another counterintuitive lesson: you need to turn counter to the desired direction in order to go into your desired direction. That is you need to steer left to go right, and steer right to go left. That is called counter steering.

In the very beginning I felt the same about programming as I did about motorcycles. There are bits that make absolute sense, but then there are areas where it all feels contradictory and confusing. But if time is made to understand the basic principles and underlying mechanics of physics (and programming) the darkness is cleared.

Luckily I didn't have to sit under a tree and ponder on the principles of physics; there are great tools that I can use to make sense of it. The same goes for programming. There many different tools, techniques and approaches to help understand something and aid in problem solving.

I will be going through a few problem solving techniques and tools and briefly explaining how I would use them. Then I will rate myself on how proficient I am at each. I will then quickly dive into a few problems that I got stuck on and what I did to solve them.

"The problem is not the problem. The problem is your attitude about the problem. Do you understand?" - Captain Jack Sparrow

Tool #1: Asking peers/coaches for help:

Much learning can be gained from asking a simple question. There is no shame in trying to understand something and asking because it is very likely that someone else is having the same issue as you. You are not stupid, it just means you're the only one brave enough to speak up. Before asking though, I would put myself in the other persons shoes: how would the question sound from their perspective? Is it a well thought out, quality question? Or is it just a string of random words. My rating? 7/10.

Tool #2: Trying something

Trying something, aka experimenting, can be useful. Especially to explore the unknown and acquire new knowledge. Trying new things though does not mean randomly type in code and pray that it will work. Or copying and pasting some code from Stack Overflow without understanding the piece of code. Trying new things should involve trying something one step at a time, observing the output, understand the underlying principles, and reflecting on why it did, or did not work. Almost like a science experiment. Always be open to try something different. On the trying something scale I am a star student, 9/10.

Tool #3: Dr Google

Isn't programming just googling? My browsing history would suggest yes. But I'd like to think no. Though, it is extremely useful (and advisable) to consult Dr Google. At the start of my learning journey I tried to commit everything to memory. I got frustrated if I forgot something. I felt guilty for google-ing the simplest of concepts that I should know. That was a mistake and I realised it. Now though, I consult and trust Dr Google to help me solve problems all the time. There is an art to googling though, and that skill can be improved. See this post. Dr Google rated me as a top user.

Tool #4: console.log-ger

console.log should be put on speed dial for me. It can be extremely useful to check if your desired result matches the actual result. If not then it's time to find the problem and fix it. Do that repeatedly from start to finish, before the program gets too big. There is nothing worse than trying to find a minute mistake if all you had to do it do was console.log to find small mistakes along the way. console.log('Can verify: uses in abundance.')

Tool #5: Reading error messages

Things can turn ugly when writing a program. We might think its flawless and then an error message pops up in the console. We are left saying: Curious, eh Watson? So when it inevitably happens its time to put our detective hats on and start investigating the error. Reading error messages should be combined with using Dr Google especially for those hard to decipher error messages. The most common errors I come across are: TypeError, SyntaxError, and ReferenceError. After identifying what the errors are its time to start debugging. Sherlock Holmes would give me a 6/10 - I need to improve.

Tool #6: Pseudocode, planning and breaking things down

When I started to code I would often just straight in and just code. Sure I would break things down into manageable chunks, test everything as I go along, but I had no plan from the outset. I wasted so much time debugging and fixing which could have been avoided. By slowing down and writing pseudocode you are forced to organise your thoughts and think of how the code will run step by step. Don't skip on pseudocode like I did. I came across this article and used it to up my pseudocodeing.

            function (string)
            IF string equals 'pseudocode' 
                    return 'Rating: 5/10, still needs work'
            ELSE IF string equals 'planning' 
                    return 'Rating 6/10, getting better'
            ELSE IF string equals 'breaking things down'
                    return 'Rating 8/10, much better'
          

Tool #7: Ducky method

Explaining things to a rubber ducky can seem silly, I thought so. However, delving into this technique I discovered that it can be very useful, in fact I have been doing it all along. The rubber ducky-ness of the duck does not matter: it could involve explaining the code to someone or even explaining someone imaginary. I would still recommend the rubber ducky to you... and myself. Being forced to explain the code line-by-line is useful, but being able to explain the code or problem to something that has no knowledge of code-ing is next level. Explaining things to myself and others: 7/10. To a rubber ducky: 0/10.

Tool #8: Reflect

Think of this as another thinking tool. Reflecting is a technique I really enjoy and I believe it helps to increase my craft at a much faster pace. Especially after solving a difficult problem I would sit and think on how I solved it and how I can do better next time. Admittedly I don’t always write out what I have learned, but I do take the time to reflect on it after the fact or at the end of the day. Entry #8: 7/10.

Overthinking a simple problem

On the second challenge of the DOM interactions I got blocked on what I considered to be a simple problem. I needed to update the counting function so that it counts how many blue, green and invisible dots there are and add that to the totals. I tried many different ways but I couldn't get the code to work. After struggling and leaving the problem until the next day I reached out and asked for guidance on Slack. Someone helped out by challenging my thinking and suggesting a different approach. All I needed to do was just to get all the dots that had a class name of blue, green, or invisible. It was so simple, but I was over-thinking it. On reflection, I did the right thing, asked for help. But I should have done, as well, was is to put more time in the problem down with pseudocode and explain to someone what should happen.

Complex problems: elegant solutions

I got stuck on the fizzBuzz challenge, which is of course difficult. But I got stuck at a point I did not expect. Though the problem on ths surface seems hard I made sense of it with pseudocode. It all consisted of a series of problems to solve. So I took a few mindful breaths to become calm and alert and went about coding.

What I had produced, though, was completely wrong. I got frustrated and annoyed because I thought my solution should work. So I went into problem solving mode: I used tool #3 (googled), paired that up with tool #2 (trying something), all the way using tool #4 (console.log), I then resorted to tool #7 (without the ducky)... but nothing worked. I threw all my tools out and started from the beginning. I actually read and tried to understand exactly what the unit tests are saying with a fresh mind. Following that I reformulated my function and it was green lights all the way.

That bring us to tool #9, the most important I think: don't over complicate and enjoy the journey. If you don't you'll get tensed up and it blocks out any new avenues for solving a problem. I was being too serious and 'focused', not enjoying myself. Realising that, I was able to let go and my mind cleared, become relaxed. I was able to solve the problem. Sometimes the solution to the most complex problems are elegantly simple.