Code Reviews That Champion Simplicity: What to Look for and How to Say It

SEO Metadata

SEO Title Options

1. Code Reviews That Champion Simplicity: What to Look for
2. Code Reviews That Champion Simplicity: Practical 2026
3. Engineering Playbook: Code Reviews That Champion

Meta Description Options

1. Learn Code Reviews That Champion Simplicity with a practical Engineering framework, expert mistakes, implementation steps, examples, FAQ, and schema-ready.
2. Gives reviewers a practical vocabulary for identifying and discussing unnecessary complexity without discouraging experimentation.

URL Slug

code-reviews-champion-simplicity-what-look-how-say-it

Focus Keyword

Code Reviews That Champion Simplicity

Additional LSI Keywords

• Engineering
• Code Review
• Simplicity
• Refactoring
• Team Practices
• Code Reviews That Champion Simplicity: What to Look for and How to Say It
• production checklist
• implementation guide
• best practices
• architecture decisions
• testing strategy
• performance impact

Table of Contents

• Article overview
• What Code Reviews That Champion Simplicity means
• Why it matters now
• Implementation framework
• Practical comparison
• Expert workflow
• Common mistakes
• Media and link plan
• Original technical deep dive
• FAQ
• Structured data
• Conclusion

Article overview

Code Reviews That Champion Simplicity is the kind of topic that looks simple until it reaches production. Teams usually discover the real cost late: unclear boundaries, weak defaults, hidden maintenance work, and decisions that seemed harmless when the codebase was small.

The problem gets worse when the article, tutorial, or implementation guide only explains the happy path. This guide closes that gap with a practical framework, a comparison table, common mistakes, and a deep technical section you can use while planning real work.

Keep reading for the non-obvious part: the safest implementation is rarely the most impressive-looking one. It is the one your team can debug, test, document, and evolve without turning every future change into archaeology.

Key Takeaways

• Code Reviews That Champion Simplicity should be evaluated as a production decision, not only as a syntax or tooling choice.
• The best implementation keeps responsibilities visible, with clear ownership, tests, documentation, and rollback paths.
• Search visibility improves when practical depth, structured answers, and expert examples live on the same page.

[IMAGE: A mobile-first technical article layout showing the main concept, decision table, implementation checklist, and FAQ blocks. Alt: Code Reviews That Champion Simplicity expert guide for Engineering]

What Code Reviews That Champion Simplicity means

Code Reviews That Champion Simplicity means applying engineering knowledge to a concrete engineering decision, then turning that decision into reliable code, documentation, and operational behavior. In practice, it combines the topic's core concepts with trade-off analysis, implementation boundaries, testing strategy, and maintenance discipline.

This is the definition worth optimizing for featured snippets because it avoids hype. It tells the reader what the topic does and what a professional implementation must include.

Why it matters now

The technical web is more crowded than it was a few years ago. Thin tutorials can still get indexed, but they rarely earn trust from senior developers, buyers, AI answer systems, or teams that need production guidance.

For engineering topics, the strongest content now has three layers:

• a clear answer for fast scanning
• a practical framework for implementation
• expert context that explains what breaks later

That same structure helps search engines understand the page. It also helps readers decide whether the advice fits their project.

Implementation framework

Use this framework before adopting the approach described in this article.

1. Define the user problem and the production risk.
2. Identify the smallest reliable implementation boundary.
3. Keep configuration, secrets, and environment-specific behavior outside the article's core logic.
4. Add tests for the behavior that would hurt if it regressed.
5. Document the trade-off, not only the final code.
6. Measure the result with logs, metrics, or user-facing outcomes.
7. Revisit the decision after real usage exposes edge cases.

The sequence is deliberately conservative. It keeps the work grounded in outcomes instead of novelty.

[IMAGE: A seven-step implementation framework with discovery, boundary design, configuration, tests, documentation, measurement, and iteration. Alt: Code Reviews That Champion Simplicity implementation framework]

Practical comparison

This table is intentionally practical. It gives a reviewer something to check before the implementation becomes expensive to change.

Expert workflow

