In All Things, Make Thyself Simplicity

    So goes the saying above, which I've heard for most of my life and yet currently can't find an author it's attributed to. Marcus Aurelius? Paul the Apostle? Brilliant 21st century writer Max "Edison" Engel-Streich? The world may never know for sure.
    But, as it does with "all things," the above rings true for coding as well. As a thinker (and speaker, and writer, and communicator, and texter, and blogger, and journal keeper...the list goes on) it's commonly tempting for me to really hammer a point home by over-explaining it, and then re-explaining it (just in case I missed something the first time). So it was no surprise to me when I forced myself to stop for a moment and re-evaluate how much extra syntax I was putting into my code.

Take the below problem:
// Our task is to print:

    // - "AA" if marks is greater than 90.
    // - "AB" if marks is greater than 80 and less than or equal to 90.
    // - "BB" if marks is greater than 70 and less than or equal to 80.
    // - "BC" if marks is greater than 60 and less than or equal to 70.
    // - "CC" if marks is greater than 50 and less than or equal to 60.
    // - "CD" if marks is greater than 40 and less than or equal to 50.
    // - "DD" if marks is greater than 30 and less than or equal to 40.
    // - "FF" if marks is less than or equal to 30.

    // 🚨 Format your if...else if...else conditional below

(all credit and copyright and glory to FlatIron School).

    My initial thought was how important it would be to make use of javascript's built in function to accept two parameters which both need to be true - ie "&&." On second thought, I realized, that would be redundant. Two important things to consider:
(1) That the code is read from left to right, and top to bottom.
(2) Practical mathematics.
(3) Built in operational efficiency.
    Here's what I mean:
(1) The code will inherently read and analyze the first line first - if the input is higher than 90 - and then the second line second - if  the input is higher than 80.
(2) A number that is lower than 90 inherently fails the first if statement. If it is higher than 80 it inherently passes the second statement - and is inherently lower than 90.
(3) Thanks to the functionality of javascript, once a condition is met, the loop automatically exits. Even though a number that is higher than 80 is also inherently higher than 70, 60, etc, the code will automatically only fulfill the first condition that is true, and then exit the loop. As such, I decided to lean in to "simplicity" and leave the second condition out of the parameters list. My resulting code looked as follows:

if (marks > 90) {
    console.log("AA");
        } else if (marks > 80) {
            console.log("AB"){
                }else if (marks >70){
                    console.log("BB")
                        }else if (marks > 60){
                            console.log("BC")
                                }else if (marks > 50){
                                    console.log("CC")
                                        }else if (marks > 40){
                                            console.log("CD")
                                                }else if (marks > 30){
                                                    console.log("DD")
                                                        }else {
                                                            console.log("FF")
                                                                }

(Cascade added for readability/visual effect).

    The above code works! Just fine! It also got me thinking - if it was written "backwards" (testing for lowest value first, up to highest), then the second parameter, and the use of "&&" would absolutely be necessary. It would absolutely need to iterate through every stage of the loop looking for the correct range - otherwise the same value that should earn a grade of "AB" would automatically exit the code at "DD."

    Turns out, if statements aren't the only place that javascript wants me to use less text. Check out how I initially approached a "default variable":

function saturdayFun(soundsFun){

    if (soundsFun === undefined){

        soundsFun = "roller-skate"

    }

    return "This Saturday, I want to " + soundsFun + "!";

}
    That whole extra if statement is totally unnecessary. It should read like this:

function saturdayFun(soundsFun = "roller-skate"){

    return "This Saturday, I want to " + soundsFun + "!";

    I literally gave myself a face-palm when I learned how simple default variables are meant to be. But at least now I know for next time.

    I get the sense that the examples of places where javascript wants to do the heavy lifting for us run deep. Think about all the array functions (like .map() and .reduce()) that automatically iterate through each element for us. All of which feels like a simultaneous "big relief" and "rabbit hole of exploration I could wind up going down instead of actually sitting down and writing the code in a way that I already know would work even if the amount of text becomes slightly redundant." Which, I suppose, is the other end of the spectrum.
    In a lot of what I do (talking, texting, journaling) I have a tendency to over-communicate. Just  to make sure the other person definitely understands me. I have a feeling coding will be the same type of journey for me ("Will the program really execute this properly? What about x, y or z?"). One of the instructors at FlatIron School saw some of my coding redundancies, and paid them no heed. "First make it functional, then make it sexy," he pointed out. Truly wise words. Sounds like maybe I'm not the first person who went into coding with a tendency to overcommunicate, nor would I be the first person with a tendency to over-correct.
    Seems like the learning journey ahead could be a long one. Glad to know that javascript wants to at least help me with some of the heavy lifting along the way.