I still see production bugs where a simple substring search turns into a crash, a wrong branch, or an invisible failure. The root cause is usually not the algorithm—it’s the choice between two tiny methods that behave very differently when the text is missing. If you’re scanning log lines, parsing file names, or validating user input, the difference between returning -1 and throwing a ValueError is the difference between a predictable branch and a fatal exception.

I’ll walk you through how I think about find() and index(), how they behave, and how I choose between them in real code. You’ll see concrete examples, edge cases, and the practical patterns I rely on when I want a quick check, a hard guarantee, or a clean failure. I’ll also show how these decisions play with modern workflows, including AI-assisted refactors and typed Python code. The goal is simple: help you pick the right tool instantly and avoid subtle bugs.

The two methods, same mission, different contract

Both methods locate the position of a substring inside a larger string. The signature is similar, and in the happy path they return the same index. The contract is where they diverge:

• find() returns the integer index of the first match, or -1 if the substring isn’t found.
• index() returns the integer index of the first match, or raises ValueError if the substring isn’t found.

I think of find() as a soft probe and index() as a hard assertion. That contract difference shapes everything else: how you branch, how you log, and how you handle failure.

A concrete example I use in reviews

Here’s the smallest runnable example that shows the difference. I keep it in my head because it’s the quickest way to debug someone else’s logic.

s = "hello world"
find() returns -1 if not found
print(s.find("world"))   # 6
print(s.find("python"))  # -1
print(s.find("o", 5))    # 7

s = "hello world"
index() raises an exception if not found
print(s.index("world"))  # 6
print(s.index("python")) # ValueError
print(s.index("o", 5))   # 7

I use this as a mental unit test. If a developer expects an exception, I recommend index(). If they want a cheap “is it present?” check without try/except, I recommend find().

How I explain the behavior with a simple analogy

I explain it like this: imagine a librarian helping you find a book.

• find() is the librarian saying, “The book is on shelf 6. If it’s missing, I’ll just tell you ‘-1’.”
• index() is the librarian saying, “The book is on shelf 6. If it’s missing, I’m going to stop you with an error because you told me it must exist.”

That analogy helps teams remember the contract. It also makes it clear that index() is not more powerful; it’s just more assertive.

API surface: arguments and return values

Both methods take the same optional arguments:

• sub: the substring to search
• start (optional): start index
• end (optional): end index (non-inclusive)

The return values differ when the substring isn’t present.

s = "2026-01-27_app.log"
Search within a slice
print(s.find("_", 0, 10))   # 10? No, within 0..10, it’s not present => -1
print(s.find("_", 0, 11))   # 10, now within the range

A common mistake is forgetting that end is exclusive. When you pass the wrong end, find() returns -1 and your code quietly misroutes. index() will surface that problem immediately, which can be a good thing during development.

When I choose find() in real projects

I pick find() when the absence of the substring is a normal and expected outcome. These are typical cases:

• Optional markers: file names that sometimes include “_backup”
• Loosely structured text: log lines that vary by version
• User-generated input: you should not trust it to contain fixed tokens

Here’s a realistic example: parsing an uploaded filename to detect a build number. I want a default path when the tag is missing.

def extractbuildtag(filename: str) -> str | None:
# Looking for a suffix like "_b1234"; if not found, return None
marker = "_b"
pos = filename.find(marker)
if pos == -1:
return None
return filename[pos + len(marker):]
print(extractbuildtag("app_b1234.zip"))  # 1234
print(extractbuildtag("app.zip"))       # None

I don’t want exceptions here. I want a simple branch that keeps the pipeline moving.

When I choose index() in real projects

I choose index() when the substring must be present, and I want a loud failure if it isn’t. That’s common in:

• Structured formats: “protocol://host/path”
• Internal conventions: names generated by your own system
• Validation steps: rejecting bad input early

Here’s an example I use in services that parse resource identifiers. If the format is wrong, I want a clear exception.

def parseresourceid(resource_id: str) -> tuple[str, str]:
# Expected format: "tenant:resource"
sep = ":"
seppos = resourceid.index(sep)  # Raises if invalid
tenant = resourceid[:seppos]
resource = resourceid[seppos + 1:]
if not tenant or not resource:
raise ValueError("Invalid resource_id format")
return tenant, resource
print(parseresourceid("acme:invoices"))
parseresourceid("acme") -> ValueError

