All Notes
Code
Code – Recursion
Recursion – Theory
Solving Puzzles - A Developers Pragmatic Approach

Every developer, from junior to principal, is fundamentally a puzzle solver. Whether you’re untangling a gnarly bug, optimizing a performance bottleneck, designing a new system, or tackling an algorithmic challenge, you’re faced with a problem that demands a methodical approach. This post isn’t about specific algorithms; it’s about the universal process of problem-solving itself, illustrated with practical, runnable examples.

Let’s dive into the strategies that separate frantic guessing from effective, systematic solutions.

1. Understand the Problem Deeply

This is the most critical step, often overlooked in the rush to code. Before you write a single line, ensure you fully grasp what’s being asked.

  • Read Carefully: Don’t skim. Pay attention to every word, constraint, and nuance.
  • Clarify Ambiguities: If anything is unclear, ask questions. What are the inputs? What are the expected outputs? What are the edge cases? What are the performance requirements?
  • Restate the Problem: Articulate the problem in your own words. If you can’t, you don’t understand it yet.

Example Scenario: You’re asked to write a function that counts the number of “valid” words in a given sentence.

Initial Thought: “Easy, split by space, count words.” Deep Understanding Questions:

  • What defines a “word”? Alphabetic characters only? Alphanumeric? Hyphens? Apostrophes?
  • What about punctuation? “hello.” - is it “hello” or “hello.”? Should punctuation be stripped?
  • Case sensitivity? “Hello” vs “hello”.
  • Empty string input? String with only spaces?
  • Performance for very long sentences?

Let’s illustrate with a simple Python example: count words containing only alphabetic characters, ignoring case.

import re

def count_alpha_words(sentence: str) -> int:
    """
    Counts words in a sentence that consist only of alphabetic characters.
    Words are separated by spaces. Punctuation attached to words is removed.
    Case-insensitive.
    """
    if not sentence:
        return 0

    # 1. Normalize: convert to lowercase and remove non-alphabetic chars from word boundaries
    #    This regex splits on one or more non-alphanumeric characters.
    #    The `re.split` approach handles multiple spaces and various punctuation naturally.
    words = re.split(r'\W+', sentence.lower())

    count = 0
    for word in words:
        # 2. Validate: check if the word, after stripping, consists only of alphabets.
        #    `isalpha()` is crucial here. Empty strings after split are also handled.
        if word.isalpha():
            count += 1
    return count

# Test cases
print(f"'Hello world!': {count_alpha_words('Hello world!')}")
print(f"'   Python is-awesome!  ': {count_alpha_words('   Python is-awesome!  ')}")
print(f"'123 Go programming!': {count_alpha_words('123 Go programming!')}")
print(f"Empty string: {count_alpha_words('')}")
print(f"'   ': {count_alpha_words('   ')}")
print(f"'A-B-C': {count_alpha_words('A-B-C')}") # A-B-C is treated as three words 'a', 'b', 'c' due to \W+ split
print(f"'Don't stop, can't stop!': {count_alpha_words("Don't stop, can't stop!")}") # 'don', 't', 'stop', 'can', 't', 'stop'
'Hello world!': 2
'   Python is-awesome!  ': 3
'123 Go programming!': 2
Empty string: 0
'   ': 0
'A-B-C': 3
'Don't stop, can't stop!': 6

Note: The re.split(r'\W+', ...) approach simplifies tokenization by splitting on any non-alphanumeric character. If the requirement was “words can contain hyphens/apostrophes but not other punctuation”, the regex and subsequent logic would need to be more complex. The example demonstrates that understanding how to define a “word” is paramount.

2. Break It Down (Divide and Conquer)

Complex problems are rarely solved in one go. Decompose the big problem into smaller, more manageable sub-problems. Solve each sub-problem, then combine the solutions.

Example Scenario: Process a large access log file to find the top 5 most frequent error endpoints.

Big Problem: Find top 5 error endpoints from a large log.

