Together with
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:
Gotta find a target in a list?
Sort the list
Check the middle
If the target is less than the middle, ignore the right side and go left
If the target is greater than the middle, ignore the left side, go right
Repeat.
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 foundCool. 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.
When you add an index to a column, the database builds a sorted structure behind the scenes. Then when you query it, instead of scanning every row, it uses that sorted order to eliminate half the remaining rows at each step.
Sound familiar?
The actual implementation is called a B-tree. It's like binary search's more practical cousin.
Instead of a flat sorted array, the data lives in a tree that stays balanced as rows get inserted and deleted. But the core idea is identical: sorted data, eliminate half, repeat, find your answer in O(log n) instead of scanning everything.
-- No index: scans every row. Gets slower as your table grows.
SELECT * FROM users WHERE email = '[email protected]';
-- With index: sorted lookup. Fast at 100 rows or 10 million.
CREATE INDEX idx_users_email ON users(email);
SELECT * FROM users WHERE email = '[email protected]';You've probably added indexes before. Maybe someone told you "it makes queries faster." Well that’s because you were basically using binary search on that column.
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 at least one half is always sorted. Use that to decide which side to search.
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 -1if your target isn't in the sorted half, there's zero reason to ever look in that half again. You just eliminated half the array for free. That's binary search doing its thing even when the array looks broken.
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's almost always a hint that a log n solution exists or they’re playing tricks with you.
If the data is sorted or the problem has a monotonic structure (always gets bigger or always gets smaller as you increase the input), binary search is the optimized answer.
An easy checklist for interview problems
When looking at the question, ask yourself:
Is the data sorted (or can it be)?
Am I looking for where something changes, not just a specific value?
Is there a range of possible answers I could search instead?
If any of these are yes, think binary search first.
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:
# Safe version. Always use this.
mid = left + (right - left) // 2For you Java and C nerds:
int mid = (low + high) >>> 1; // Javamid = ((unsigned int)low + (unsigned int)high)) >> 1; // C and C++This exact bug existed for a long time.
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.
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.