If this exception fires, it’s a strong signal of a bug or bad data. That’s exactly what I want.

Error handling patterns I rely on

There are two idioms I recommend. The first is explicit branching with find(). The second is exception-driven control flow with index(). I prefer the first for user input, the second for internal guarantees.

# Pattern 1: explicit branching
pos = s.find("/")
if pos == -1:
# Provide a fallback path
base = s
else:
base = s[:pos]

# Pattern 2: exception-driven control flow
try:
pos = s.index("/")
except ValueError:
# Log and raise a higher-level error
raise ValueError("Expected ‘/‘ in path")

In modern codebases, I also look at how exceptions are handled in the calling layer. If I see broad try/except blocks that already translate errors into user-friendly messages, I’m more likely to use index() and let it fail fast.

A practical decision checklist

Here’s the decision flow I actually follow. It’s short and reliable:

• If missing text is normal: use find() and branch on -1
• If missing text is a bug: use index() and let it explode
• If you want a default value: use find() or partition()
• If you want to enforce a format: use index() or split() with validation

This avoids “It depends on your situation…” because I’ve already named the situation. If you can classify the input as optional vs guaranteed, the method choice is obvious.

Common mistakes I keep seeing

These are the failures that show up in reviews and incident reports. They’re easy to avoid once you see them once.

• Using find() but forgetting to check for -1, then slicing with it
• Using index() for user input and then crashing on a normal case
• Confusing start/end arguments and searching in the wrong slice
• Treating 0 as “not found” and breaking when the match is at the start

Here’s a bug I’ve fixed multiple times:

# Buggy: fails when the match is at index 0
if s.find("http"):
print("has scheme")
Correct
if s.find("http") != -1:
print("has scheme")

The original code fails because 0 is falsy. If you’re scanning for a prefix, that’s the most common index. I always tell developers to compare explicitly with -1 when using find().

A modern alternative pattern: partition()

When I only care about splitting once, I often use partition() because it gives me a clean, branchable result without exceptions.

def split_once(s: str, sep: str) -> tuple[str, str, str]:
# Always returns a 3-tuple: (head, sep, tail)
return s.partition(sep)
head, sep, tail = split_once("tenant:resource", ":")
if sep == "":
# Not found
print("invalid format")
else:
print(head, tail)

This is not a replacement for find() or index(), but it’s a good option when you want a single split and a clear indicator of presence.

Performance considerations that actually matter

Both methods are implemented in optimized C and run in linear time relative to the length of the string. In practice, the difference between them is negligible for typical inputs. The real cost is in error handling and control flow:

• A successful index() call is about as fast as find()
• A failed index() call is slower because raising exceptions is expensive
• A failed find() call is cheaper, returning -1 directly

If you’re running millions of searches in a tight loop and missing is expected, I recommend find(). You’ll avoid exception overhead. In normal application code, the performance difference is rarely noticeable; correctness and clarity matter more.

Table: traditional vs modern usage patterns

When teams modernize codebases, the difference often shows up in error handling style. Here’s a quick comparison I share during refactors.

Goal

Traditional style

Modern style

My recommendation

—

—

—

—

Check if substring exists

if s.find(x) != -1

if x in s

Use in for readability, or find() if you need the index

Assert required delimiter

s.index(":")

s.index(":") with explicit error message

Keep index(), add clear error messaging

Split once on delimiter

s.find() + slicing

s.partition()

Prefer partition() when it improves clarity

Validate format

try/except around index()

explicit validator with regex or split

Use index() only if the rule is simpleIf you just need a boolean check, x in s is idiomatic and clear. When you need the index, find() or index() are your tools.

Edge cases I test for in reviews

I keep a mental checklist of edge cases, especially when parsing user input or system identifiers.

• Empty substring: "abc".find("") returns 0, and index("") also returns 0
• Unicode text: both methods operate on Unicode code points, not grapheme clusters
• Negative start: allowed, counts from the end
• start > end: search range is empty, returns -1 or raises ValueError

Here’s a quick test harness you can run to see behavior on tricky inputs:

cases = [
("", ""),
("abc", ""),
("abc", "a"),
("abc", "d"),
]
for s, sub in cases:
print(s, sub, s.find(sub))
try:
print(s, sub, s.index(sub))
except ValueError:
print(s, sub, "ValueError")

