Basic mind set in understanding how to code

Basic mind set in understanding how to code
0

#1

hey guys what mind set should one have while coding to avoid confusion and errors?


#2

Whenever you learn something new there is always the likelihood of confusion and errors. Part of what will make you successful as a coder will be your resilience in the face of these - yes, you’ll be confused and get bogged from time to time, but don’t let these things stop you from learning or trick you into believing you simply aren’t cut out for coding.

That said, there are some practices that can help you minimise the confusion and errors.

Variable / function naming

Name your variables, functions, objects etc in a sensible way, so that when you read your own code it makes sense to you. Consider the two following code snippets that do exactly the same thing:

// bad naming
function x(y) {
  var z = "";
  for (var i = y.length - 1; i > -1; i--) {
    z += y[i];
  }
  return z;
}

// better naming
function reverseString(string) {
  var reversedString = "";
  for (var i = string.length - 1; i > -1; i--) {
    reversedString += string[i];
  }
  return reversedString;
}

Every time you try to read the first one you will have to mentally process the code, whereas with the second one, it’s clear just from the names what it does and how it works.

Loops within loops (within loops) / nested IFs / Callback hell

You can easily find yourself writing layers upon layers of code that are all entangled. This is affectionately known as spaghetti code, which sounds delicious until it wraps its tomato sauce smothered tendrils around your brain and you find yourself thinking things like So, for each array within the array, my code looks at the second element (in the nested array) and compares that to the second element in the previous array’s array to see if they are the same…no, wait, if the second element in…ah, forget it :frowning:

A little nesting is often required, but if you find yourself going too deep (i.e. you can’t keep the logic straight in your own head), rethink your approach.

Sort of related: http://callbackhell.com

Pen and Paper

When in doubt, or when your code just does not do what you think it should be doing, get a pen and paper out and manually work through your program doing exactly what your code tells you to do. Keep a track of the contents of variables as they change.

Really diligently do as you are told - checking the MDN documentation if you are not 100% sure how a method works, what arguments they take, or what they return.

This is a hard thing to do well, because often our erroneous assumptions about our code are the reason it doesn’t do what we want, and those same erroneous assumptions are what we will repeat when we manually work through our code. So referring to the documentation is crucial at that point.

Go for a walk, take a shower, go to bed

When learning anything, focused study is a crucial tool, but it’s also a tool that blunts with overuse. We can restrict our brain’s capacity to make connections to prior learning by focusing too hard for too long - the alternative, known as the diffuse mode of thinking, allows our brains to make those connections. We are able to use our diffuse mode when we carry out mundane tasks, engage in physical activity, or simply daydream.

Sleep is important because we flush toxins from our brains while we sleep. The longer we stay awake, the harder it becomes to concentrate, so often the best cure for confusion that is encountered late at night is simply to sleep - we can often wake up with the solution that evaded us eight hours earlier.

You can learn more about these ideas relating to the diffuse mode and the importance of sleep in the first week or two of this free course: https://www.coursera.org/learn/learning-how-to-learn


#3

Writing code is giving foolproof instructions to the worlds biggest idiot. Computers are stupid. When you’re writing an algorithm, imagine that you are explaining something to a person who will deliberately misunderstand everything you say. You couldn’t start instructing them to make a PB&J sandwich by saying “put peanut butter on a piece of bread” because they would balance a jar of peanut butter on top of a loaf of baguette. Computers are stupid. The sooner you embrace this idea, the better your life will be.


#5

Sometimes, when you’re starting out, this may not be entirely unavoidable. If you can break your spaghetti code up to be more modular/understandable/easily handled, do so, but sometimes you just can’t for various reasons. As you get deeper into understanding JavaScript, definitely investigate promises - they can make your life so much easier. That being said, if you’re just starting out, please don’t look into them and just stick with trying to learn the basics! (Gotta learn to walk before you can run!)

All of @JacksonBates’s other points, I think, are super solid. A few things to add on to:

  • When/if you’re getting stuck and can’t figure out why your code isn’t doing what you thought it would - walk through, baby step by baby step, exactly what your code is doing. This may or may not include pen/paper, and/or console.logging the crap out of everything, and/or inserting “debugger” statements in Chrome Dev tools.

  • On that note, Chrome Dev tools can be immensely useful - learn how to use them! A quick Google search for the resource I was looking for just failed, but there are quite a few beginner-level tutorials out there.

  • Related to the first point - if you feel like you don’t even know where to begin on a coding challenge/project, break it down into the smallest parts possible, and start from there. When I first looked at some of the projects/algorithms, my mind would be in a million places - “okay, so this has to happen, but also this, but also this, and then 1 and 3 have to connect to each other somehow, BUT ALSO there’s this…” and it’s really easy to get overwhelmed. But if you break it down into the tiniest pieces, you can start writing code to accomplish that tiny little thing, and then build upon that. (Ex. for the weather app - instead of, “I need to find my location and get the weather results to show up”, you could break it down into: “Okay, I need to get my current location.” [Code that.] “Okay, now I need to figure out how to extract the latitude and longitude.” [Do that.] “Now I need to put the position into the AJAX request.” [Do that.] “Now I need somewhere for the information to show in my app.” [Do that.] “Now I need to put the information I got back from the AJAX request into the place I just created in my app.” - that’s a lot more manageable than “I need to find my location and get the right weather results to show up in my app.”) I’ll usually even write out in baby steps on a piece of paper the normal English version of the steps to do something, and then start translating that into code only after I’ve broken it down.

  • And, seconding Jackson 110% - when you’re going in circles and have no idea what’s going on, take a break and come back to it later. :slight_smile:


#6

:+1: very informative thanks


#7

Lol, never heard about this metaphor, but I like it! :+1:


#8

Exactly the metaphor in CS50! Three students lined up on a table, following PB&J production instructions to the T. One of them takes that literally (as he is the most computer like of all three students) and ends up in all kinds of mess.


#9

Yep that’s me… when i’m man enough to learn proper unit testing i’ll let you know


#10

Hey, you gotta start somewhere. :slight_smile:


#12

NIce link Mark, just enrolled!!


#13

And I take full credit for finding that link too… no one would be able to find it without me and it had nothing to do with that @P1xt fellow :grin:


#15

I am really enjoying it. I love the energy of the lecturer, it’s infectious. I’ve not given it near enough the attention it deserves though… I actually made a timetable today (from yet another of your great post’s suggestions) so I can fit everything in, in a more productive way as once I get in front of an editor I want to do little else.

I’ll go and check that one out. I’m enrolled to that way of thought by default anyway so I’ll be happy to know how to put it to real use. Thank you :thumbsup:


#16

Such a good answer. Kudos to you!!


#17

I keep this in mind, more or less, as I started really getting back into coding. It’s great to hear ones mindset on it. That was cool. I paused on AJAX, for I’m not familiar as of yet, but looking forward nonetheless.

Current focus YDKJS as my mindset went there with the Practice in Chapter one. It’s an easy read of the code now for me, but in the beginning, thought create, upon thought create, upon thought… w/ console.log in mind when I backtracked.

Oh and I’m in hear replying based upon my search on “Effective Thinking Through Mathmatics” after wondering off of YDKJS. Back to coding.