How to Highlight Code Based on Importance

I write every file in the repo with a different level of attention, and so does everyone else. The payment handler gets three reads before I open a pull request. The CSV export helper gets one pass and hope. The difference is rarely written down anywhere. It is a quiet ranking of how much each file touches money, correctness, and my reputation. Naming that ranking explicitly, and building review gates around it, turns private instinct into a repeatable process for the whole team.

Key Takeaways:

• Every developer already stack ranks code paths by how much they care; the value is in writing that ranking down and enforcing it.
• Not every line of a pull request needs the same review effort. Routing review to high-care paths cuts review fatigue and escaped defects.
• Automation is the natural owner of low-care, high-volume code: formatting, linting, and type checks handle what no human needs to reread.
• On GitHub, CODEOWNERS and protected branches give you the mechanism to encode care tiers directly into the source control platform’s merge flow.
• A runtime “care sidecar” that annotates logs and tests is a workable experiment, but it only works if the tier manifest stays in sync with the code.

The Three-Tier Heuristic

When a reviewer opens a diff on GitHub, they do not parse the file evenly. They spend disproportionate attention on lines that would hurt if wrong: an auth check, a retry loop, a transaction boundary. Everything else gets skimmed. This is a rational allocation of finite attention, and it becomes a problem only when nobody admits it. A Coursera overview of GitHub describes the platform as a web-based hosting service for Git repositories that layers collaboration tools on top, which is exactly where that instinct plays out through pull requests, diffs, and review requests.

Promoting and Demoting Tiers

I use three tiers. Tier one is code I trust to be boring: fixtures, static config, generated bindings, simple getters, and anything a linter can fully validate. Tier two is code that must be mostly right: the common path, normal API handlers, average business logic, stuff that runs every day without drama. Tier three is code where a subtle mistake is expensive: money movement, auth, retry and timeout math, anything a customer or auditor would notice. The tier decides how many passes I give a file before it lands, and how much evidence it has to carry.

Pretending the ranking does not exist causes real problems. Flat review rules, where every pull request must pass the same checklist, produce two failure modes. Either reviewers rubber-stamp everything because the list is unmanageably long, or they burn hours on a CSV export while a payment-state edge case sails through. A care tier fixes both by being explicit about where attention goes. It also gives new engineers a map of the codebase’s risk surface on day one, which is more valuable than any onboarding document.

Turning Care Into a Pull Request Gate

The mechanism for enforcing this on a team already lives in Git and the hosting platform. GitHub’s features page lists pull requests, protected branches, and code review as core collaborator features: reviewers visualize changes, and protected branches enforce merge restrictions by requiring reviews or limiting who can approve. The InfoWorld explainer of GitHub lays out the same shape: a pull request is a proposal to merge a set of changes from one branch into another, and protected branches gate that merge behind required review.

That lets you map tiers onto hard gates. Tier one merges after CI passes and only needs a single sign-off. Tier two requires one human review. Tier three requires additional reviewers plus a test that asserts an invariant. The code below shows how a reviewer might annotate a diff so the tier is visible before anyone reads line one. This is a different lever from the size and turnaround discipline covered in our high-prf code review processes piece; that post manages how much changes and how fast, while tiers manage where attention actually lands.

The comment has two purposes. It tells the reviewer this is a place to slow down, and it tells the author which invariants deserve unit tests: idempotency, price snapshot timing, and the partial-failure path. The same diff, written without a tier note, invites a skim. The annotation is cheap, but it changes the default behavior of every person who touches the file afterward.

What Gets Missed When Everything Gets Equal Review

Equal review effort sounds fair and scales poorly. When a reviewer must give the same attention to a renamed import, a retry backoff calculation, and a compliance-relevant data transformation, the constrained resource becomes the reviewer’s working memory. Attention spent verifying an unchanged datetime.now() call is attention not spent on a race condition two lines down. The result is diluted safety spread so thin that expensive bugs slip through the same gate as harmless ones.

The classic victim is untested “glue” code: code that sits between two systems, does nothing complicated, and passes review because it reads easily. Yet integration points are where prod incidents concentrate. A webhook handler, a message-queue consumer, a database migration that runs once and never again. These look boring, so they collect tier-one attention while carrying tier-three blast radius. The fix is to promote specific integration code into tier three when its failure cost is high, so it collects the same scrutiny as a payment handler. Raising global vigilance everywhere is a slower, less sustainable answer; people cannot sustain it.

A useful test for promotion: ask whether a bug here would cause a rollback, a compliance finding, or a silent data-corruption incident. If the answer is yes for any of the three, the code belongs in tier three regardless of how boring it looks. If the answer is no, it stays in tier two or one, and the team saves its energy for paths that actually threaten the product.

Automation Replaces Bottom Tiers

Tier one is where automation should own review. Formatting, linting, type checking, and dependency scanning catch mechanical failures that no human needs to read for. Removing that burden from human review leaves reviewers with only the parts of the diff that need judgment. This is the single highest-impact change a team can make, because it converts reviewer time from mechanical verification into design and correctness review.

GitHub Actions fits here as the CI/CD layer that runs checks and reports status on every pull request. The InfoWorld piece describes Actions as a system that automates build, test, and deployment pipelines, with events like opening a pull request or pushing a commit triggering workflows. Pointing low-tier checks at CI means a maintainer’s approval is no longer spent confirming that a file is formatted; it is spent on tier-two and tier-three decisions. This complements the pre-review pipeline in our code review deep dive, which argues automation should clear mechanical comments before a human looks at the code.

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# .github/workflows/tier-check.yml (excerpt)
- name: Tier 1 gate
 run: |
 # Tier-1 files must pass lint + type check; no human approval needed.
 npx eslint --max-warnings 0 src/bindings
 npx tsc --noEmit