This is where I remind developers that empty substrings are considered found at index 0. If your logic treats empty input as invalid, you need explicit checks.

Real-world scenario: parsing a log line

Imagine a log format like: "2026-01-27

ERROR

service=authmsg=invalid token". I often parse this type of string in streaming workflows. The parsing strategy depends on whether the separators are guaranteed.

def parselogline(line: str) -> dict[str, str]:
# Expecting ‘|‘ separators; if missing, treat as invalid
parts = []
start = 0
for _ in range(3):
sep_pos = line.find("|", start)
if sep_pos == -1:
raise ValueError("Invalid log format")
parts.append(line[start:sep_pos])
start = sep_pos + 1
parts.append(line[start:])
return {
"date": parts[0],
"level": parts[1],
"service": parts[2],
"msg": parts[3],
}

I intentionally use find() here instead of index() because I want a consistent error message and I’m already handling the -1 case. If I wanted to keep the logic shorter and didn’t care about the error message, I could switch to index().

Real-world scenario: validating a URL-like pattern

This time, I want a hard failure because the format is required for downstream systems.

def parsesimpleurl(s: str) -> tuple[str, str]:
# Expected format: scheme://rest
scheme_sep = "://"
seppos = s.index(schemesep)  # Should exist
scheme = s[:sep_pos]
rest = s[seppos + len(schemesep):]
if not scheme or not rest:
raise ValueError("Invalid URL-like pattern")
return scheme, rest

I use index() because a missing scheme is a true error, not a normal absence. This makes the failure loud and early.

A subtle bug: slicing with -1

If you use find() and then slice without checking -1, you can get wrong results instead of a clean error. That’s one reason I sometimes prefer index() in strict parsing.

s = "filename.txt"
Bug: if ‘.‘ is missing, pos = -1 and this slices off the last char
pos = s.find(".")
name = s[:pos]
print(name)

If the dot doesn’t exist, name becomes everything except the last character, which looks valid but is wrong. This is a dangerous failure mode. In this pattern, I either check for -1 or use index() to force an exception.

How I document the choice for teams

When I’m reviewing code, I want the intent to be obvious. I’ll suggest small comments or helper functions to encode the contract.

def findornone(s: str, sub: str) -> int | None:
# Explicitly codifies the "missing is normal" contract
pos = s.find(sub)
return None if pos == -1 else pos

def indexorfail(s: str, sub: str, label: str) -> int:
# Raises with a clear error message
try:
return s.index(sub)
except ValueError:
raise ValueError(f"Expected {label} in input")

This makes the intent so clear that other developers won’t accidentally reverse the behavior later.

Interactions with typing and modern tooling

In 2026, most teams I work with use type checkers and AI-assisted refactors. The method choice affects both:

• With find(), the return type is always int, but you must branch on -1. That’s easy to miss in static analysis.
• With index(), a missing substring becomes an explicit exception. Type checkers won’t guarantee safety, but exception paths are more obvious in review.

If I’m working in a codebase that relies on tools like mypy or pyright, I often wrap the behavior with helper functions like findornone because a return type of int | None is easier for the type checker to reason about than the magic value -1.

AI code assistants also tend to default to find() without checking -1, so I keep a linting rule or review checklist to catch this.

Testing strategy I recommend

These tests are tiny, but they catch the biggest mistakes:

• Successful match at index 0
• Successful match at a later index
• Missing substring
• Empty substring
• Behavior with start/end bounds

Example tests:

def testfindindex():
s = "abc"
assert s.find("a") == 0
assert s.find("d") == -1
assert s.find("") == 0
assert s.find("b", 2) == -1
assert s.index("a") == 0
try:
s.index("d")
assert False, "Expected ValueError"
except ValueError:
pass

These tests are small enough to keep as part of any parsing utility module.

A quick note on lists and sequences

You might see index() on lists too. The contract is similar, but the behavior is subtly different and worth knowing. list.index(value) raises ValueError when the value is missing, and there is no find() counterpart on lists. The closest equivalent is often a manual search, next() with a default, or a try/except around index().

If you’re coming from strings to lists, it’s easy to carry over the “-1 means missing” assumption and introduce a bug. I remind teams that only string.find() returns -1. On lists and tuples, missing is always an exception.

