Problem Solving

Black and white photograph of a laptop

Tell your non-tech friend a story about a time you:

In both cases, explain:

Blocked on a simple problem

More than once have been blocked on a simple problem that turned out to be either a 1 in place of an i in my for loop or missing "punctuation" such as a } , ) or ;.

When it happened, and I had to spend time trying to figure out what was wrong, I felt frustrated. Then when I found my error, I felt both relieved and a little silly.

What I learned from these experiences is that there are certain syntactical errors that I am prone to make, and so an efficient way to start debugging is to check if I have made one of these errors that I have made more than once before.

It is also useful to check my code by console.logging, linting and using a helpful code editor to highlight for me which line contains the error. (Although I have found that with missing "punctuation" the code editor is often inaccurate or unhelpful in its advice about where an error is or which character was wrong.)

Solving a problem in an elegant way

I remember the first time I knew to refactor my code such that it was creating elements on my page programmatically rather than me adding the elements individually. Adding them individually wouldn't have taken long because there weren't many of elements at the time. But, D.R.Y. is good practice. (This stands for do not repeat yourself.) And, adding the elements programmatically was a much more elegant, flexible and scalable solution.

Some of the problem solving techniques I used were pseudocode, trial and error, googling for clarification on use of array methods, and console.logging.

I felt a sense of achievement, and learnt to write less 'naive' code

Reflect on how confident you feel using each of these problem solving techniques/processes:

I feel confident in using any and all of these techniques. The ones I have used most are: trying things out, googling, reading error messages, console.logging and pseudocode. Sometimes I have used something similar to the rubber ducky method, but thinking through the explanation in my head or on paper, not actually talking to an object. Until joining Dev Academy, I haven't had coaches or dev peers, so I hadn't had opportunities to use the techniques of asking peers for help or asking coaches for help. But, when something comes up that I can't solve myself, I don't think I will have any problem asking other EDA students or our facilitators for help.