Expert tip: "Treat Code Reviews That Champion Simplicity as a system boundary. If the next developer cannot find where the decision lives, how it is tested, and when it should be avoided, the implementation is not finished."

A useful workflow is simple:

• Start with the smallest working example.
• Add the constraints that exist in your real project.
• Remove anything that only demonstrates cleverness.
• Write down the failure modes.
• Add links to related decisions so future readers can navigate the topic cluster.

That last point matters for both humans and search systems. A single article can answer a question; a cluster proves authority.

Common mistakes

Mistake 1: Copying a pattern without its context

A pattern that works in a small demo can fail in a real application. The missing context is usually data volume, team experience, deployment process, security requirements, or observability.

Before copying the pattern, ask what assumption made it safe in the original example.

Mistake 2: Putting business logic in the wrong layer

This is the fastest way to make future debugging expensive. In Laravel, PHP, and server-rendered websites, presentation should receive prepared data, not discover rules on its own.

Keep decision logic in models, actions, services, policies, requests, jobs, or documented helpers where it can be tested directly.

Mistake 3: Optimizing for novelty instead of maintainability

Newer tools and language features can be valuable. They can also hide simple behavior behind unfamiliar syntax.

Use the option that makes the next production incident easier to understand.

Mistake 4: Publishing without a measurement plan

If the article describes a performance, SEO, security, or architecture improvement, define how success will be checked. Logs, tests, crawl diagnostics, analytics, and user behavior are all stronger than assumptions.

[IMAGE: A common-mistakes board with context loss, wrong layer, novelty bias, and missing measurement highlighted. Alt: Code Reviews That Champion Simplicity common mistakes]

Media and link plan

Image placeholders

• [IMAGE: A concept diagram for Code Reviews That Champion Simplicity with input, decision boundary, implementation, tests, and production feedback. Alt: Code Reviews That Champion Simplicity concept diagram]
• [IMAGE: A mobile screenshot-style checklist for Code Reviews That Champion Simplicity: What to Look for and How to Say It. Alt: Code Reviews That Champion Simplicity mobile checklist]
• [IMAGE: A comparison table visualization for strong versus weak implementation choices. Alt: Code Reviews That Champion Simplicity comparison table]

Video placeholder

[VIDEO: Insert a 5-8 minute YouTube walkthrough that demonstrates the main decision, the implementation boundary, the test strategy, and the production caveats for Code Reviews That Champion Simplicity.]

Trustworthy outbound links

• Google Search quality guidance - use this as the trust reference for people-first content and E-E-A-T alignment.

Internal linking opportunities

• Internal guide: The YAGNI Principle in Practice: Shipping - use this when readers need a related Engineering follow-up.
• Internal guide: Simplicity at Scale: How Great Engineering - use this when readers need a related Engineering follow-up.

Original Technical Deep Dive

Code review should make code easier to change.

That does not happen when reviewers only say:

This feels over-engineered.
Can we make this simpler?
I do not like this abstraction.
This is too clever.

Those comments may be correct, but they are not useful enough. They sound like taste. The author has to guess what to change, what is blocking, and whether the reviewer is objecting to the idea, the implementation, or the timing.

A simplicity-focused review needs better language.

The short version

Good simplicity review has three parts:

The goal is not to reject experimentation. The goal is to keep experiments visible, reversible, and cheaper than the uncertainty they are meant to resolve.

Review simplicity, not personal style

Simplicity is not:

• the fewest lines
• the fewest classes
• your preferred pattern
• avoiding all abstraction
• copying what the reviewer would have written

Simplicity is code whose behavior, dependencies, and change path are easy to understand.

This is the review question:

Does this change make the next correct change easier or harder?

That question keeps the review technical. It avoids turning feedback into "I would write it differently."

Use labels before opinions

Labeling feedback helps authors separate blockers from optional ideas.

Use a small vocabulary:

Example:

issue (complexity): This introduces a plugin registry, but this feature has only one
payment provider today. Could we keep a direct `StripePayments` adapter for now and
extract a registry when a second provider is actually added?

That comment is direct. It is also fair:

