Find Your Own Answers

Service members understand how to find their own answers. They understand the governing guidance and how to interpret it. Law, regulation, guidance. They understand how to apply and what the differences are.

The Principle

In the military, you learn the chain of authority for information: law supersedes regulation, regulation supersedes guidance, guidance supersedes opinion. You learn to find the source, interpret it, and apply it to your situation.

Engineering is the same.

The goal is not to know everything. The goal is to know how to find anything.

A senior engineer isn't someone who has memorized the docs. They're someone who can find the right answer quickly, evaluate its reliability, and apply it correctly. This is a skill. It can be learned. It must be practiced.

The Hierarchy of Truth

Not all sources are equal. Work down the ladder; trust falls as you go.

1. The specification (law). What must be true. Language specs, protocol specs, API contracts, your own system's tests. For edge cases and "what should happen when," this is the ruling.

2. Official documentation (regulation). Written by the people who built it. Read the docs before Stack Overflow, before asking a coworker. The answer is often right there.

3. Official examples (guidance). How the authors intended it to be used. Simplified by design: they show the happy path, and real code has more edge cases.

4. Source code (ground truth). When the docs are wrong or incomplete, read the code. The source is the behavior itself, not a description of it. It might be confusing. It might be poorly written. But it's what actually happens.

5. Community resources (convention). Stack Overflow, blog posts, conference talks. Written by users, not authors. Check the date. Check the version. Verify against the docs.

6. AI assistants (opinion). Fast answers, variable reliability, and confident hallucination. Verify against the docs. Never ship generated code you could not explain.

7. Folklore (hearsay). "I heard that..." "Everyone knows..." Verify before applying.

The ladder is also a tiebreaker, with one distinction worth keeping sharp: the top of the ladder answers what should happen; the source and the running system answer what does. When intent and behavior disagree, you have not found a winner. You have found either a bug or a stale spec, and naming which one is the actual work.

The 15-Minute Rule

Digging too long wastes your time. Asking too quickly wastes others' time and stunts your growth. When you're stuck:

1. Spend 15 minutes trying to solve it yourself. Read the error message, all of it. Search for it verbatim. Check the docs. Try the obvious things.

2. Still stuck? Prepare to ask. Write down what you tried, what you expected, and what actually happened. Build a minimal reproduction if you can.

3. Ask with context. "I'm trying to X. I expected Y. I got Z. I tried A, B, and C."

Fifteen minutes is a default, not a law. Production down: ask immediately. Blocked and blocking others: ask sooner. New territory you'll meet again: dig longer.

Respect their time. The better your question, the faster the answer.

The signs that this skill needs work are unglamorous: asking before searching, skimming past error messages, pasting code you could not explain. Everyone starts there. The way out is habit, not talent. Search first. Read the actual docs. Verify before applying, especially community content and AI output. And when fifteen minutes of digging has not moved you, ask well: context, expected, actual, tried.

The goal was never to memorize answers. It is to know how to find them, evaluate them, and apply them. That skill outlasts any specific technology.