Big O is just answering one question. As your input grows, how does the work grow?

Imagine your code is a machine. You feed it an input of size n. Maybe n is the length of an array, the number of users, the size of a string. Big O describes the shape of the curve you'd draw if you plotted "amount of work done" against "size of input". It throws away constants and small terms because we only care about what happens when n gets huge.

O(1), constant. The work doesn't depend on n at all. Looking up arr[5] takes the same time whether the array has 10 elements or 10 million. You walk into a room, grab the thing nearest the door and leave.

int x = arr[0];   // O(1)
return x + 1;     // O(1)

O(log n), logarithmic. Each step throws away half the remaining work. Binary search is the classic. If n doubles, you do one extra step. n = 1000, you do about 10 steps. n = 1,000,000, you do about 20. Logarithms grow painfully slowly, which is why we love them.

while (n > 1) {
    n = n / 2;     // halving each time, log n iterations
}

The signature is division by a constant factor inside the loop. Halving, thirding, whatever. Cut the problem down by a fixed fraction each step and you're in log n territory.

O(n), linear. You touch every element once. n doubles, work doubles.

for (int i = 0; i < n; i++) {
    System.out.println(arr[i]);
}

O(n log n). This is what good sorting algorithms do. Mergesort, heapsort, the sort Java actually uses. The pattern is "do n work, log n times" or "do log n work, n times". You see it whenever you split something in half repeatedly and do linear work at each level.

O(n²), quadratic. Two nested loops, each going up to n. The dead giveaway.

for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
        // something O(1) here
    }
}

n = 10 means 100 operations. n = 1000 means a million. n = 1,000,000 means a trillion and your laptop is on fire.

O(2\^n), exponential. Each step branches into two. Naive recursion for Fibonacci does this. n = 30 is fine. n = 60 outlives the universe.

O(n!), factorial. Trying every permutation. Travelling salesman by brute force. n = 12 is already painful.

Walk through the code asking one question at every line. How many times does this run, as a function of n?

Single statement, runs once, O(1). A loop from 0 to n, O(n). A loop nested inside another loop, both going to n, O(n) times O(n) = O(n²). A loop where the counter halves or doubles, O(log n). A loop from 0 to n with a halving loop inside it, O(n) times O(log n) = O(n log n).

Then add the pieces together and keep only the biggest.

void mystery(int[] arr) {
    int n = arr.length;

    System.out.println("hi");        // O(1)

    for (int i = 0; i < n; i++) {    // O(n)
        System.out.println(arr[i]);
    }

    for (int i = 0; i < n; i++) {    // O(n²)
        for (int j = 0; j < n; j++) {
            // do something
        }
    }
}

Total: O(1) + O(n) + O(n²) = O(n²). Which leads me to the two rules you already worked out, both correct.

So O(n²) + O(n) + O(1) collapses to O(n²). When n is huge, n² dwarfs the rest. At n = 1,000,000, n² is a trillion and n is just a million. Adding a million to a trillion changes nothing meaningful. Big O cares about the dominant term and ignores the rest.

Stacking the same complexity doesn't change the class. Three separate O(n) loops one after another do 3n work total, but Big O drops constants. 3n is still O(n). Same reason O(n/2) is just O(n) and O(100n) is just O(n). Constants don't survive.

The reason for both rules is that Big O is an asymptotic statement. It describes behaviour in the limit as n goes to infinity. Constants and smaller terms get swamped at infinity, so we throw them away.

Once you've done this enough, you stop deriving and start pattern-matching.

One loop over the input, O(n). Two nested loops over the input, O(n²). Halving or doubling inside a loop, log n shows up. Recursion that splits the input in half and recurses on both halves, O(n log n) usually. Recursion that branches into two calls on input of size n minus 1, O(2\^n).

A useful sanity check. Plug in n = 10 and n = 100. Count operations roughly.

O(n) goes from 10 to 100. Tenfold. O(n²) goes from 100 to 10,000. Hundredfold. O(log n) goes from about 3 to about 7. Barely moves. O(2\^n) goes from 1,024 to a number with 30 digits. Catastrophic.

If your timing roughly matches one of these jumps when you increase n tenfold, you've identified the complexity empirically.

Memory complexity is the same idea but for space instead of time. How much extra storage does the algorithm need as n grows? An algorithm that creates a copy of the input array is O(n) space. One that builds an n by n grid is O(n²) space. One that just uses a few variables regardless of input size is O(1) space.

Time and space complexity are independent. An algorithm can be fast in time and greedy in space, or slow in time and frugal in space. You analyse them separately, using the same rules.

Don't worry about the math feeling slippery at first. It clicks once you've stared at a few dozen loops and asked "how many times does this run".