What’s up beautiful people
Welcome to another edition Sloth Bytes. I hope you’re getting 8 hours of sleep.

ChatGPT gives you generic answers because you give it generic prompts.
You know the fix: longer prompts, more context, clearer constraints. But typing all that takes five minutes per prompt, so you shortcut it. Every time.
Wispr Flow lets you speak your prompts instead of typing them. Talk through your thinking naturally — include context, constraints, examples — and get clean text ready to paste. No filler words. No cleanup.
Works inside ChatGPT, Claude, Cursor, Windsurf, and every other AI tool. System-level, so there's nothing to install per app. Tap and talk.
Millions of users worldwide. Teams at OpenAI, Vercel, and Clay use Flow daily. Free on Mac, Windows, and iPhone.
200+ Proven Ways to Make Money With AI in 2026
The next wave of millionaires will be people who figured out how to make AI work for them.
The window to get ahead is still open. But not for long.
Here are 200+ proven ways to make money with AI in 2026.
Sign up for Superhuman AI, the free daily newsletter read by 1M+ professionals, and get instant access to all 200+ ways to profit from AI this year.

Binary Search Is Everywhere and Nobody Told You

Binary search is a classic algorithm. Pretty much the introduction to algorithms.
It’s pretty straight forward:
Start with data that is already sorted by the key you care about.
Check the middle element.
If the target is smaller, discard the right half.
If the target is larger, discard the left half.
Repeat until you find the target or the search range is empty.
def binary_search(arr, target):
left, right = 0, len(arr) - 1
while left <= right:
mid = left + (right - left) // 2
if arr[mid] == target:
return mid
elif arr[mid] < target:
left = mid + 1 # target is in the right half
else:
right = mid - 1 # target is in the left half
return -1 # not foundImportant: binary search is O(log n) when the data is already sorted (or represented by an ordered structure). If you take an arbitrary unsorted list, sort it first, and only perform one search, the sort usually costs O(n log n)—more than the search itself. Binary search shines when the ordering already exists or you reuse it across many lookups.
Cool. But why should you care?
Let me actually show you.
Binary search is FAST.
Every step in binary search cuts the remaining problem in half. Which means the performance is BLAZINGLY FAST.
Searching 1,000 items → takes 10 steps max
Searching 1,000,000 items → takes 20 steps max
Searching 1,000,000,000 → takes 30 steps max
Isn’t that crazy? A billion items takes a maximum 30 checks.
Because of this, binary search has a time complexity of O(log n).
Where Binary Search is used
Let me give you 2 practical examples.
Many relational databases use balanced tree indexes—commonly B-tree/B+ tree variants—to keep keys ordered and make lookups efficient. Instead of scanning every table row, the engine can traverse a small number of tree pages to narrow down the key range.
Sound familiar?
This is related to the same ordered-search idea as binary search, but it is not literally binary search on a flat array. A B-tree node can have many children, which is especially useful for databases because each node is sized to work efficiently with storage/cache pages.
The result is still logarithmic-style lookup behavior as the index grows, but the branching factor is much larger than two. Databases also have to consider page reads, selectivity, covering indexes, query planning, and whether using the index is actually cheaper than a scan.
-- Without a useful index, the database may scan many/all rows.
SELECT * FROM users WHERE email = '[email protected]';
-- A B-tree-style index can make selective equality/range lookups much cheaper.
CREATE INDEX idx_users_email ON users(email);
SELECT * FROM users WHERE email = '[email protected]';
-- The query planner still decides whether using the index is worthwhile.So when someone says an index can make a lookup faster, binary search is a useful stepping-stone mental model—but real database indexes are optimized tree structures with their own tradeoffs.
You were vibe coding too hard and now you have a serious bug. You have no idea when it appeared because your AI made 500 commits.
The obvious move is to start checking before the 500 commits and go one by one until you find where things broke, but that would take forever.
Instead you’d use git bisect. It’s a built-in Git command that does this for you.
git bisect start
git bisect bad # current commit is broken
git bisect good v2.1.0 # this older commit was fine
# git checks out the middle commit automatically
# test it, then run either:
git bisect good # bug isn't here
git bisect bad # bug is here
# ~9 steps later, git tells you the exact commit that broke everything
git bisect reset # clean up when doneYou give it two reference points:
A "bad" commit where the bug exists
A "good" commit where everything still worked.
Git then checks out a commit right in the middle of those two points and asks you: good or bad? You test it, answer, and Git cuts the remaining range in half again. Repeat until it lands on the exact commit that broke everything.
The interview section (don't skip this)
Most people don’t realize a problem needs binary search. They think it only applies to "find X in a sorted array." But there’s actually other situations where it’s the best approach.
Let me show you how to recognize the pattern.
Signal #1: The problem involves a sorted array (or sortable data)
Example interview problems:
This is the most obvious signal. If the input is sorted and you're searching for something, binary search should be your first thought.
Signal #2: The problem asks you to find a boundary
Example interview problems:
The problem doesn't say "search." It says "find the first one where X is true." That's a boundary search in disguise because you’re searching for the point where something changes.
# Find first index where arr[i] >= target (left boundary)
def find_left_boundary(arr, target):
left, right = 0, len(arr)
while left < right:
mid = left + (right - left) // 2
if arr[mid] < target:
left = mid + 1
else:
right = mid # keep going left to find the first one
return leftSignal #3: The problem says "find the minimum/maximum value that satisfies X"
Example Interview Problems:
This one trips people up the most because there's no array to search at all. You're searching a range of possible answers.
Usually it’ll be in the form of “find the minimum/maximum such that condition X holds"
This is an most important interview pattern. Once you see it, you can't unsee it.
Signal #4: The array is sorted but rotated
Example Interview Problem:
[4, 5, 6, 7, 0, 1, 2] looks broken, but with distinct values at least one side around the midpoint is sorted, which lets you decide which half can still contain the target. Duplicate-heavy variants need extra handling and can degrade toward O(n) in the worst case.
def search_rotated(arr, target):
left, right = 0, len(arr) - 1
while left <= right:
mid = left + (right - left) // 2
if arr[mid] == target:
return mid
# left half is sorted
if arr[left] <= arr[mid]:
if arr[left] <= target < arr[mid]:
right = mid - 1
else:
left = mid + 1
# right half is sorted
else:
if arr[mid] < target <= arr[right]:
left = mid + 1
else:
right = mid - 1
return -1With distinct values, the ordering tells you which half cannot contain the target, so you can discard it and preserve the O(log n) search pattern.
Signal #5: The interviewer basically says you can do better
If you come up with an O(n) solution and the interviewer smiles and says "can you optimize that?"
That means there may be a better structure or algorithm—but it is not automatically a binary-search hint. Hashing, two pointers, dynamic programming, heaps, prefix sums, better data structures, or a different invariant might be the real answer.
Binary search becomes a strong candidate when you can identify a monotonic predicate: as the candidate value increases (or decreases), the answer to a yes/no feasibility question changes at most once. That is what makes “binary search on the answer” work.
An easy checklist for interview problems
When looking at the question, ask yourself:
Is the data already sorted or stored in an ordered structure?
Am I looking for a first/last position where a monotonic condition changes?
Is there a numeric/searchable answer range with a monotonic feasibility test?
Can I discard half of the remaining candidates without losing a possible answer?
If those properties hold, binary search is worth considering. If they do not, forcing binary search because the interviewer raised an eyebrow is how bugs are born.
The sneaky bug even the experts missed
Jon Bentley (very smart programmer) once assigned binary search to a room of professional programmers.
The most common mistake every programmer made was finding the middle point:
# Looks fine, but there's a secret issue here.
mid = (left + right) // 2In Python you're safe if you do this, but in Java or C, if left and right are both large numbers, adding them together overflows the max integer value, flips negative, and gives you an index that doesn't exist.
The safe way to calculate the middle is like this:
# Overflow-safe midpoint pattern in fixed-width integer languages.
# Python integers do not overflow here, but this pattern is still portable.
mid = left + (right - left) // 2For you Java and C nerds:
int mid = low + (high - low) / 2; // Javaint mid = low + (high - low) / 2; // C/C++, assuming low <= high and valid boundsThe overflow bug is historically famous because the naive midpoint expression can overflow fixed-width signed integers when the bounds are very large. The subtraction-first form avoids that problem under the normal binary-search invariant that low <= high.
It lived in Java's standard library for nine years and was only found because someone's program actually broke
Bentley's own book “Programming Pearls” had it.
If you want to keep learning
Data structures and algorithms explained — the bigger picture behind search algorithms, data organization, and performance.
Big O notation explained — understand exactly why cutting the search space in half gives binary search O(log n) performance.
How Google Maps finds the fastest route — another real-world look at algorithms doing useful work instead of just terrorizing interview candidates.

Let me know your thoughts on this topic
I’ve always felt that data structures and algorithms have a reputation problem.
Every resource that teaches them frames it the same way:
Here's the theory, here's the runtime, and memorize it for your interview.
That's it. No context and no reason to care. So you start to hate the topic because you feel like “you’ll never use this in real life.” So I want to try teaching it in a way that prepares you while also giving you an actual reason/idea on where it’s used.
Let me know if you liked it or if you just want the normal style of teaching.
Anyways, that’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.