items = ["a", "b", "c"]
list.index raises ValueError
pos = items.index("b")  # 1
items.index("x") -> ValueError

That difference matters when you refactor from strings to tokens, or when you parse then search in the resulting list.

Deep dive: start/end parameters and off-by-one traps

The start and end arguments are incredibly useful, but they are also a common source of subtle bugs. I see two specific mistakes frequently:

1) Confusing end as inclusive, not exclusive

2) Passing a start that already skips the match

Here’s a quick demonstration:

s = "abc/def/ghi"
Want the second slash
first = s.find("/")       # 3
second = s.find("/", first + 1)  # 7
Using end to search only the first segment
print(s.find("/", 0, 3))  # -1, because end is exclusive
print(s.find("/", 0, 4))  # 3, now included

If your logic is sensitive to slicing boundaries, find() can silently fail while index() will raise and show you the mistake immediately. That’s another reason I sometimes start with index() during development and later switch to find() once the boundaries are correct and I want softer behavior in production.

Choosing between find(), index(), and "in"

A lot of developers default to find() for any substring check, but if you don’t need the index, it’s often the wrong choice. Use in for readability, and reserve find()/index() for when the index drives the next step.

# Readable presence checks
if "error" in line:
handle_error()
Index needed for slicing
pos = line.find("=")
if pos != -1:
key = line[:pos]
value = line[pos + 1:]

This small change makes code easier to review and reduces off-by-one bugs caused by forgetting to check -1.

Defensive parsing: a hybrid approach

In production, I sometimes blend both approaches. I’ll use find() to avoid exceptions in the hot path, but I’ll still assert or log when the input should have been well-formed.

def parse_header(line: str) -> tuple[str, str] | None:
# Expected format: "Key: Value"
sep = ": "
pos = line.find(sep)
if pos == -1:
# Soft failure but visible in logs
# In a real service, this might be a structured log event
return None
return line[:pos], line[pos + len(sep):]

This pattern is particularly useful when you’re parsing data from external systems you don’t fully control. It avoids crashing a stream worker while still giving you a point to log and inspect the unexpected line.

A bigger example: parsing a config line safely

Let’s say you have a simple config format with optional comments and key-value pairs. This is a scenario where find() helps keep the parser resilient.

def parseconfigline(line: str) -> tuple[str, str] | None:
# Strip comments
hash_pos = line.find("#")
if hash_pos != -1:
line = line[:hash_pos]
line = line.strip()
if not line:
return None
eq_pos = line.find("=")
if eq_pos == -1:
raise ValueError("Missing ‘=‘ in config line")
key = line[:eq_pos].strip()
value = line[eq_pos + 1:].strip()
if not key:
raise ValueError("Empty key")
return key, value

Here I mix both worlds: find() for optional comments, and a required equals sign enforced via a -1 check with a clear error. I could use index() for the equals sign, but the explicit branch gives me a tailored error message and allows me to handle it consistently.

Another bigger example: file name parsing with strict and loose modes

I often build parsers that can operate in both strict and permissive modes. That’s a great place to show the difference between find() and index().

def parse_filename(name: str, strict: bool = False) -> dict[str, str] | None:
# Expected: "projectenvversion.ext"
# Example: "appprod1.2.3.zip"
if strict:
parts = name.split("_")
if len(parts) < 3:
raise ValueError("Invalid filename format")
else:
parts = name.split("_")
if len(parts) < 3:
return None
ext_pos = name.rfind(".")
if ext_pos == -1:
if strict:
raise ValueError("Missing file extension")
return None
project = parts[0]
env = parts[1]
version = parts[2]
ext = name[ext_pos + 1:]
return {
"project": project,
"env": env,
"version": version,
"ext": ext,
}

Note that I used rfind() for the extension; it follows the same contract as find(), just searching from the end. Strict mode enforces a format and raises, permissive mode returns None. The decision here mirrors the same logic you’d apply to find() vs index().

The role of rfind() and rindex()

You’ll often need to search from the end. In those cases, rfind() and rindex() behave exactly like find() and index() but scan from the right. The same “soft vs hard” decision applies.

• rfind() returns -1 if missing
• rindex() raises ValueError if missing

path = "/var/log/app/server.log"
last_slash = path.rfind("/")
print(path[last_slash + 1:])  # server.log
rindex would raise if ‘/‘ were missing