• it names the concern
• it explains the current evidence
• it offers a smaller design
• it leaves room for the author to show missing context

What to look for

When reviewing for simplicity, scan for these complexity patterns.

[IMAGE: Supporting visual 1 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 1]

[IMAGE: Supporting visual 1 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 1]

Do not reject a pattern by name. Reject the cost it creates in this change.

Pattern 1: abstraction before evidence

Before:

<?php

declare(strict_types=1);

interface InvoiceExportDriver
{
    public function export(Invoice $invoice): ExportedFile;
}

final class InvoiceExportManager
{
    /**
     * @param array<string, InvoiceExportDriver> $drivers
     */
    public function __construct(private array $drivers)
    {
    }

    public function export(string $driver, Invoice $invoice): ExportedFile
    {
        if (! isset($this->drivers[$driver])) {
            throw new InvalidArgumentException("Unknown export driver [$driver].");
        }

        return $this->drivers[$driver]->export($invoice);
    }
}

final class PdfInvoiceExportDriver implements InvoiceExportDriver
{
    public function export(Invoice $invoice): ExportedFile
    {
        return new ExportedFile(
            name: 'invoice-'.$invoice->number.'.pdf',
            contents: render_invoice_pdf($invoice),
        );
    }
}

If the requirement is "download invoice as PDF," the manager and interface may be premature.

Poor review comment:

This is over-engineered.

Better:

issue (complexity): This creates a driver registry, but the product only supports PDF
export in this change. That makes readers understand a multi-driver system before one
exists. Could we start with a concrete `PdfInvoiceExporter` and extract the driver
interface when a second export format lands?

Smaller version:

<?php

declare(strict_types=1);

final class PdfInvoiceExporter
{
    public function export(Invoice $invoice): ExportedFile
    {
        return new ExportedFile(
            name: 'invoice-'.$invoice->number.'.pdf',
            contents: render_invoice_pdf($invoice),
        );
    }
}

The smaller version still has a boundary. It just does not pretend the variation exists yet.

Pattern 2: generic names hide decisions

Before:

<?php

declare(strict_types=1);

final class Processor
{
    public function handle(array $data): Result
    {
        if ($data['type'] === 'refund') {
            return $this->run($data);
        }

        return Result::skipped();
    }

    private function run(array $data): Result
    {
        // ...
    }
}

Poor review comment:

Bad names.

Better:

suggestion (readability): `Processor`, `handle`, `data`, and `run` do not expose the
business decision here. Could these names describe the refund workflow directly, for
example `RefundEligibility`, `decisionFor`, and `RefundRequest`?

Possible rewrite:

<?php

declare(strict_types=1);

final readonly class RefundRequest
{
    public function __construct(
        public int $orderId,
        public int $amountCents,
        public string $reason,
    ) {
    }
}

final class RefundEligibility
{
    public function decisionFor(RefundRequest $request): RefundDecision
    {
        if ($request->amountCents < 1) {
            return RefundDecision::rejected('Refund amount must be positive.');
        }

        return RefundDecision::manualReview();
    }
}

The review comment does not just demand "better names." It explains which decision is hidden.

Pattern 3: comments explain complexity that should be removed

Before:

<?php

declare(strict_types=1);

final class SubscriptionAccess
{
    public function canUseFeature(User $user, Feature $feature): bool
    {
        // We need this because public features are allowed for active users even
        // if they have no subscription, but private features need an active plan.
        if ($user->isActive() && ! $user->isSuspended() && ($feature->isPublic()
            || ($user->subscription() !== null && $user->subscription()->isActive()
                && $user->subscription()->plan()->includes($feature)))) {
            return true;
        }

        return false;
    }
}

Poor review comment:

This comment is too long.

Better:

issue (readability): The comment is explaining control flow that the code could express
directly. Could we split the public-feature path from the subscription path so future
readers do not have to mentally parse this condition?

Possible rewrite:

<?php

declare(strict_types=1);