Sub-Problems:

  1. Read the log file line by line efficiently.
  2. Identify lines that represent an error (e.g., HTTP status code 5xx).
  3. Extract the endpoint URL from each error line.
  4. Count the frequency of each extracted endpoint.
  5. Sort the endpoints by frequency and get the top 5.

Let’s use a sample log and Bash/CLI tools to demonstrate:

# Create a dummy log file
cat << EOF > access.log
192.168.1.1 - [10/Oct/2023:10:00:01 +0000] "GET /api/status HTTP/1.1" 200 123
192.168.1.2 - [10/Oct/2023:10:00:02 +0000] "POST /api/data HTTP/1.1" 201 45
192.168.1.3 - [10/Oct/2023:10:00:03 +0000] "GET /api/user/123 HTTP/1.1" 200 78
192.168.1.4 - [10/Oct/2023:10:00:04 +0000] "GET /api/error_endpoint_A HTTP/1.1" 500 22
192.168.1.5 - [10/Oct/2023:10:00:05 +0000] "GET /api/status HTTP/1.1" 200 123
192.168.1.6 - [10/Oct/2023:10:00:06 +0000] "POST /api/error_endpoint_B HTTP/1.1" 502 33
192.168.1.7 - [10/Oct/2023:10:00:07 +0000] "GET /api/user/456 HTTP/1.1" 200 99
192.168.1.8 - [10/Oct/2023:10:00:08 +0000] "GET /api/error_endpoint_A HTTP/1.1" 500 22
192.168.1.9 - [10/Oct/2023:10:00:09 +0000] "DELETE /api/error_endpoint_C HTTP/1.1" 503 15
192.168.1.10 - [10/Oct/2023:10:00:10 +0000] "GET /api/error_endpoint_A HTTP/1.1" 500 22
192.168.1.11 - [10/Oct/2023:10:00:11 +0000] "GET /api/status HTTP/1.1" 200 123
192.168.1.12 - [10/Oct/2023:10:00:12 +0000] "GET /api/error_endpoint_D HTTP/1.1" 504 40
EOF

# Now, execute the sub-problems step-by-step
echo "--- Step 1 & 2: Identify error lines (5xx status) ---"
grep " 50[0-9] " access.log | head -n 3 # Show first 3 error lines
echo

echo "--- Step 3: Extract endpoint URL ---"
# Use awk to parse the part between "GET /" or "POST /" and " HTTP/1.1"
# This regex is simplified; actual log parsing might need more robustness.
grep " 50[0-9] " access.log | awk -F'"' '{print $2}' | awk '{print $2}' | head -n 3
echo

echo "--- Step 4: Count frequency of each endpoint ---"
grep " 50[0-9] " access.log | awk -F'"' '{print $2}' | awk '{print $2}' | sort | uniq -c | head -n 3
echo

echo "--- Step 5: Sort by frequency and get top 5 ---"
grep " 50[0-9] " access.log | \
    awk -F'"' '{print $2}' | \
    awk '{print $2}' | \
    sort | \
    uniq -c | \
    sort -rn | \
    head -n 5
--- Step 1 & 2: Identify error lines (5xx status) ---
192.168.1.4 - [10/Oct/2023:10:00:04 +0000] "GET /api/error_endpoint_A HTTP/1.1" 500 22
192.168.1.6 - [10/Oct/2023:10:00:06 +0000] "POST /api/error_endpoint_B HTTP/1.1" 502 33
192.168.1.8 - [10/Oct/2023:10:00:08 +0000] "GET /api/error_endpoint_A HTTP/1.1" 500 22

--- Step 3: Extract endpoint URL ---
/api/error_endpoint_A
/api/error_endpoint_B
/api/error_endpoint_A

--- Step 4: Count frequency of each endpoint ---
      1 /api/error_endpoint_B
      1 /api/error_endpoint_C
      1 /api/error_endpoint_D

