BLEU

This week's tech post is all about solving problems and reflecting on the learning from two different problem solving experiences - a time when I got stuck, and a time when a solution came easily.

Blockage

Once upon a javascript array there lived a method called .map().

.map() is something that took me a very long time to get my head around, largely due to the callback function that it takes. However, after spending time doing CodeWars katas and focusing on using array dot operator methods instead of for loops I felt that .map() and I could be friends.

So, when I encountered this kata, I thought ‘Cool cool, they want me to use .map(), simple, I can do this.’

So, I used a problem solving technique that I had read about called the Four Step Problem Solving Method. Here’s a link to a really good explanation of the method.

Here’s step one and two - Understand the Problem and Devise a Plan:

I thought I had a nice simple solution to this issue and started step three: Solve the Problem.

Uh oh… I was capitalising the first letter of each word, but I was only returning that letter! I hummed and harred and felt myself getting frustrated. I had identified the problem, but I didn’t know how to solve it.

Somewhere in my brain I knew I could get part of the string kind of like this:

But for the life of me I couldn’t remember how it was that I could do that. So I took to Google. Google took me to .substring(), and after a quick frustrated peek at the hints I knew I was on the right track. (Wow, it was really hard for me to admit that I looked at the hints. “Shouldn’t I be independent and self-sufficient?” “Shh negative voice! Can’t you see we’re trying to learn here? Shove off with your bad vibes.”)

Okay cool, with some help from Google and the hints folder, I was able to solve this kata. (Woo!)

My main enemy was that annoying negative voice that reared their ugly head. The technical block itself caused frustration to rise in my body, and distract me from seeing the problem as a learning experience, and instead tried to trick me into thinking that this kata was a test. If I could solve it by myself, then I was ‘good’. If I needed help, then I was ‘bad’.

I practiced a lot of self compassion during this time, and found that because I’ve been doing mindfulness practice and increasing my self awareness through the Core curriculum tasks that I was able to kindly remove that limpet voice from my mind. Having kicked limpet voice to the curb, I could focus on kindness towards myself and focus on solving the problem.

I learned that the technical block is not the problem. It’s how I respond to the block that creates either a problem or a learning experience. With time, I think I will be able to say ‘huh, I’m stuck, what can I learn,’ instead of saying, ‘ugh, I’m stuck, how will I survive?’.

Elegance

FizzBuzz was hanging out in a Repl.it one day, and I came across this issue and thought ‘yus, time to whip out a conditional statement.’

I used the same understanding and planning technique as above like so:

I wrote out the function, however I forgot that I would need to put the divisible by both 3 and 5 condition first - otherwise, calling fizzbuzz(15) (for example) would stop running at the divisible by 3 condition and would return Fizz and not FizzBuzz! So how to solve this? I thought about writing the conditions like so:

if (num % 3 === 0 && num % 5 !== 0)

if (num % 5 === 0 && num % 3 !== 0)

But I opted for Occam’s Razor and simply put the most specific condition first. Here is the final solution with some logged examples:

I felt a sense of achievement and pride as I worked on this kata. For me, it was a testament to the previous kata I have done on CodeWars and the previous difficult learning experiences (like the .map() example above). I did feel proud, but my ego didn’t inflate too much, because I understood that I could solve kata this simply due to learning, planning and practice.

I learnt that things get simpler with comprehensive understanding. And comprehensive understanding comes from seeking to learn, making mistakes and slowly grasping at concepts until they are easy to reach.

Writing the blog post has made me recognise how having a growth mindset and understanding neuroplasticity is crucial when learning to code. It’s so important to remind myself that: ‘yes I can learn this! Look at these two experiences and see how similar they are. You’re simply more familiar with one concept than another, and soon you’ll be mapping and substringing yourself into a wonderful mess’.

Problem Solving Techniques and my thoughts on them:

• Pseudocode - this is something I like and use a lot of
• Trying something - I call this the ‘bash bash’ method. I sometimes feel like I’m bashing around in the dark when I do this, but I do enjoy giving things a go before I go to Google
• Rubber ducky method - I think this is a good technique when there is an error message that doesn’t make sense to me or that I can’t work out.
• Reading error messages - especially with TDD, this technique is really useful. I also like error messages because they tell me exactly which line is wrong
• Console.logging - I do this a lot. I recently forgot that to find the value at an array in a for loop that I needed to use array[i], not just i on its own. console.log() and typeof are useful tools in this kind of situation
• Googling - I do more MDN searching than Google searching. I like to go from MDN to Google when I want to see another practical implementation of a certain method etc.
• Asking your peers for help - I do like to do this as a nearly-last resort. I think that growing my self-sufficiency is important, and solving a problem alone will be a rich learning experience. However, if I am truly stuck I will reach out to other students
• Asking coaches for help - I haven’t explicitly done this yet, but helpful facilitators have jumped into the student help channel which has been super useful. I would also consider my partner a coach as he is a software engineer. He’s certainly been a really good person to turn to when I’m stuck
• Improving your process with reflection - this is something I am still working on. With more knowledge and practice I will be able to refactor my code and create more elegant solutions. For now, I will reflect on solutions others post on CodeWars etc. to see what I can learn from them, which will inform my own coding

fin.

Thanks for reading! Feel free to get in touch and tell me about other great problem solving techniques or resources.