Algorithms: Will Your Code Survive More Users?
Big O, binary search, and recursion explained as practical tools for predicting how code behaves as data grows.
An algorithm is a procedure for solving a problem.
That sounds abstract, so use a kitchen metaphor: an algorithm is a recipe. The same dish can be made with a messy recipe or a clean one. Both may work for one person. Only one survives a restaurant rush.
In real software, the important question is not, "Can this code pass a coding interview?"
The useful question is:
What happens when the data grows?
Big O: predicting future pain
Big O notation describes how work grows as input grows.
If you have 10 items, almost anything feels fast. If you have 1,000,000 items, the growth pattern matters.
One direct lookup. Size barely matters.
Cut the search space in half repeatedly.
Look at each item once.
Common for practical sorting algorithms.
Compare every item with every other item.
What 1,000 items means
| Complexity | Everyday analogy | Rough work at 1,000 items | Example |
|---|---|---|---|
| O(1) | Open a locker by exact label | 1 | Hash map lookup |
| O(log n) | Open a dictionary near the middle, then narrow | 10 | Binary search |
| O(n) | Check every person in a line | 1,000 | Scan an array |
| O(n log n) | Sort cards efficiently | 10,000 | Merge sort / quicksort |
| O(n²) | Compare every person to every person | 1,000,000 | Nested loops over the same list |
O(n²) is not scary because the symbol looks mathematical. It is scary because 10x more data can mean 100x more work.
Binary search: the elegant dictionary trick
Imagine looking for the word "octopus" in a paper dictionary.
You would not start at page one. You would open near the middle, decide whether "octopus" is before or after that page, then cut the remaining pages in half again.
That is binary search.
It only works when the data is sorted. But when it works, it is powerful because each step cuts the problem in half.
Binary search appears in:
- Finding an item in sorted data.
- Searching time ranges.
- Guessing a threshold.
- Optimizing "what is the smallest value that still works?" questions.
Recursion: a problem inside the same problem
Recursion is when a function calls itself.
The friendly metaphor is a set of nesting dolls. Open one doll and there is a smaller version inside. Open that one and the same pattern continues until the smallest doll stops the process.
Recursion is useful when the data has the same shape repeated inside itself:
- Folders inside folders.
- Comments with replies.
- Menus with submenus.
- Organization charts.
- Tree traversal.
The key is the stopping condition. Without it, recursion keeps opening dolls forever.
What builders actually need
You do not need to memorize every algorithm before building products.
You do need to recognize these patterns:
- Direct lookup is usually better than repeated scanning.
- Sorting once can make repeated searching faster.
- Nested loops over growing data deserve suspicion.
- Recursion is natural for trees and nested structures.
- Measuring is better than guessing.
How this appears in AI-built apps
AI often writes code that is correct for the sample data in the prompt. That sample data is usually tiny.
Watch for:
-
Repeated full scans Rescanning the entire list, table, or documents whenever data changes.
-
Nested loops Comparing every user with every post, or every document with every other document.
-
Slow lookups Using
array.find()for ID lookups instead ofMap,Set, or database indexes. -
Unnecessary full sorts Sorting the entire dataset when you only need the top 10.
-
Missing pagination Fetching every record at once when only a subset will be shown.
-
Missing database indexes Running queries for search, sorting, date filters, or status filters without indexes.
-
N+1 queries Fetching a list, then sending a separate database query for each row.
-
Excessive browser-side processing Loading all data from the database and filtering it in the browser.
-
Expensive work on every render Recomputing groupBy, chart data, markdown parsing, or date formatting on every render.
-
Event flooding Running computations or API calls on every keystroke, scroll, or resize without debounce or throttle.
-
Missing cache or memoization Recomputing the same result, API response, AI output, or embedding every time.
-
Missing batch or parallel processing Handling multiple API calls, AI calls, image processing, or email classification one by one.
-
Long work without a queue Running PDF analysis, bulk exports, AI analysis, or file processing inside a request-response cycle.
-
Inefficient AI / RAG Stuffing every document into the prompt, regenerating embeddings every time, or using search results without ranking or top-k filtering.
-
No streaming for large data Loading large CSV, JSON, image, log, or export files entirely into memory.
Frequently asked questions
What is Big O notation?
Big O notation describes how much work an algorithm does as the input grows. It helps you predict whether code that feels fast with ten items will collapse with a million.
What is binary search used for?
Binary search finds an item in sorted data by repeatedly cutting the search range in half. It is much faster than scanning every item when the dataset is large.
When should I worry about algorithm performance?
Worry when you see nested loops over growing data, repeated full scans, or operations that must run for every user, record, or document. Small datasets usually hide these problems.
What is recursion good for?
Recursion is good for problems that contain smaller versions of themselves, such as folders inside folders, comments with replies, or tree traversal.
How do I spot a slow algorithm in AI-generated code?
Look for array.find inside loops, repeated filtering on every keystroke, comparing every item with every other item, and loading all records into the browser before filtering.
The takeaway
Algorithms are not puzzle tricks. They are how you predict whether today's working demo becomes tomorrow's slow product.
The goal is not to know every solution. The goal is to notice when growth changes the problem.
About the Author

Jaehee Song
Enterprise data platform architect with 20+ years of experience building data systems for Fortune 500 companies. AI development educator who has taught vibe coding and AI development to hundreds of students. Founder of Seattle Partners, helping Korean technology startups navigate the US market.