--- Step 5: Sort by frequency and get top 5 ---
      3 /api/error_endpoint_A
      1 /api/error_endpoint_B
      1 /api/error_endpoint_C
      1 /api/error_endpoint_D

By breaking it down, each command in the pipeline addresses a specific sub-problem, making the overall solution clearer and easier to debug.

3. Start Simple / Trivial Cases

Don’t immediately aim for the most complex or generalized solution. Solve the simplest version of the problem first, then gradually add complexity. This builds confidence and provides a baseline for correctness.

  • Smallest Input: What happens with an empty input, or the smallest possible non-empty input?
  • Base Cases: For recursive problems, define the termination conditions.
  • Single Element/Simple Scenario: What if the input array has one element? What if the condition is always true/false?

Example Scenario: Implement a function to calculate the Nth Fibonacci number.

Trivial Cases:

  • fib(0) -> 0
  • fib(1) -> 1
  • fib(2) -> fib(1) + fib(0) -> 1 + 0 = 1
def fibonacci_recursive(n: int) -> int:
    """
    Calculates the Nth Fibonacci number recursively.
    """
    if n < 0:
        raise ValueError("Input cannot be negative.")
    # Base cases
    if n == 0:
        return 0
    if n == 1:
        return 1
    
    # Recursive step
    return fibonacci_recursive(n - 1) + fibonacci_recursive(n - 2)

print(f"fib(0): {fibonacci_recursive(0)}")
print(f"fib(1): {fibonacci_recursive(1)}")
print(f"fib(2): {fibonacci_recursive(2)}")
print(f"fib(7): {fibonacci_recursive(7)}")

try:
    print(f"fib(-1): {fibonacci_recursive(-1)}")
except ValueError as e:
    print(f"Error for fib(-1): {e}")
fib(0): 0
fib(1): 1
fib(2): 1
fib(7): 13
Error for fib(-1): Input cannot be negative.

By explicitly handling n=0 and n=1, we define the foundational building blocks. This makes the recursive step much clearer.

4. Visualize / Whiteboard / Diagram

Often, stepping away from the keyboard and using a whiteboard, paper, or a diagramming tool (like Excalidraw, Mermaid, PlantUML) can provide clarity.

  • Draw Data Structures: Linked lists, trees, graphs.
  • Trace Execution: Step through loops, recursive calls, or system interactions with sample data.
  • Map System Flows: For debugging distributed systems, draw the communication paths.

Example Scenario: Understanding how a binary search tree insertion works.

Instead of just reading code, drawing the tree’s state before and after each insertion step makes the logic immediately apparent.

Let’s use a simple representation in text.

class Node:
    def __init__(self, key):
        self.key = key
        self.left = None
        self.right = None

def insert_bst(root, key):
    if root is None:
        return Node(key)
    
    if key < root.key:
        root.left = insert_bst(root.left, key)
    elif key > root.key:
        root.right = insert_bst(root.right, key)
    # If key == root.key, assume no duplicates or handle as needed
    return root

def print_tree(node, level=0, prefix="Root: "):
    if node is not None:
        print("    " * level + prefix + str(node.key))
        if node.left or node.right: # Only print children if they exist
            print_tree(node.left, level + 1, "L-- ")
            print_tree(node.right, level + 1, "R-- ")

# Let's insert values and visualize step-by-step
root = None
print("Inserting 50:")
root = insert_bst(root, 50)
print_tree(root)
print("\nInserting 30:")
root = insert_bst(root, 30)
print_tree(root)
print("\nInserting 70:")
root = insert_bst(root, 70)
print_tree(root)
print("\nInserting 20:")
root = insert_bst(root, 20)
print_tree(root)
print("\nInserting 40:")
root = insert_bst(root, 40)
print_tree(root)
print("\nInserting 60:")
root = insert_bst(root, 60)
print_tree(root)
print("\nInserting 80:")
root = insert_bst(root, 80)
print_tree(root)
Inserting 50:
Root: 50

Inserting 30:
Root: 50
    L-- 30

Inserting 70:
Root: 50
    L-- 30
    R-- 70

