"A time you got blocked on a simple problem"

I've been doing a few coding exercises outside of this course to help me learn the JavaScript syntax and expose myself to more concepts. My technique has been to do the questions alongside a tutorial or textbook to understand the concept, then to do that same question again the next day on my own.

One of these problems had me completed blocked today. I knew the theory on how to solve it from learning the day before, and in the test case my code worked perfectly, but it kept failing something in the full suite of tests.

The problem solving technique I used initially was to try to isolate the problem. I added a console.log for every substep of the calculation, then manually worked out what the answer should have been at each point. I realised that the code was continuing to iterate longer than it should have, in ways that sometimes gave the right answer and sometimes didn't. I was feeling pretty frustrated at this point so took a few deep breaths, and this helped me realise the structure I was using (a for loop) was completely wrong, as the way I'd set up the code would only work with a do-while loop.

What I learned from this is to start by working through each step of the problem from a high-level view - I spent nearly 30 minutes bogged down in implementation within the loop, but I hadn't even thought to question the structure itself.

"A time you solved a problem in an elegant way"

I don't want to spoil the Sprint 4 content for anyone, so will stick to outside-the-course examples. There was one exercise I did manage to solve on my own, which was pretty cool. Basically the problem was to take a list of numbers, then pair up all the numbers in a way that the largest sum of a pair was kept as low as possible. I figured I could just sort the array of numbers (though I did have to Google how to do this!), then take the smallest and the biggest number and pair them, then the second-smallest and second-biggest, and so on.

This was still a little frustrating at times as I ran into problems with syntax, but all in all it felt way better because I could see the overarching 'point' of the program, so I was confident it would work if I could just figure out all the substeps.

What I learned from this experience is that understanding what is going on in a program, and why, is essential to getting it to work - but also is essential to staying calm and motivated! I think it's shown me that if I don't fully understand something at the start, I shouldn't even touch the keyboard until I've actually worked what I'm doing. Otherwise I waste time and get frustrated over implementation without making any real headway.

Confidence with problem-solving techniques

• Pseudocode
• I feel pretty good about this, though I try to use a bit of JavaScript syntax in my pseudocode when possible, to reduce the mental load of translating it to real code.
• Trying something
• I'm confident in trying different approaches - maybe too confident, since I sometimes jump in too quickly without thinking through all the limitations of the approach. I'm working on fixing this!
• Rubber ducky method
• I keep a little rubber duck picture at the top of my notes, and explain everything I learn to him :) This is really useful, because I quickly find out what I don't really know!
• Reading error messages
• I'm pretty good about reading and Googling these, though I don't always understand what they're trying to convey.
• Console.logging
• I feel a little too reliant on this one!
• Googling
• I Google a lot, mostly for syntax issues.
• Asking your peers for help
• I feel pretty uncomfortable doing this, but will if I really have to.
• Asking coaches for help
• I'm pretty comfortable with this.
• Improving your process with reflection
• The reflection process has been a neat experience, so I'm trying to keep it up while learning even when there's no reflection prompt. I do struggle to be consistent with this, so it's a work in progress.