You Want It Darker
You Want It Darker
I'm not messing around. "You want it darker" is a song by Leonard Cohen.
I am Leonard Cohen obsessed. I absolutely love him. I started with his poetry book 'The Book of Longing'.
When I was 14. I just walked into the library at school one day and it was there. I read his poem about a 'magic cure'. It was just so relatable. That was half my life ago. I have listened to his CDs, covered countless of his songs, and even read one of his novels!!! ever since. And I barely ever even read.
One last final .map() practice (well, at least for now...)
I just had this little idea and I thought it would be fun to do.
Errors and Debugging - Part II! (Again!!)
Tools for tackling code errors
Dissect the Error
- When an error first appears on your screen, find the line in the error specific to your code.
- You want to find the part of the error message that gives you insight about what happened.
- That line is generally at the top of your error stack trace.
Ask yourself, is the solution in the error?
Search The Web For Instances of The Error
"Copy and paste the important part of the error message into a search engine and look through the results until you find someone else who has also run into that issue. To get better search results, you can include relevant keywords and modify the error message to be more generic.
"
Sometimes, you have to make your errors more generic
If you try to search the net for an error that is too specific to your problem, then you won't find anything. So what you need to do in this instance is:
- Swap out any highly specific names for general words
- E.g. the name of an array for 'array', or the name of an object for 'object'
- Also it helps to put the name of the language in question as a keyword
- And then the next two steps are:
- Look for promising results
- Also cross-check things with the MDN
- And actually the Codecademy course also recommends searching directly into Stack Overflow - which I am yet to ever post on at all, to be honest...
Errors and Debugging - Actual Lesson Part -
What I learned yesterday:
JavaScript Error Types
SyntaxError
ReferenceError
TypeError
Debugging Errors.
Okay. So there is a step by step process.
What I learned today:
WHAT THE THREE NICE AND EASY STEPS ARE:
- Run your code. If you can find the error's type, description and location, go fix that.
- Go to the file name and the line number. Using the error type and description, identify the bug in your code.
- Fix the error in your code and then re-run the code. And then if there are any more errors that come up again then repeat the 3 steps again from start to finish!
"Locating Silent Bugs"
Omg wow that sounds so exciting!!! Wow wow wow!!! That sounds amazing.Here are some really great quotes:
"You may find that your code is consistently returning incorrect values without throwing any errors. A LACK OF THROWN ERRORS DOES NOT MEAN YOUR CODE LOGIC IS COMPLETELY CORRECT." And also this one:
"Even if your code runs error-free, it is not necessarily bug-free".
"An incredibly powerful too for locating bugs is a method you likely learned very early in your JavaScript journey: console.log()!
Here is one response I gave to an exercise. It was so cute and this is so much fun. |
Debugging with console.log()
Okay so I reached out to my wonderful mentor Chung who I have mentioned on here before about this.
He sent me this lovely and wonderful response in reply.
He said that:
'A lot of developtment is about manipulating data, changing and transforming things for different uses.
console.log() lets us
SEE WHAT SOMETHING ACTUALLY CONTAINS AND LOOKS LIKE, RATHER THAN GUESSING WHAT IT MIGHT BE
It doesn't affect any other code,
it just outputs a message to the console.
Because it doesn't change anything else, it's really easy to insert it in places to find out what's actually happening".
Thank you, Chung!! Wow!
So what he's saying here is, that:
- Sorry but this line is so good that I just had to rephrase it:
- "A lot of development is about manipulating data, changing or transforming things for different uses.
- Console log lets us see something for what it actually is, rather than guessing what it might be.
- It doesn't AFFECT OR CHANGE ANY OF THE OTHER CODE and so for that reason, that's why it is really useful.
AND THEN CHUNG SAID ONE MORE THING! Which was amazing (he is so awesome). 🦄
" console.log() is really great and there's no harm in using it as much as you need when working through things
Just remember to remove it from production code for cleanliness' sake. "
ADHD at Uni
When I was 18-20 and at Uni pre-ADHD diagnosis, it was an absolute nightmare.
I just thought I was so stupid. I thought I was so dumb all the time.
But I can see now that what was really missing for me was structure.
At Uni, there was a complete lack of structure.
But now I am in structure heaven - I have my learning updates doc, my course, my CodePens, and my blog.
So now, I am in structure heaven. 🌈🦄🦄🦄🦄🦄🦄🦄🦄🦄🦄
P.S. I had my interview with Codecademy and that came out and it references this blog - so here is the link: https://www.codecademy.com/resources/blog/how-i-learned-to-code-with-adhd-trainee-software-engineer/
P.S. I had my interview with Codecademy and that came out and it references this blog - so here is the link: https://www.codecademy.com/resources/blog/how-i-learned-to-code-with-adhd-trainee-software-engineer/
Comments
Post a Comment