Inserting 20:
Root: 50
    L-- 30
        L-- 20

Inserting 40:
Root: 50
    L-- 30
        L-- 20
        R-- 40

Inserting 60:
Root: 50
    L-- 30
        L-- 20
        R-- 40
    R-- 70
        L-- 60

Inserting 80:
Root: 50
    L-- 30
        L-- 20
        R-- 40
    R-- 70
        L-- 60
        R-- 80

This output, while textual, represents the tree structure. On a whiteboard, you’d physically draw nodes and arrows, which makes the traversal and insertion logic much more intuitive.

5. Iterate and Refine (Trial and Error with Purpose)

Your first solution doesn’t have to be perfect. Often, a “brute force” or naive approach is a good starting point. Once you have a working solution, you can then optimize it. This is not random guessing; it’s an iterative process: solve, analyze, improve.

Example Scenario: Find if a list contains duplicate numbers.

Naive Approach (O(N^2)): Compare every element with every other element.

Optimized Approach (O(N)): Use a hash set (or dictionary in Python) to keep track of seen elements.

def contains_duplicate_naive(nums: list[int]) -> bool:
    """
    Checks for duplicates using a nested loop (O(N^2)).
    """
    n = len(nums)
    for i in range(n):
        for j in range(i + 1, n):
            if nums[i] == nums[j]:
                return True
    return False

def contains_duplicate_optimized(nums: list[int]) -> bool:
    """
    Checks for duplicates using a hash set (O(N) on average).
    """
    seen = set()
    for num in nums:
        if num in seen:
            return True
        seen.add(num)
    return False

# Test cases
test_cases = [
    ([1, 2, 3, 4, 5], False),
    ([1, 2, 3, 4, 1], True),
    ([], False),
    ([7], False),
    ([7, 7], True)
]

print("--- Naive Approach ---")
for nums, expected in test_cases:
    result = contains_duplicate_naive(nums)
    print(f"List: {nums}, Duplicates: {result} (Expected: {expected})")
    assert result == expected

print("\n--- Optimized Approach ---")
for nums, expected in test_cases:
    result = contains_duplicate_optimized(nums)
    print(f"List: {nums}, Duplicates: {result} (Expected: {expected})")
    assert result == expected
--- Naive Approach ---
List: [1, 2, 3, 4, 5], Duplicates: False (Expected: False)
List: [1, 2, 3, 4, 1], Duplicates: True (Expected: True)
List: [], Duplicates: False (Expected: False)
List: [7], Duplicates: False (Expected: False)
List: [7, 7], Duplicates: True (Expected: True)

--- Optimized Approach ---
List: [1, 2, 3, 4, 5], Duplicates: False (Expected: False)
List: [1, 2, 3, 4, 1], Duplicates: True (Expected: True)
List: [], Duplicates: False (Expected: False)
List: [7], Duplicates: False (Expected: False)
List: [7, 7], Duplicates: True (Expected: True)

Both work, but the optimized version is significantly faster for large inputs. The “puzzle” here is finding the more efficient data structure and algorithm.

6. Test Relentlessly

Writing tests for your solution is non-negotiable. Tests act as executable specifications and safety nets.

  • Unit Tests: Verify individual components or functions.
  • Edge Cases: Test empty inputs, maximum/minimum values, nulls, invalid formats, or boundaries.
  • Negative Tests: What happens with invalid input? Does it fail gracefully?

Example Scenario: Test a function that calculates the sum of numbers in a list, ensuring it handles various inputs correctly.

import pytest

def sum_list_elements(numbers: list[int]) -> int:
    """
    Calculates the sum of elements in a list.
    """
    total = 0
    for num in numbers:
        total += num
    return total

# Using pytest for demonstration
# Save this in a file named test_sum_function.py
# Then run `pytest test_sum_function.py` in your terminal.
# test_sum_function.py
import pytest
from your_module import sum_list_elements # Assuming sum_list_elements is in your_module.py