final class SubscriptionAccess
{
    public function canUseFeature(User $user, Feature $feature): bool
    {
        if (! $user->isActive() || $user->isSuspended()) {
            return false;
        }

        if ($feature->isPublic()) {
            return true;
        }

        $subscription = $user->subscription();

        if ($subscription === null || ! $subscription->isActive()) {
            return false;
        }

        return $subscription->plan()->includes($feature);
    }
}

Sometimes comments are right. Comments should explain why a decision exists, not compensate for tangled code.

Pattern 4: events hide synchronous requirements

Before:

<?php

declare(strict_types=1);

final class MarkInvoicePaid
{
    public function handle(Invoice $invoice): void
    {
        $invoice->markPaid();

        event(new InvoiceWasPaid($invoice->id));
    }
}

final class SendReceiptListener
{
    public function handle(InvoiceWasPaid $event): void
    {
        $invoice = Invoice::findOrFail($event->invoiceId);

        Mail::to($invoice->customerEmail)->send(new ReceiptMail($invoice));
    }
}

Events can be a good boundary. They are not automatically simpler.

Poor review comment:

I do not like events here.

Better:

question (behavior): Does receipt sending have to succeed before we consider the invoice
payment complete? If yes, the event makes the required order less visible. A direct
`ReceiptSender` call inside the use case may be clearer. If this should be async, can we
add retry and failure visibility in this change?

Possible synchronous version:

<?php

declare(strict_types=1);

final class MarkInvoicePaid
{
    public function __construct(private ReceiptSender $receipts)
    {
    }

    public function handle(Invoice $invoice): void
    {
        $invoice->markPaid();

        $this->receipts->sendFor($invoice);
    }
}

The right answer depends on behavior. The review comment asks for that behavior instead of arguing from pattern preference.

Pattern 5: tests duplicate the implementation

Before:

<?php

declare(strict_types=1);

it('calculates invoice status', function () {
    $invoice = InvoiceFactory::new()
        ->withLine(quantity: 2, unitPriceCents: 1000)
        ->withLine(quantity: 1, unitPriceCents: 500)
        ->withPayment(amountCents: 2500)
        ->create();

    $expected = 0;

    foreach ($invoice->lines as $line) {
        $expected += $line->quantity * $line->unit_price_cents;
    }

    $paid = 0;

    foreach ($invoice->payments as $payment) {
        $paid += $payment->amount_cents;
    }

    expect($invoice->status())->toBe($paid >= $expected ? 'paid' : 'open');
});

Poor review comment:

The test is messy.

Better:

issue (test): The test recomputes the same algorithm as the production code, so both can
share the same mistake. Could the assertion use named examples instead: one fully paid
invoice is `paid`, one underpaid invoice is `open`, and one overpaid invoice is `paid`?

Possible rewrite:

<?php

declare(strict_types=1);

it('marks a fully paid invoice as paid', function () {
    $invoice = invoiceWithTotal(2500);

    $invoice->recordPayment(2500);

    expect($invoice->status())->toBe(InvoiceStatus::Paid);
});

it('keeps an underpaid invoice open', function () {
    $invoice = invoiceWithTotal(2500);

    $invoice->recordPayment(1000);

    expect($invoice->status())->toBe(InvoiceStatus::Open);
});

Tests should simplify the behavior for reviewers. If the test needs a debugger, the production code probably is not the only problem.

Pattern 6: scope grows inside the review

Simple reviews depend on simple changes.

Watch for pull requests that combine:

• behavior change
• broad renaming
• formatting churn
• dependency upgrade
• database migration
• test framework cleanup
• unrelated TODO removal

Poor review comment:

This PR is too big.

Better:

issue (scope): This mixes the invoice bug fix with a repository rename and PHP-CS-Fixer
output. Could we split the mechanical rename and formatting into separate PRs? I can
review the behavior safely once the diff only shows the payment change.

That comment explains the reviewer risk. It is not a complaint about line count.

Pattern 7: configuration replaces code without reducing ownership

Before:

<?php

declare(strict_types=1);

