Problem Solving

07 July 2023

Simple problem blocks

Explain a time you were blocked on a simple problem

A recent simply problem I was blocked on was a question in the manipulating the dom challenge in the javascript kata section. I was struggling with figuring out how to tell part of my code what it's value should be by assigning it a value previously defined in my code. I felt quite frustrated at the time as my pseudocode and logic was sound, but I couldn't figure out the right word to use to communicate to my computer what I wanted it to do.

I tried doublechecking my pseudocode, googling potential approaches and solutions to my problem, tried a variety of different solutions and was still stuck. Given that none of these worked, I then ended up asking someone from my cohort for help. This solved the problem for me, as they have a bit more experience working within javascript and pointed me in the right direction.

This block and its resolution really reinforced that I do actually know my limitations and when I need to ask for help, and that doing so is a much more productive use of my time than struggling through a bit of syntax that I don't understand! If I get to the point where I'm not actively trying different things for a reason, and just frustratingly trying the same solution and looking for different results, taking a step back or asking for another perspective is worthwhile - especially when I am not yet familiar enough with javascript to be able to easily spot my syntax based mistakes!

Elegant problem solving

Explain a time you elegantly solved a problem

A time a elegantly solved a problem was during the super fizzbuzz challenge in javascript kata! Having to write a function in order to return specific words for specific numbers wasn't something I had done before so I was quite proud I managed to solve it in one go and feel comfortable and confident through my process of doing so. I started by checking all the code requirements stipulated by the tests, wrote my step by step pseudocode and tried writing something. While writing my pseudocode I was able to recall some similar code that I had written for a previous sprint challenge that I could build off to solve the problem.

Throughout the problem solving process I felt very present in what I was doing - each line of code was thought through and intentional and I was able to justify everything I was writing. I think my pseudocode really helped with this as it was most similar to an ordered checklist rather than a general vibe of things to put into my solution (as can often be the case with unfamiliar problems until I can narrow down the direction I should take).

I think it also reinforced that having a base to build upon, rather than coming up with something completely new really helps my problem solving. In this case it was provided by previously written code, but in cases where that isn't applicable having a similar example or just trying to write something so I can get a measure for where I should be headed with my solution speeds up and increases my confidence in getting to a solution!

Problem solving techniques

Reflect on how confident you feel using each of these problem-solving techniques

Pseudocode

I use pseudocode for every problem I encounter that I have to think about/don't immediately have an answer to. I am a very organisationally orientated person, and I think through my full approach to problems first by assessing what I have been given, what I am trying to solve, and what I need to solve the problem. Pseudocode gives a way for me to write it down and have it as a track record of how I solved a problem.

Trying something

When faced with an unfamiliar problem, trying something is my first approach to actual code writing as it gives me a basis to work from, and depending on the success level of what I have written either confirms I am on the correct path, or will give me the feedback needed to pivot to the correct solution.

Rubber duckying

I haven't directly implemented this technique yet, but I have confidence that it will be very helpful when I use it. Explaining things to someone else and being forced to look at something from another perspective and break it down in the simplest way extends your understanding, and my decade of tutoring high school science can definitely attest to this!

Reading error messages

I feel mostly confident with being able to read error messages. Occassionally the error messages from the tests could be a bit confusing but overall they often clearly point out a syntax or other error, making it much easier to fix my code than having to work through it myself.

Console.logging

I am most confident and find console logging most useful when tyring to look at the contents of an array or object, or look at the actual output of some code. I think there is some room to improve my confidence with this as it is normally a flippant problem solving technique to see if I can see what is happening, rather than something I would choose first. However I think that it will be more useful when I am not just writing general functions, which has been most of the kata this week.

Googling

I am extremely confident with using google to help solve problems. This is a tool and method I have used throughout my physics degrees and career, so I am both familiar with it, and know how to utilise it most effectively for myself.

Asking peers

I am not very confident with this yet, but am hoping to change this over this course. I think that part of this comes from not knowing the people in the course super well yet, and I need an amount of trust in the person I am asking for help before I can confident in reaching out. I am however confident this will improve over the duration of the course.

Asking coaches

This is the technique I feel least confident with. I think this is due in part to not having a lot of direct interaction with the facilitators as foundations is remote and mostly self taught/directed. Another part is that I have had some unsupportive past experiences with asking for help from managers, which will take some time to work through. I am hoping that through the environment and people at dev academy I will be able to become more comfortable with asking coaches for help, and also become more confident in knowing I should get the assistance I need.

Improving through reflection

I am very confident in being able to use reflection of my work to improve. For the problems I get actively stuck on and struggle to solve, I note down afterwards what I learnt from solving that problem - both syntax and approaches I should make sure to reinclude, or ones to disregard. This process not only reinforces it for me, but also allows these reflections and approaches to be easily accessed at a later point as required.

Asking for help

Reflect on a time you were reluctant to ask for help. Consider what made you reluctant to do so. What might you try differently next time?

I was reluctant to ask for help when I was struggling with my simple problem earlier this week (as outlined above). Part of the reason for my reluctance was that I am not very confident or comfortable asking for help virtually! Virtually I can't see if someone is busy, read all their non verbal feedback on the situation and how they feel about helping me before and during my request for help. This can result in me feeling unsure about whether it is okay if I have asked them for help, as well as limiting the direct feedback that it was okay for me to ask, and that my question wasn't 'stupid'.

I've had some unsupportive experiences when having asked for help in the past so can get quite nervous about someone thinking I am annoying or frustrating for not understanding something simple, such as 'basic' syntax. I also find it quite intimidating to have to ask for help in large channels with everyone from foundations as it exacerbates these insecurities.

Next time I think I will make sure to set a timer for how long I have been struggling on a particular problem, and immediately ask for help at the end of that instead of stewing over doing after I have realised I need to. I think also approaching someone from my cohort individually for help with a problem instead of forcing myself to immediately be comfortable with messaging the tech-questions channel as a first resort.