def test_empty_list():
    assert sum_list_elements([]) == 0

def test_single_element_list():
    assert sum_list_elements([5]) == 5

def test_positive_numbers():
    assert sum_list_elements([1, 2, 3]) == 6

def test_negative_numbers():
    assert sum_list_elements([-1, -2, -3]) == -6

def test_mixed_numbers():
    assert sum_list_elements([10, -5, 0, 2]) == 7

def test_large_numbers():
    assert sum_list_elements([10**9, 2*10**9]) == 3*10**9

# Note: For types, if your function signature expects int,
# you might want to add a test that ensures it handles non-int inputs gracefully
# if that's a requirement (e.g., raise TypeError or filter).
# For simplicity, we assume valid int inputs here as per type hint.
# To run these tests:
# 1. Save the sum_list_elements function in a file, e.g., your_module.py
# 2. Save the test_sum_function.py file.
# 3. Make sure you have pytest installed (`pip install pytest`).
# 4. Run from your terminal:
pytest -v test_sum_function.py
============================= test session starts ==============================
platform linux -- Python 3.9.13, pytest-7.4.0, pluggy-1.0.0 -- /path/to/venv/bin/python
cachedir: .pytest_cache
rootdir: /path/to/your/project
collected 6 items                                                              

test_sum_function.py::test_empty_list PASSED                             [ 16%]
test_sum_function.py::test_single_element_list PASSED                    [ 33%]
test_sum_function.py::test_positive_numbers PASSED                       [ 50%]
test_sum_function.py::test_negative_numbers PASSED                       [ 66%]
test_sum_function.py::test_mixed_numbers PASSED                          [ 83%]
test_sum_function.py::test_large_numbers PASSED                          [100%]

============================== 6 passed in 0.01s ===============================

Testing is how you confirm your puzzle pieces fit correctly and the final picture is what you intended.

7. Debug Systematically

When things go wrong, resist the urge to randomly change code. Debugging is a puzzle in itself, requiring a logical, systematic approach.

  • Reproduce: Can you consistently make the bug happen?
  • Isolate: Narrow down the problem area. Which part of the code is responsible?
  • Observe: Use logging, print statements, or a debugger to see variable states and execution flow.
  • Hypothesize & Test: Formulate a theory about why it’s failing, then run an experiment (e.g., change one line, add a print) to validate or invalidate your theory.
  • Binary Search Debugging: If a bug appears after many changes, revert halfway back to a working state. If it’s fixed, the bug is in the second half; if not, it’s in the first. Repeat.

Example Scenario: Debugging a shell script where a variable isn’t behaving as expected.

#!/bin/bash

PROCESS_NAME="my_app_process"
LOG_FILE="debug.log"

# Simulate some log output
echo "Starting service..." > $LOG_FILE
echo "PID 1234: ${PROCESS_NAME} is running." >> $LOG_FILE
echo "Error: Failed to connect to DB." >> $LOG_FILE
echo "PID 5678: Another process." >> $LOG_FILE
echo "Error: Could not read config file." >> $LOG_FILE
echo "Stopping service." >> $LOG_FILE

echo "--- Original script (might have a subtle bug) ---"
# What if we want to count specific errors for 'my_app_process'?
# This might miss some logs if `grep` is too specific.
error_count=$(grep "Error:" $LOG_FILE | grep "${PROCESS_NAME}" | wc -l)
echo "Original error count for ${PROCESS_NAME}: ${error_count}"

echo -e "\n--- Systematic Debugging: Using set -x ---"
# Enable verbose debugging
set -x 
echo "Debugging steps for finding relevant errors:"

# Step 1: Filter error lines
ERROR_LINES=$(grep "Error:" $LOG_FILE)
echo "Found error lines: ${ERROR_LINES}"

