Zen and the art of Coding

Submit

Please email hello@zenandtheartofcoding.info for a password

Intro to algorithms

• every JavaScript section so far (except for events) has been building up to this
• if you have been following along, congratulations, this is huge 🎉👏
• from here you can really take coding in any direction you want from frontend to backend to game dev to data science and AI
• you can really start doing leetcode (opens in a new tab) problems if you want to get super serious. I might even show some here
• algorithms are step-by-step procedures for solving computational problems
• you hear the word all the time: "my instagram algorithm is showing me nothing but DIY vegan recipes lately". if that is true then instagram has some data point associated with your profile and they are just using that in functions just like this

Palindrome

• fuck it, lets just dive right into the deep end
• lets say you need to create an algorithm to check if a number is a palindrome (opens in a new tab) (the same backwards and front) or not
• lets put everything together that we have seen so far. lets create a function that takes in a number as a parameter, use built-in string and array methods and then conditional logic to find our answer

function isPalindrome(num) {
  // turn the number to a string
  let numToStr = num.toString();
 
  // turn the string to an array (split it with nothing)
  let strToArr = numToStr.split("");
 
  // reverse the array
  let arrReversed = strToArr.reverse();
 
  // join the reversed array back to a string
  let reversedStr = arrReversed.join("");
 
  // turn the string back to a nummber for consistency and strict equality checks
  let reversedNum = Number(reversedStr);
 
  // compare num and reversedNum
  if (num === reversedNum) {
    // if num equals reversedNum, we have a palindrome
    return true;
  } else {
    // if not, we do not have a palindrome
    return false;
  }
}
 
console.log(isPalindrome(121)); // true
console.log(isPalindrome(-121)); // false
console.log(isPalindrome(10)); // false

• that is a step by step algorithm. play around with it, console.log() all of the variables in the function to really see a visuaul of how it works
• that step by step approach will work and solve your leet code tests but nobody really codes this way. unless you are really spelling something out like I just did, you can chain these methods together. this is the exact same algorithm:

const isPalindrome = (num) => {
  let numReversed = Number(num.toString().split("").reverse().join(""));
  return num === numReversed;
};

• if you are like wtf 🤬🤯, don't worry, leetcode says that 7.6 million people have tried that on their platform and only 4.2 million (55.6%) have solved it. I mostly want you to see both the step by step thought process along with chaining together your methods. plus this used numbers, strings, arrays and then back again
• this is where style and the balance of readability comes into play. sometimes just because you can do an entire algorithm in one line doesn't necessarily mean you should. it could be hard for other devs you are working with or you could come back and be like "how tf did I do this..."
• the best code is "self documenting", which means variable names make sense and functions are easy to follow. actually documenting and writing comments to explain something is also totally valid and often appreciated

Space and Time Complexity

• this is kind of bordering on the scope of what I was picturing for this course and don't want to get too deep into this (yet?) but want to mention it for your grand nexus sphere of information
• there are usually many ways to solve problems and to do things using algorithms and some ways are "better" than others. "better" meaning they are mathematically provably better
• very often your first iteration of an algorithm will be to just get the function working and to get the result you are after. sometimes that looks a lot like that step by step process that I showed above. that kind of direct line of thinking is usually called the "brute force" approach
• the brute force approach to algorithms is absolutely fine is most real world scnearios, especially in general web dev. I think that is important to mention because so many other courses and bootcamps won't actually tell you that
• the "better" algorithms are more optimized and will both run faster and take up less memory on a computer. these algorithms become important when you are fine tuning your code and when you are working with huge data sources
• that is what space and time complexity is
  • time complexity: how long an algorithm takes to run (in terms of the quantity of input it recieves)
  • space complexity: how much memory (or space) an algorithm requires to run (also in terms of the quantity of input it recieves)
• space and time complexity can be defined as something called "Big O Notation". Big O Notation is basically a mathematical way to determine the efficiency of an algorithm
• I don't think I'm going to get into that here. it can be a little intimidating to non-comp-sci people and maybe even a little off-putting and at this stage of game, it really is unnecessary. if this is brand new information to you and you would like deep dive, I really like this article (opens in a new tab) by freeCodeCamp
• but at a super high level, the more times your algorithm has to run through the input, the longer it will take and the worse it technically becomes. thats the time. the space comes into play when you start using lots of variables and creating new data structures to hold information while you do your logic
• for example: if you have a for loop running through every single item in your input array, it takes time to run through every item in the array and run it through your logic, if you have nested for loops, your code will take double the time to run through the same input array

for (let i = 0; i < arr.length; i++) {
  for (let j = 1; j < arr.length - 1; j++) {
    console.log(arr[i], arr[j]);
  }
}

• we are talking milliseconds here. I don't want to totally dismiss eventually optimizing your algorithms, nobody wants a laggy UI! but for now, use those nested for loops, brute force your solutions and make shit work! worry about optimization later. that is the way the real world works. nobody cares how optimized your code is if it doesn't work in the first place