{"id":2265,"date":"2024-10-15T21:46:52","date_gmt":"2024-10-15T21:46:52","guid":{"rendered":"https:\/\/algocademy.com\/blog\/why-algorithmic-thinking-is-like-cooking-follow-a-recipe-then-experiment\/"},"modified":"2026-10-15T10:34:50","modified_gmt":"2026-10-15T10:34:50","slug":"why-algorithmic-thinking-is-like-cooking-follow-a-recipe-then-experiment","status":"publish","type":"post","link":"https:\/\/algocademy.com\/blog\/why-algorithmic-thinking-is-like-cooking-follow-a-recipe-then-experiment\/","title":{"rendered":"Algorithmic Thinking Is Like Cooking: Follow a Recipe, Then Experiment"},"content":{"rendered":"

A recipe is an algorithm: a fixed list of steps that turns inputs (ingredients) into an output (a dish). Learning algorithmic thinking follows the same path as learning to cook. You follow the recipe exactly, you work out why each step is there, and only then do you start changing things, one change at a time, tasting after each.<\/p>\n

This post walks through that path with one small problem, finding the largest number in a list, and then shows where the cooking comparison stops being useful.<\/p>\n

Where the comparison holds<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
In the kitchen<\/th>\nIn code<\/th>\n<\/tr>\n<\/thead>\n
Ingredients<\/td>\nInput (the function’s arguments)<\/td>\n<\/tr>\n
The finished dish<\/td>\nOutput (the return value)<\/td>\n<\/tr>\n
Steps, in order<\/td>\nStatements, run top to bottom<\/td>\n<\/tr>\n
“Stir until thick”<\/td>\nA loop with a stopping condition<\/td>\n<\/tr>\n
“If the sauce is too thin, simmer longer”<\/td>\nAn if<\/code> statement<\/td>\n<\/tr>\n
A technique you reuse (making a roux)<\/td>\nA function<\/td>\n<\/tr>\n
Mise en place: chop everything before you start<\/td>\nReading the problem, listing inputs and edge cases before typing<\/td>\n<\/tr>\n
Tasting while you cook<\/td>\nRunning tests and printing intermediate values<\/td>\n<\/tr>\n
Cooking for 2 versus for 200<\/td>\nTime complexity: how the work grows with the input<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

None of this is deep. It is useful because it describes how people actually learn both skills, and it points at the stage where most beginners get stuck: they want to experiment before they can follow the recipe.<\/p>\n

Stage 1: follow the recipe exactly<\/h2>\n

A first-time cook who “improves” a recipe halfway through usually ends up with something inedible and no idea which change caused it. The coding version is copying a solution, changing a few lines you do not understand, and then being unable to say why it fails.<\/p>\n

Here is the recipe for the largest number in a list, written as plain steps:<\/p>\n

    \n
  1. Take the first number and call it best so far<\/em>.<\/li>\n
  2. Look at each remaining number. If it is bigger than best so far<\/em>, it becomes the new best so far<\/em>.<\/li>\n
  3. When the numbers run out, best so far<\/em> is the answer.<\/li>\n<\/ol>\n

    And the same recipe in Python:<\/p>\n

    def find_max(numbers):\n    best = numbers[0]\n    for n in numbers[1:]:\n        if n > best:\n            best = n\n    return best\n\nprint(find_max([3, 9, 2, 9, 4]))   # 9\nprint(find_max([-7, -3, -12]))     # -3\nprint(find_max([5]))               # 5<\/code><\/pre>\n
    Follow it by hand once with [3, 9, 2, 9, 4]<\/code>: best starts at 3, becomes 9 at the second number, stays 9 for the rest. Doing this on paper is the equivalent of cooking along with the recipe open on the counter. Our post on dry-running code with sample test cases<\/a> covers the habit in more detail.<\/p>\n
    Stage 2: find out why each step is there<\/h2>\n
    Good cooks know why you salt the pasta water and why the pan must be hot before the onions go in. For the recipe above, the questions are just as concrete.<\/p>\n
    Why start from the first number and not from 0?<\/strong> Try it:<\/p>\n
    def wrong_max(numbers):\n    best = 0\n    for n in numbers:\n        if n > best:\n            best = n\n    return best\n\nprint(wrong_max([-7, -3, -12]))    # 0, which is not in the list<\/code><\/pre>\n
    Starting at 0 only works if the list contains something at least 0. Starting from an actual element works for every non-empty list. That one detail is the difference between a recipe that works on your kitchen’s stove and one that works on any stove.<\/p>\n
    What happens with an empty list?<\/strong> find_max([])<\/code> raises IndexError: list index out of range<\/code>, because there is no first element to take. The recipe silently assumed at least one ingredient. Decide what you want: raise a clearer error, or return None<\/code>. Either is fine as long as you chose it on purpose.<\/p>\n
    What happens with ties?<\/strong> In [3, 9, 2, 9, 4]<\/code> the 9 appears twice. The ><\/code> comparison keeps the first one. Using >=<\/code> would keep the last one. For plain numbers it makes no difference, but if you were returning the position it would.<\/p>\n
    Stage 3: change one thing at a time<\/h2>\n
    This is the experimenting part, and the rule is the same as in the kitchen: if you change salt, spice and cooking time together, you learn nothing. Change one step, run it, compare.<\/p>\n
    Experiment 1: return the position as well as the value.<\/p>\n
    def find_max_with_index(numbers):\n    if not numbers:\n        raise ValueError(\"find_max_with_index needs at least one number\")\n    best_i = 0\n    for i in range(1, len(numbers)):\n        if numbers[i] > numbers[best_i]:\n            best_i = i\n    return numbers[best_i], best_i\n\nprint(find_max_with_index([3, 9, 2, 9, 4]))   # (9, 1)<\/code><\/pre>\n
    Experiment 2: flip the comparison to get the minimum. Experiment 3: keep the two largest values instead of one. Each is a small variation, and each teaches you what a line of the original was doing. Also try replacing the whole loop with Python’s built-in max()<\/code>. It is shorter and you should use it in real code, but notice that it does the same three steps inside. In an interview, an interviewer who asks you to find the maximum wants to see the loop, not the call.<\/p>\n
    When you invent a variation yourself, like “largest number that is also even”, you are no longer cooking from a recipe. You are writing one. Our post on breaking complex problems into steps<\/a> is about that move.<\/p>\n
    Stage 4: cook for a crowd<\/h2>\n
    A recipe for four people does not simply multiply by fifty. Pots, oven space and timing all change. In code, the question is how the work grows as the input grows.<\/p>\n
    Searching for a value in a sorted list shows this well. Checking every item takes work proportional to the list length. Binary search, which repeatedly looks at the middle and discards half, takes work proportional to the logarithm of the length. Counting the steps on a list of one million even numbers (0, 2, 4, up to 1,999,998):<\/p>\n
    def linear_search(items, target):\n    steps = 0\n    for x in items:\n        steps += 1\n        if x == target:\n            return True, steps\n    return False, steps\n\ndef binary_search(items, target):\n    lo, hi, steps = 0, len(items) - 1, 0\n    while lo <= hi:\n        steps += 1\n        mid = (lo + hi) \/\/ 2\n        if items[mid] == target:\n            return True, steps\n        if items[mid] < target:\n            lo = mid + 1\n        else:\n            hi = mid - 1\n    return False, steps\n\ndata = list(range(0, 2_000_000, 2))\nprint(linear_search(data, 1_999_998))   # (True, 1000000)\nprint(binary_search(data, 1_999_998))   # (True, 20)<\/code><\/pre>\n
    One million steps against twenty. Binary search only works because the list is sorted, which is the algorithmic version of “this technique needs the dough to rest first”. If you want to go deeper, read linear vs binary search<\/a> or time complexity explained<\/a>.<\/p>\n
    Where the comparison breaks<\/h2>\n