If you only need the last occurrence, rfind() is often clearer than find() combined with slicing.

How I handle empty substring behavior

The empty substring rules can surprise people. Both find() and index() treat an empty substring as found at the start of the search range. That means:

• "abc".find("") -> 0
• "abc".find("", 1) -> 1
• "abc".find("", 1, 2) -> 1

This is mathematically consistent, but not always what you want. If empty input is invalid in your domain, check it explicitly before searching.

def safe_find(s: str, sub: str) -> int:
if sub == "":
raise ValueError("Empty substring is not allowed")
return s.find(sub)

I only add this check when empty input would represent a broken upstream step. Otherwise I stick with the standard behavior.

Unicode and grapheme clusters: what “index” really means

Python strings are sequences of Unicode code points, not grapheme clusters. That means the index returned by find()/index() may land in the middle of what a human thinks is a single character (for example, characters with combining marks or emoji sequences).

If your application deals with user-facing text in multiple languages, be aware that the “index” is a code point index, not a visual character index. For most logging and parsing tasks, this is fine. For UI or text editing workflows, you may need a different approach (like grapheme-aware libraries) if accurate cursor placement matters.

This is not a reason to avoid find() or index(), but it is a reason to understand what the index actually means.

Debugging strategy: make failures explicit

When you’re debugging a parsing bug, it can be helpful to temporarily swap find() for index() so missing substrings throw exceptions and show you where the assumptions are wrong. Then, once the issue is resolved, switch back to find() if you truly want soft behavior.

I treat this as a quick, targeted technique. It doesn’t replace good testing, but it often reveals incorrect assumptions about input formats much faster.

Patterns for safe slicing

If you use find(), it’s worth standardizing slicing patterns so you don’t forget the -1 checks. Here are two patterns I use to reduce mistakes:

# Pattern A: use a guard clause
pos = s.find("=")
if pos == -1:
return None
value = s[pos + 1:]

# Pattern B: convert -1 to None once
pos = findornone(s, "=")
if pos is None:
return None
value = s[pos + 1:]

Both keep the branch close to the search and prevent accidental slicing with -1.

Exception hygiene with index()

If you choose index(), handle exceptions intentionally. I avoid bare except: blocks and I usually translate the error to include the input context or the expected format.

def parse_pair(s: str) -> tuple[str, str]:
try:
pos = s.index(":")
except ValueError as e:
raise ValueError(f"Expected ‘key:value‘ format, got: {s!r}") from e
return s[:pos], s[pos + 1:]

The from e preserves the original exception context. That’s helpful when you debug or inspect logs later.

Real-world scenario: CSV-like parsing without full CSV

I see a lot of custom parsing where the format is “CSV-like” but only uses a single delimiter and doesn’t require quotes or escaping. In those cases, find() is sometimes enough, but index() can be safer if the line must contain the delimiter.

def parsepairline(line: str) -> tuple[str, str]:
# Format: key,value (no quotes)
pos = line.index(",")  # Required
key = line[:pos].strip()
value = line[pos + 1:].strip()
if not key or not value:
raise ValueError("Invalid pair line")
return key, value

If you decide to switch to find(), you must also change the control flow to branch on -1. That’s the contract in action again.

Why I rarely use regex for simple substring search

Regex is powerful, but it’s often overkill for finding a substring. It can also be slower and less readable. I only reach for regex when I need complex pattern matching or validation. For simple presence or a single delimiter, find()/index() (or partition()) are better.

If your rule is, “must contain a colon somewhere,” index() is perfect. If your rule is, “must contain a colon followed by 2–4 digits,” then a regex might be appropriate. Don’t reach for regex to solve a problem a basic method can solve more clearly.

Refactoring guide: converting find() logic to index()

Sometimes you want to move from permissive to strict behavior. Here’s how I refactor:

1) Identify the find() calls that expect a substring to exist

2) Replace with index()

3) Add a clear exception message if needed

4) Update tests to expect ValueError

Example:

# Before
pos = s.find(":")
if pos == -1:
return None
return s[:pos], s[pos + 1:]

# After
pos = s.index(":")
return s[:pos], s[pos + 1:]

Then I add a test that missing data raises ValueError. This makes the new contract explicit.

Refactoring guide: converting index() logic to find()

The opposite refactor is common too, especially when you realize the input isn’t actually guaranteed. The steps are:

