One of the things that many college professors will preach and that many programmers will ignore, at least in my case, is that you should modularize your code as much as humanly possible down to the line almost. Separate your concerns if you will. This is something that took me some years to get used to and to learn the importance of. For the most part I lumped together all logic into one container and hoped that I'd never have to look at it again. But of course that never happened. I'd have to look at it months later when that memory had all but faded away, and I'd have to battle my way through a field of random comments and single character variables.

Think of it like this. If you looked at a human eye from afar, you'd see all kinds of complexity that we could never understand. But now break the eye up into its many different functions. Break it up from the ground up. From the light hitting it, to your brain flipping the image upside down. Now things start to make more sense.

Separate those concerns

A function like this isn't very uncommon in our programming ethos.

function checkout()
{
    var i = 34;
    var temp = 0;
    for(var x = 12; x < 2 * 10^3; x++)
    {
        temp = x + y; // error probably
    }

    for(var y = 0; i < x; y++)
    {
        result += y + temp;
    }

    while (forever)
    {
        i = 0;
    }
}

Look at any code that was written over a year ago and it'll probably look something that like. But even this simple made up example can turn into something like the following:

function checkout()
{
    createUser();
    createOrder();
    createTransaction();
}

Each one of those functions could be a total mess on the inside, but at least now they make sense together. And those internal functions will more than likely also need to be broken down. Think of it as a tree of functions, with each parent sending "nutrients" to its child branches. All interconnected and communicating from the tip of the last branch all the way back up to the source.

Benefits

The obvious benefit is that your code will make more sense. And who couldn't use more of that. Having 3 or 4 for loops in a function with varying degrees of x, y and z variables doesn't leave much to the imagination. But having 4 well named functions performing the same will have any future person working on your code thanking you. And a future you, thanking you as well.

Another benefit is that instead of 1 giant problem later on that you'll have to wade through, you'll end up with 1 or 2 tiny problems that make sense to fix. You'll be able to reuse variable names where they make sense and will avoid things like:

var counter1 = 0;
var counter 2 = 0;
var countera= 9;
etc

Thinking differently

I'll say now, that this takes practice and patience. The first time you'll end up with 2 or 3 functions out of 1 giant one. But eventually, you will indeed end up with 10 or even 15 functions for that original one. Your functions will need to cascade down in a way that they make sense. Variables will need to be returned and passed into other functions. Things will have to click and fit in the right places. Much like the beloved Tetris block and that sweet sweet feeling when you're one line block away from clearing everything out.

What's in the box?!

And for that you will have to think differently. More modular. As I mentioned, things will need to fit into other things. Most functions will rely on data from previous functions. So you'll need to package your data more carefully.

Package your data

Classes are amazing, and serve a purpose much higher than your typical Boat inherits from Vehicle example that we learn in school. If you're ever passing too many variables into a function, to the point where it's breaking into a new line, then you need to package your data. And classes are perfect for that.

The beauty of classes is that they are almost always returned by reference, which means that you can pass a shell into your child functions, and by the time it comes back, it will be filled with that sweet data. You can then pass that object into another object and so on and so forth. And that's how code really works. It's this alive and constantly changing tree of connections feeding data around until the result comes out.

Where it can go wrong

If you've ever gotten too many zig zag Tetris blocks sequentially within 3 turns, then you will know where I'm going with this. You could turn 1 big complex function into 10 even more complex functions. You could end up with data where it doesn't belong, confusing you later on, or worse, you could end up missing data where you may need it.

And that's why I mentioned that this takes practice and patience. In time you will begin to see the big picture and it will impossible to think in any way other than this. So next time you encounter something that's seemingly complex to the naked eye, just remember that it can probably be brought to down to 5 or 6 incredibly simple processes that will make sense.