Christelle's Blog

Blocked by a Simple Problem

The last exercise for the JavaScript Olympics, 'newAthlete', was very simple. Yet my solving it was not as straightforward. I ended up needing to read the instructions many times for the solution to click, as well as reading the tests for the function.

The Dev Academy handbook said the function took four parameters: a name, age, sport, and quote. Functions are a list of instructions you give to a computer. Parameters are the input the function takes and does things with. All I needed to do was list these parameters where you specify the parameters, and in the space for function instructions - as an object for the latter.

Throughout this process I felt confused and focused. Confused because I didn't know what I was doing, nor what I was doing wrong. Focused because I was keen to figure it out. I learnt that it would serve me well to go through the instructions or tests slowly, especially if I'm unfamiliar with the type of problem or if I'm stuck.

Solved a Problem Elegantly

I filled in the 'deBee' function of the Built-in Methods quite elegantly. Functions are a list of instructions you give to a computer. For this function, we needed to take a sentence and remove any 'buzz'es, no matter what case each letter in the word was. For example, 'buzz' or 'BUZZ' or 'bUzZ', 'BuZZ', etc. they all needed to be removed.

Firstly, I wrote down the methods I needed to use, given the instructions in the Dev Academy Handbook. Methods are functions built in to the language, so you can just use them by refering to them. For this exercise, we need to use the methods 'split' and 'filter'. Then I looked through the tests for this function to understand the end goal. Tests make sure the code is working as it should, they also tell you how a code should work. I wrote down the steps I thought I needed to take to make the function work. Having used the equivalent methods as 'split' and 'join' in Python, which I learned through university, I knew how to use these methods. So, using the split method, I took the sentence and made a list of the words. When looking at the tests, I quickly realised that I could use the 'toLowerCase' string method to take any 'buzz'es, with their varying cases, make them all lower case. I used this within my use of the 'filter' method, which returns a list of words that match the filter, which was not any lower case 'buzz'es.

I solved this problem quite quickly and without much, if any refactoring, that's why I say I solved this problem elegantly. It helped that I had experience with similar problems in the university programming paper I took. Throughout this process I felt energised, curious and excited. I love solving problems and puzzles. It was satisfying to have come to a solution in a straightforward manner.

Pseudocode

Confidence: high. I find planning out the code I'm about to write is helpful with moving forward with clarity and efficiency.

Trying something

Confidence: very high. This is my first instinct when I code: code whatever steps I think I may need. I just get so excited and want to dive straight into solving the challenge. However, this could be disadvantageous when stepping back, looking at the big picture, planning, and maybe writing some pseudocode would be most beneficial. Stepping back would be especially helpful when starting to write code, or when I get stuck.

Rubber ducky method

Confidence: low. I haven't tried this method. This will probably be the last thing I take out of my toolbox because the idea of it feels uncomfortable, so much so that I imagine I wouldn't be able to think while trying to talk. I would rather talk to my boyfriend, although it's probably not the best use of his time. I would also prefer writing pseudocode or writing down my ideas, vs. speaking them out loud to an inanimate object.

Reading error messages

Confidence: medium. I don't get scared of error messages, however I'm haven't mastered understanding them. I always read them to get an idea of where in my code I went wrong, and to develop my ability to understand error messages.

Console.logging

Confidence: very high. I find it very useful to console.log each line of code, especially for functions. This technique helps me move forward knowing my prior code works, and to see and know what I'm working with (e.g. arrays, objects, strings, etc.)

Googling

Confidence: medium. I think I word my searches well, and I've found some great websites for my coding questions: MDN Web Docs, W3Schools, and Medium. However, I've found I'm not always great at picking out important information the first time I read the content. I've gotten better with repetition, and I'm aiming to be more efficient at picking out important information.

Asking your peers for help

Confidence: low. I haven't tried this. This is probably one of the strategies I'd try, once I've exhausted the above, plus reflection. Although, sometimes I search Discord if I get stuck, and the threads there are often helpful.

Asking coaches for help

Confidence: low. Like asking peers for help, it's one of the last strategies I'd try. So far, I haven't had the need to do this, or someone else has already beat me to asking the question, so I just look at the relevant Discord thread.

Improving your process with reflection

Confidence: medium. I quite like doing journaling exercises in general. A couple exercises I like to do are: writing my goals for the day, writing why I did or didn't meet my goals, and for the day or week, asking the following questions: 'What went well?', 'What needs work?', and 'How can I improve or optimize?'. I don't like to journal without prompts or structure.