1) Replace index() with find()

2) Handle -1 explicitly

3) Return None or a fallback

4) Adjust callers to handle that fallback

# Before
pos = s.index("/")
return s[:pos]

# After
pos = s.find("/")
if pos == -1:
return s  # or None, or a default
return s[:pos]

This is not just a method swap; it’s a change in the error contract, so update the caller accordingly.

A quick comparison table of return behavior

Sometimes I show this table to new team members because it compresses the entire difference into one glance.

Method

Found

Not found —

—

— find()

returns index

returns -1 index()

returns index

raises ValueError rfind()

returns index

returns -1 rindex()

returns index

raises ValueError

Once you know this, you know the whole story.

Production considerations: logging and observability

In production systems, the difference between find() and index() is not just about exceptions; it’s about observability. If you choose find() and return None on missing data, you might silently drop problematic input. That’s fine if missing is expected, but it’s dangerous if it indicates a bug.

I usually add one of these patterns:

• For expected missing: no log, but a counter for metrics
• For unexpected missing: warning logs with a sample of the input
• For critical missing: raise ValueError and fail fast

This is less about the method itself and more about how you instrument your code. But your choice of find() vs index() often implies which monitoring path you should pick.

AI-assisted refactors: the pitfalls I watch for

AI assistants are great at rewriting code, but they sometimes flatten intent. The two mistakes I see most are:

1) Replacing index() with find() without adding a -1 check

2) Replacing find() with index() and accidentally introducing a crash on optional input

When I use AI tools, I scan for these changes first. If you keep the “soft probe vs hard assertion” framing in mind, you can catch most of these errors before they hit production.

Using find() and index() in typed Python

If you’re in a typed codebase, consider using helper functions that make the return type explicit. That helps your tooling and your teammates.

from typing import Optional
def findornone(s: str, sub: str) -> Optional[int]:
pos = s.find(sub)
return None if pos == -1 else pos

This turns a magic value into a clear optional type. If you’re using pyright or mypy, this often yields better type checking and less ambiguous code.

A quick note about bytes

Both find() and index() also exist on bytes objects. The behavior is the same, except you’re searching for bytes instead of strings.

data = b"\x00\x01\x02"
print(data.find(b"\x01"))  # 1
data.index(b"\x03") -> ValueError

The same “soft vs hard” rule applies. I mention this because binary parsing bugs can be far more subtle than text parsing bugs.

Decision patterns for real teams

Here’s how I encode the decision for teams so it’s not just in my head:

• Parsing external input: default to find(), branch, and log if unexpected
• Parsing internal identifiers: default to index(), fail fast on anomalies
• Refactoring legacy code: keep the existing contract unless you update callers
• Writing utilities: provide both behaviors (e.g., parse() and parse_strict())

This makes the choice explicit at the architecture level, not just in a single line of code.

A strict vs permissive parsing API

If you’re building a shared parsing library, consider exposing both behaviors in the API. That way callers can opt into strictness without changing method internals.

def parsetagpermissive(s: str) -> str | None:
pos = s.find("#")
if pos == -1:
return None
return s[pos + 1:]
def parsetagstrict(s: str) -> str:
pos = s.index("#")
tag = s[pos + 1:]
if not tag:
raise ValueError("Empty tag")
return tag

This makes your intent obvious and allows downstream code to pick the right contract.

Summary: the one-sentence rule I keep in mind

If you remember only one thing, make it this:

• Use find() when missing is expected, use index() when missing is a bug.

Everything else—logging, performance, testing, refactoring—flows from that contract.

Final checklist before you choose

Before I ship code that uses find() or index(), I ask myself these questions:

• Is the substring guaranteed by format or convention?
• If it’s missing, should we proceed or fail?
• Will a silent -1 cause subtle slicing bugs later?
• Does the caller already handle exceptions cleanly?

Answer those and the choice becomes automatic.

Closing thought

These two tiny methods look almost identical in code, but they encode very different assumptions about your data. That’s why I put so much emphasis on choosing the right one. If you treat find() as a soft probe and index() as a hard assertion, you’ll avoid the most common production bugs and make your parsing logic both clearer and safer.

When in doubt, choose clarity over cleverness. And if you’re still unsure, write the tiny test harness and watch the behavior. It takes 30 seconds and saves hours of debugging later.