return [
    'refunds' => [
        'manual_review_threshold_cents' => env('REFUND_MANUAL_REVIEW_THRESHOLD', 50000),
        'auto_approve_roles' => explode(',', env('REFUND_AUTO_APPROVE_ROLES', 'admin')),
        'workflow' => env('REFUND_WORKFLOW', 'default'),
    ],
];

Configuration is useful when operators need to change behavior safely. It is not always simpler than code.

Poor review comment:

Why is all of this configurable?

Better:

question (operability): Who will change these refund settings, and how will they verify
the result? If only developers change them through deploys, constants in the refund policy
may be easier to search, test, and review.

If the author answers that support staff need runtime control, then the review should move to guardrails:

suggestion (operability): If support owns this threshold, can we add min/max validation
and an audit log for changes? That would make the runtime flexibility safer.

Simplicity is contextual. Runtime configuration can be simpler for operations and more complex for developers. The review should name that trade-off.

[IMAGE: Supporting visual 2 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 2]

How to say "simpler" without shutting down the author

Use this structure:

<label> (<area>): <specific concern>.
<why this matters>.
<smaller option or question>.

Examples:

[IMAGE: Supporting visual 2 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 2]

The better comments point at code, not character. They ask for evidence, not obedience.

Blockers vs suggestions

Not every simplicity comment should block a merge.

Block when:

• the new complexity can create bugs
• the behavior is unclear
• the abstraction has no current use and affects public design
• the code is hard enough that future maintenance is risky
• the change makes rollback, testing, or deployment harder
• the PR degrades a shared boundary

Do not block when:

• the issue is naming polish in a private helper
• the author chose a valid local style
• the design is slightly different from your preference
• the abstraction is small and isolated
• a follow-up is safer than expanding the current diff
• the PR is an incremental improvement over worse existing code

Useful labels:

issue (blocking): ...
suggestion (non-blocking): ...
nit (non-blocking): ...
thought (follow-up): ...

If everything is blocking, nothing is prioritized.

Protect experimentation

Simplicity review should not punish learning.

Experiments are useful when they are:

[IMAGE: Supporting visual 3 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 3]

• named as experiments
• scoped to a small surface
• protected by tests
• hidden behind a reversible path
• documented with the question they answer
• deleted or promoted after the result is known

Good review comment:

suggestion (experiment): I like trying the rule-object approach here. Could we keep it
inside the discounts module for now and avoid making it a shared framework until we know
whether the next two rules need the same shape?

Another:

question (experiment): What result would tell us this abstraction worked? If the answer is
"we will know after the next campaign," can we add a follow-up issue to either generalize
or collapse it after that campaign ships?

This supports experimentation without letting every experiment become permanent architecture.

Ask for evidence

When the author says "we will need this later," ask for the evidence calmly.

Useful questions:

Which current requirement uses this?
Which next planned change becomes cheaper?
Is there a ticket, customer commitment, or incident behind this?
How would we add that future case if we kept this simple now?
What is expensive to change later?
What is expensive to carry now?

Example:

question (YAGNI): The new registry seems designed for multiple tax providers. Do we have
a committed second provider, or is this preparing for a possible future? If it is only
possible, I would rather keep the one-provider path direct and revisit when the second
provider has real requirements.

That is firmer than "maybe YAGNI" and easier to answer.

Accept good explanations

Sometimes the author has context you missed.

Reviewer:

question (complexity): This queue job adds retries and failure state around a simple email.
What production case needs that instead of sending directly?

Author:

Enterprise customers have 2,000-user imports. Sending inside the request timed out twice
last week. The job is also required so support can retry failed invites.

Good reviewer response:

That context makes sense. Could you add a short note to the PR description and a test for
retrying a failed invite? The queue boundary looks justified with that behavior captured.

Do not make the author win an argument twice. Once they provide good evidence, move the review forward.

Do not let review-only explanations carry the design

If a reviewer asks, "Why is this needed?" and the author explains a real domain rule, put that explanation where future readers will find it.

Options:

• rename the method
• extract a named policy
• add a test with the business case
• add a short code comment for non-obvious rationale
• update the PR description or ADR if the decision is architectural

Review comment:

suggestion (documentation): Your explanation about refunds after chargeback windows is
important, but it will disappear after this review. Could we capture it in the test name or
a short comment near `RefundWindowPolicy`?

Code review tools are not documentation.

Praise simple choices

Reviewers often comment only when something is wrong. That trains authors to see review as defense.

Praise specific simplicity:

praise: Keeping this as a direct `ReceiptSender` call makes the failure order obvious.
That is easier to reason about than an event for this synchronous path.

praise: The guard clauses make the invalid states clear. This will be easier to extend
when the next subscription rule arrives.

praise: This test names the business case instead of duplicating the implementation.
Good pattern to reuse in the rest of this file.

Specific praise is not fluff. It reinforces the engineering behavior you want repeated.

[IMAGE: Supporting visual 3 for Code Reviews That Champion Simplicity: What to Look for and How to Say It, showing Code Reviews That Champion Simplicity decisions, examples, and Engineering, Code Review, Simplicity. Alt: Code Reviews That Champion Simplicity code-reviews-champion-simplicity-what-look-how-say-it visual 3]

Handle pushback without turning review into a debate

Pushback is normal.

Use this sequence:

Restate the author's goal.
Name the code-health risk.
Ask for evidence or offer the smaller path.
Escalate synchronously if the thread becomes circular.
Record the final decision.

Example:

I understand the goal: make future payment providers easier to add.

My concern is that the registry adds indirection to the only provider we have today, and
every checkout change now has to understand provider resolution.

If we have a committed second provider this quarter, I am fine keeping the interface and
would like a test showing provider selection. If not, I think `StripePayments` is the
better first step and we can extract the interface when the second provider lands.

This is not soft. It is clear.

A reviewer checklist for simplicity

Before submitting review comments, ask yourself:

Did I separate blockers from suggestions?
Did I explain the cost of the complexity?
Did I point to code, behavior, or maintenance risk?
Did I avoid making it about the author's skill?
Did I offer a smaller alternative?
Did I accept valid context from the author?
Did I praise simple choices worth repeating?
Did I keep review-only explanations from becoming hidden design docs?

If the answer is no, rewrite the comment before posting it.

A team standard for simplicity reviews

Teams can make this explicit:

### Simplicity review standard

Reviewers may block a change when new complexity is not justified by current behavior,
production risk, or a committed near-term requirement.

When blocking for simplicity, reviewers must:

- identify the complexity being added
- explain the maintenance or behavior risk
- suggest a smaller alternative or ask for missing evidence

Authors may keep the more complex design when they provide evidence that it reduces a
real cost, protects a real boundary, or supports a committed requirement.

Optional ideas must be labeled as non-blocking.

This removes a lot of social friction. The reviewer is not being difficult. The team agreed that complexity needs evidence.

FAQ

What is Code Reviews That Champion Simplicity?

Code Reviews That Champion Simplicity is a practical engineering topic that should be evaluated through implementation scope, production risk, testing, documentation, and long-term maintainability.

When should a team use Code Reviews That Champion Simplicity?

Use Code Reviews That Champion Simplicity when it solves a real project constraint, improves clarity, or reduces operational risk. Avoid it when it only adds novelty or hides behavior from future maintainers.

What is the biggest risk with Code Reviews That Champion Simplicity?

The biggest risk is copying a pattern without its context. Production systems need clear boundaries, rollback options, tests, and observability before a technique becomes dependable.

How do you test Code Reviews That Champion Simplicity?

Test the smallest unit that owns the behavior, then add integration coverage for the path users or systems actually rely on. Include failure cases, configuration differences, and regression checks.

How does Code Reviews That Champion Simplicity affect SEO and AI search visibility?

It improves visibility when the article gives a direct answer, expert context, structured headings, internal links, trustworthy references, and FAQ content that matches the visible page.

Conclusion

Code Reviews That Champion Simplicity is worth doing when the implementation improves clarity, reliability, or delivery speed. It is not worth doing when it hides ownership, increases operational risk, or makes the system harder to explain.

Use the framework above as a review checklist. Then connect this topic to the rest of the project documentation so readers can move from concept to implementation without losing context.