How to work on algorithms using JS

I went through basic javascript section once ,stuck at record collection and profile lookup and decided to cover the very basic syntaxes from MDN javascript ,I have knowledge about basic blocks in js and I am going through Codewars but still I am getting the logic of how to work on js algorithms,any tips.Title may not be related to the topic

1 Like

There are no js algorithms. That’s the first thing to get out of your head. None. Not a one. There are algorithms.

The whole purpose of an algorithm is, it is a way of expressing a pattern, or a logical construct. The only language that should be applied to an “algorithm” is your own. Your own words, expressing logic in a series of steps that make sense to you.

I have suggested before, when faced with a tough challenge (and the record collection, and profile lookup are the beginning of tough challenges), that you step away from the computer. Get comfortable with a notepad and pencil. Write some pseudocode.

In each lesson, you have the long text bit on the left upper side of the screen. It tells you most of what you need for the current lesson, but it isn’t always in words that make sense to me. I rewrite the purpose of the lesson in my own words (I synthesize the lesson). Doing this, I can start to picture what I want for the end result. So, the Record Collection lesson:

I need to write a function that takes an album id and updates some value on that album. The options for updates include setting a property, deleting a property, or adding a track to the array of tracks.

That’s the whole thing, condensed into my own words. No code, nothing more code-y than the word array in that. So its something I could tell to a seven year old, and it should make sense.

Next, break it down. Start building logic. This is where the pseudo-code starts. Again, NO javascript, unless that is how you think. Write the tasks in a language that is native to YOUR brain. So maybe a first pass might look like this:

function updateRecords(id, prop, value){
 * So we get three things with our function:
 *  - id: the album id
 * - prop: the name of the property we want to change
 * - value: what we want to set it to.
 * First, I probably ought to find a record that matches
 *  that id. If we have one, I work with it. If we DON'T,
 *  I return an error message and quit the function.
 * From here on, we're assuming we have a valid album.
 *  So second, let's deal with something that happens to ALL
 *  properties - if the value is empty, we just delete the property.
 *  doesn't matter if the album HAS that property, we just delete
 *  anyway. And, at that point, we can quit our function and
 *  send back the entire collection.
 * Third, we have two different types of properties. Let's deal with
 *  the 'tracks' property first, as that is the only "unique" case. So if the
 *  property is 'tracks' (and at this point, value CAN'T be empty), we either
 *  create the 'tracks' array if it doesn't exist, and then (whether it exists
 *  or not) we add the value to that array. And again, quit and return the
 *  collection.
 * At this point, we only have one more case to handle: any other 
 *  property. By this point, we've handled all the delete cases, so we know
 *  we have a value. And we've got rid of the tracks case, so we have a 
 *  plain old property going on. So now, we just set the property on this 
 *  particular object to our given value. And return the collection.

Each of those cases are pretty descriptive, and they tell me pretty well what I need to do at each step. That is the pseudocode, and that defines the algorithm for this particular challenge.

Tricks to writing a solid algorithm?

  1. Handle all your error cases first: By eliminating the case where we’re given an ID that isn’t in the collection, we know that we have a valid album for the rest of the function.
  2. At this point, we see if there are any “universal” rules that apply. In this case, there are – if we have an empty value, we delete the property. That happens for EVERY property, including tracks, so global rules should be handled after the errors, but before everything else.
  3. Now we handle any “special cases”. Is there something that has unique processing? That gets handled third. In this case, we have the tracks property. That has to be handled separately from every other property, so we eliminate it now. Within the handling of it, inside this step, is where we handle the "tracks array doesn’t exist" situation.
  4. Last, having taken care of all errors, general cases, and specialized cases, we have the “everything else” stuff. Everything else simply means (in this case) “set the property prop to the value value.” Boom done.

There is a pattern, and a flow. And honestly, it takes a LOT of time and practice. Keep a notepad handy, and write out algorithms. We use them all the time – when you’re cleaning your home, there’s an algorithm to it (or you end up doing a very disorganized cleaning). It is simply about formalizing and recognizing them.


Wow. Wish I could hit the :heart: button more than once, because that is exactly how to think as a programmer. Well said.

1 Like

Rofl Too too too many years as a programmer. I occasionally brain dump, but I worry that it comes across as a rant. It truly is not, it’s simply sharing the way I think.

Biggest lesson I think up and coming coders need to learn is “logic before language”. The pattern we use for the above code would work just as well in PHP, or perl, or node, or FORTRAN. Once the pattern is in place, the language is just… mechanicals.

I would argue that there’s language-specific algorithms too, or more specifically paradigm specific ones. The algorithm you write in Haskell is going to be pretty different than the one in PHP after all. Still, data is data, so there’s still a pretty universal mindset to adopt of thinking logically and breaking problems down into smaller units.

1 Like

Haven’t played in Haskell yet. Maybe later this spring.

Finally understand why in company algorithms already set for, you only need to copy and paste…lol