# Step 2: Now, filter for process name within these lines.
# Problem: 'grep "${PROCESS_NAME}"' might not find anything because
# the error lines don't directly contain PROCESS_NAME in the simulated log above.
# This reveals the misunderstanding of log format.
RELEVANT_ERRORS=$(echo "${ERROR_LINES}" | grep "${PROCESS_NAME}")
echo "Relevant errors (after filtering by process name): ${RELEVANT_ERRORS}"

# This reveals the count will be 0, because no error lines contained "my_app_process"
# The puzzle is realizing the connection between "Error:" and "my_app_process" isn't direct.
FINAL_COUNT=$(echo "${RELEVANT_ERRORS}" | wc -l)
echo "Final count: ${FINAL_COUNT}"

set +x # Disable verbose debugging

echo -e "\n--- Solution after understanding log format ---"
# The actual "puzzle" was that "Error:" lines don't mention PROCESS_NAME.
# So, the problem isn't "errors *for* PROCESS_NAME" but "errors *around* PROCESS_NAME's logs".
# A more robust solution for this specific log format might involve correlating timestamps or PIDs.
# If we simply want ALL errors, the first grep is enough.
# If we want errors specifically *about* the process name, the log format needs to support it.

# Let's say we just want all errors for now, and the puzzle was just to get *any* errors.
# Then the first `grep "Error:"` would be enough.
all_errors=$(grep "Error:" $LOG_FILE | wc -l)
echo "Total error lines: ${all_errors}"

# Clean up
rm $LOG_FILE
--- Original script (might have a subtle bug) ---
Original error count for my_app_process: 0

--- Systematic Debugging: Using set -x ---
+ echo 'Debugging steps for finding relevant errors:'
Debugging steps for finding relevant errors:
+ grep 'Error:' debug.log
+ ERROR_LINES='Error: Failed to connect to DB.
Error: Could not read config file.'
+ echo 'Found error lines: Error: Failed to connect to DB.
Error: Could not read config file.'
Found error lines: Error: Failed to connect to DB.
Error: Could not read config file.
+ echo 'Error: Failed to connect to DB.
Error: Could not read config file.'
+ grep my_app_process
+ RELEVANT_ERRORS=
+ echo 'Relevant errors (after filtering by process name): '
Relevant errors (after filtering by process name): 
+ echo ''
+ wc -l
+ FINAL_COUNT=0
+ echo 'Final count: 0'
Final count: 0
+ set +x

--- Solution after understanding log format ---
Total error lines: 2

The set -x output clearly shows RELEVANT_ERRORS becoming empty, immediately highlighting that the second grep (grep "${PROCESS_NAME}") is the culprit, because the preceding ERROR_LINES simply don’t contain the process name. The puzzle here was a mismatch between assumption and log reality, revealed by systematic observation.

8. Don’t Be Afraid to Step Away

Sometimes, the best solution comes when you’re not actively thinking about the problem. Your subconscious mind continues to work. If you’re stuck, take a break: go for a walk, grab a coffee, work on something else. Often, the solution will present itself.

Conclusion

Solving puzzles is the core of software development. It’s not about memorizing solutions; it’s about cultivating a robust, adaptable methodology. By systematically understanding, breaking down, starting simple, visualizing, iterating, testing, and debugging, you transform seemingly insurmountable challenges into manageable steps. Practice these strategies consistently, and you’ll find yourself not just solving problems, but truly enjoying the process of discovery.

Happy puzzling!

The Ethics of Simulating the Dead Grief Bots Go Mainstream
Jun 20, 2025
Why the Command Line Still Reigns Supreme
Jun 17, 2025
Why Every Dev Should Implement a Trie at Least Once
Jun 17, 2025
Implementing an LRU Cache to Make Web Apps Feel Snappy
Jun 17, 2025
Decoding the Word Break Problem - A Developers Deep Dive
Jun 18, 2025
Demystifying the Event Loop Async Programming Explained
Jun 17, 2025
Last updated on
Share this post: Twitter Facebook LinkedIn
Recursion and Backtracking - A Practical Deep DiveUnderstanding the Tower of Hanoi - A Classic Recursive Problem