🧭 Conceptual Foundation & Pattern Intuition

Two pointers moving through the same array, one always at or behind the other, is the foundational shape of this entire pattern — worth slowing down on before it becomes muscle memory.

🧹 The Analogy: A Librarian Re-Shelving Duplicates

Picture a librarian walking down a single shelf of books already sorted alphabetically, holding a "next open slot" marker (writer) in one hand. They scan forward with their eyes (reader), one book at a time. Whenever they spot a book different from the last one they kept, they physically slide it back into the open slot and advance the marker. Duplicate books get scanned past and simply never get a slot — they're silently overwritten by whatever comes after them.

🔑 The Key Idea in the Code

Because the shelf is already sorted, every duplicate of a book sits immediately next to it — so "is this different from the last book I kept?" is a complete duplicate check, with no need to remember anything beyond the single most recent kept value.

🤔 Common Point of Confusion: Why writer - 1 Instead of reader - 1?

Comprehending the comparison on the first iteration can feel unnatural: we are comparing index 1 with index 0, and writer - 1 forces you to juggle two moving boundaries at once.

Since the array is sorted, duplicates are always adjacent, so you could also write:

# The "Compare with Previous" Approach:
if nums[reader] != nums[reader - 1]:
    nums[writer] = nums[reader]
    writer += 1
 

Why this feels intuitive:

• Separation of Concerns: The reader is solely responsible for discovering new unique elements by checking the card it just held (reader - 1). The writer strictly acts as the "next open slot" marker.
• Mental Model: Like flipping through a deck of sorted cards, you just ask: "Is this card different from the card in my hand one second ago?"

🏛️ Architectural Insight: Which Version Is Canonically "Correct" and Why?

While nums[reader] != nums[reader - 1] is convenient for LC 26, nums[reader] != nums[writer - 1] is the canonically correct, architecturally superior version for the general pattern:

1. Trust the "Kept" Data, Not the "Raw" Data: The core invariant of compaction is that the prefix nums[0..writer-1] represents your finalized, verified, processed data (the "Kept-Prefix Boundary"). The right side (nums[reader..]) is untrusted, raw input. When deciding whether to keep an element, you should compare against the last element you actually decided to keep (writer - 1), not just whatever you looked at a moment ago.

2. Generalizability to Harder Problems (The Main Advantage): Comparing against writer allows you to solve advanced variants with almost zero code changes. Consider LC 80 (Remove Duplicates II), where you can keep at most 2 duplicates (or generally at most $k$ duplicates).

• With reader - 1, you need messy state flags and counters to track consecutive duplicate counts.
• With the writer pattern, the code remains identical—you simply look $k$ slots back in your trusted data:

def removeDuplicatesTwice(nums: list[int]) -> int:
    if len(nums) <= 2:
        return len(nums)
    writer = 2
    for reader in range(2, len(nums)):
        # Is this number different from what I kept TWO slots ago?
        if nums[reader] != nums[writer - 2]:
            nums[writer] = nums[reader]
            writer += 1
    return writer