- name: Fail on tier-3 drift
 # Path-filtered: only run when tier-3 file changed.
 if: ${{ steps.paths.outputs.tier3_changed == 'true' }}
 run: python ci/assert_tier3_has_tests.py

The second job is the part most teams skip: check that a tier-three change actually carried a test. Without it, the tier note is decoration. With it, CI enforces the promise that high-care code lands with evidence. The path filter matters as well; running the full tier-three assertion suite on every push wastes minutes, while running it only when a risk-sensitive file changed keeps the feedback loop tight.

The CODEOWNERS File as a Care Manifest

The cleanest place to record the care map is CODEOWNERS, which GitHub reads to auto-assign the right reviewers. A GitHub code-owners doc describes it as a file that defines the individuals or teams responsible for code in a repo, letting the platform route changes to people who know them. That is the care tier made mechanical: the riskiest directory always lands on a watchful pair of eyes, automatically, before anyone has to remember to tag them.

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# .github/CODEOWNERS
# Order matters: last matching pattern wins. Specific paths first.
/services/payments/ @fintech-core
/services/auth/ @identity-team
/internal/api/ @backend-eng
/scripts/export/ @data-plumbers

The mapping below is a design template, not a fixed policy. Each team fills in its own directories and decides its own merge rules. Writing it out forces the conversation that most teams skip: which paths actually carry risk, and who is accountable when one of them breaks.

The table works as a starting point for conversation, forcing the team to say out loud which paths carry risk. When a new directory appears, deciding its tier in review beats deciding on the day of an incident. The alternative, leaving ownership unassigned, produces the “tag a teammate and hope” pattern that lets risky changes sit unreviewed.

Promoting and Demoting Tiers

Tiers are not static. A file that was boring six months ago becomes risk-sensitive the moment it gains a new caller, a new dependency, or a compliance obligation. The reverse also happens: code that was once on the critical path gets frozen behind a stable interface and quietly becomes tier one. Treating the ranking as fixed causes teams to spend tier-three attention on dead code while a new integration point goes unexamined.

The promotion trigger is the same three-part test used earlier: rollback, compliance finding, or silent corruption. When any of those becomes plausible for a file, it moves up a tier. The demotion trigger is subtler. A path can drop a tier when it has been stable for a long stretch, is covered by tests, and has no new callers. Demoting is worth doing deliberately, because every file held at an unnecessarily high tier burns review attention that should go somewhere real.

One practical way to keep the ranking honest is to review it during incident postmortems. When something breaks in prod, ask whether the tier assignment predicted it. If a tier-one file caused a tier-three incident, that signals the ranking was wrong, not that the process failed. The postmortem becomes the mechanism for correcting the care map, the same way escaped-defect analysis in our review process guide corrects a checklist.

An Honest Attempt at a Runtime Sidecar

Beyond repo config, I keep a small experiment: a runtime sidecar that annotates logs and test output with the care tier, so the ranking surfaces where it is executed, not just where it is reviewed. It is deliberately simple and deliberately inconclusive; the point is the signal, not the tooling.

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

import logging

CARE = {"T1": logging.DEBUG, "T2": logging.INFO, "T3": logging.WARNING}

def log_for(path):
 tier = infer_tier(path) # reads repo manifest, e.g. TIERS.md
 return logging.getLogger(f"care:{tier}")

# Usage
log_for("services/payments/charge.py").warning("charge retry 2")
# Only T3 paths emit at WARNING, so noisy glue code stays silent.

The honest caveat is that infer_tier needs a real source of truth or it quietly drifts. In practice the manifest drifts faster than the code, so I treat the sidecar as a telemetry aid, not a control plane. Its real contribution is making the tier visible at the exact moment a developer scrolls a log line, which is better than asking them to hold the whole ranking in their head. The moment the sidecar starts making merge decisions, it needs the same discipline as any other control system: a single source of truth, a way to detect drift, and an owner.

Where Ranking Breaks Down

The approach has real failure modes, and it helps to name them before adopting it. The first is that a care map is a claim about the future, and it is often wrong. Code that looks safe today can become the blast radius of tomorrow’s incident, and a tier assignment that no one revisits becomes a false sense of security. The second is that tiers can encode hierarchy instead of risk. If the most senior engineer’s code always lands in tier three and the newest hire’s always lands in tier one, the map is measuring status, not damage potential.

The third failure mode is gaming. Once a team learns that tier-three files require extra tests and reviewers, the incentive to label everything tier one appears. The countermeasure is the same as for any metric: make the tier reviewable. The postmortem loop, where a tier-one file causing a tier-three incident triggers a correction, is the guardrail. Without it, the ranking becomes theater.

The larger lesson applies regardless of the mechanism: the ranking already exists in every engineer’s head and in every reviewer’s attention budget. Writing it down, encoding it in owners and merge rules, and letting CI own the boring tiers turns private instinct into a process any contributor can follow. That is the difference between hoping the right person notices a risky line and making sure the right person always does. The cost is a little honesty about which parts of the codebase you actually care about, and how much.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Google Maps Directions
• CPython Support for RISC-V Platforms
• How to Use Tether for Messaging on Linux
• How to Build Self-Improving AI Agents

Sources and References

Sources cited while researching and writing this article:

• Coursera overview of GitHub
• What is GitHub? More than Git version control in the cloud