Blocked by a simple problem.
Blimey where do I start. I suppose the question is the point here is a simple problem, which is usually quite subjective and only simple in hindsight. I got stuck for a little while on the first challenges involving functions with parameters. This was a couple of sprints ago, prior to honing in on these problem-solving techniques, so of course the one that I was quite used to was google. I found that at the beginning, even a google search can prove problematic when you're not entirely familiar with terminology, in which case you really need to look for different sources which cater to varying skill levels. I also reached out for some advice, and with a combination of these approaches I was able to create an analogy which really helped, and still helps to this day – the audio analogy which I refer to in my JavaScript Intro blog. I felt a bit silly as I knew I was stuck on something very fundamental, though what I learned is that googling and asking for help are both very normal parts of the process, and a huge part of how anyone learns.
Elegantly solved a problem.
I was really pleased with how I solved the Fizzbuzz challenge. I struggled a little on the first part – the Fizzbuzz – so figured I need to take a breather and have a good go at some pseudocode. This is where I determined that a number divisible by 3 divided by 3 will leave no remainder. Of course it does! Right so the same will be the case for 5. Hmm a picture is forming. Where I got a little stuck was the multiple of 3 AND 5, so this is where got away from it and had a good think. Standing outside away from the computer I figured that 15, and therefore multiples of 15 are what I'm looking for, so I added this to me pseudocode. Loving this pseudocode.. solving the core problems without trying to solve the relatively new syntax at the same time.
It was the Super Fizzbuzz where I felt like I solved quite elegantly. I was feeling quite calm and collected, so I tried to get it down in pseudocode before confusing myself. I knew an array was coming. Knew that array was going to have to be scanned though. Knew the result of that needed to get through my Fizzbuzz function.. oh you've all been there, so I won't dredge it all up again. Anyway, pseudocode helped to separate the actual problems to solve, from figuring out the details and syntax. This was a really valuable lesson and one that I think I'll make a habit of.
Rubber Ducky Method.
To choose a method of problem-solving from the list that I hadn't heard of; it has to be this one. Having said that, it's a method that I have definitely used! This could be quite a good one for me to use with the dogs. They may look at me sideways but I think this could especially apply when working remotely. It helps a lot just to get your thoughts out and hear the words, rather than keep it all mushed up in the code soup that my mind has been lately.
A couple of times recently I have been telling my brother about something that I'm struggling with, when I suddenly figure out what I'm trying to do just by putting it in to words. I see this as almost the reverse of pseudocoding; putting it in to simple, descriptive statements, but afterwards or during solving the problem.
Pseudocoding.
My first introduction to using this in practice was following Joseph along the cafe tutorial. It seems like a good way to not only plan out the approach, but to free up your mind by getting those main factors down. Similar to commenting, it could also be a great way to describe the intention to others needing to look at potentially-unfinished code. There is always something really satisfying about ticking off a to-do list, which is effectively what pseudocode is!
Googling.
At the moment, this is a biggie. Given that the results from the good sources tend to be more instructional rather than direct code solutions, Googling still tends to be plenty educational. Certain resources can still be quite difficult to understand, so it can pay to try to research beginning at a more simple level and then continue to the more advanced. A trap that I have found is easy to fall in to, is looking for examples close to what your current problem is. The best solution, for current problem and for long-term understanding, is to research the fundamentals and then apply to your own problem.
Asking for help.
I have addressed a little in my neuroplasticity blog how asking for help can bring up some of those self-conscious feelings. Am I an idiot for asking this? Actually, no. I would never think that of somebody else, so the reverse is true. I have not been very good at this up to this point, and I think that stems from always feeling that my work has to be genuinely mine. But sharing is how anybody learns anything.
Console.logging.
I've started doing this a lot. It's like a little window into a certain point of your process. Or like tasting as you cook. Console.log is good.
Trying something.
Some of my initial problems came from just trying something. But I'm referring to getting stuck in without a plan. Now I do like to try things with a purpose, as part of a plan. It helps to realise that you can try things out without fear! Things can be undone. Try different loops, different methods, console.log at certain outputs to see what's going on. Trying something is also good.
Read error messages.
Now this is one that I need to put a bit of focus on. Generally I see a heap of scary red text and go AGGGHHH. Occasionally I'll decipher a really helpful and simple error, but it's not something I'm very well-versed in right now.