What Good Engineering Looks Like in Practice

Context

Good engineering is not what most people think it is. It is not the most clever solution, the most performant code, or the most sophisticated architecture. Good engineering is the kind that makes the next person's job easier, that survives contact with production, and that ages gracefully as requirements evolve.

This post describes what I have observed in systems and teams that I consider genuinely well-engineered, along with the characteristics that are often mistaken for good engineering but are not.

Characteristic 1: The Code Reads Like Prose

Good engineering produces code that communicates its intent. Not through comments explaining what the code does (the code itself should do that) but through naming, structure, and flow that make the reader nod rather than squint.

Signs of readable code:

• Function names describe what they do, not how they do it. calculateShippingCost over processOrderData.
• Variables are named for their role, not their type. remainingAttempts over int1.
• Control flow is linear. The happy path reads top to bottom. Error cases are handled early and exit early.
• Abstractions match the domain. A PaymentGateway interface makes sense to someone who understands the business domain, not just the code.

Signs of code that looks impressive but is not good engineering:

• Complex type-level programming that requires understanding the type system deeply to follow
• Deeply nested generics or template metaprogramming for marginal code reuse
• "Elegant" one-liners that compress logic into unreadable expressions
• Over-abstraction that adds layers without adding clarity

Characteristic 2: Errors Are Handled, Not Ignored

The difference between a prototype and production code is error handling. Good engineering treats errors as first-class citizens.

Related: Handling Partial Failures in Distributed Mobile Systems.

This means:

• Every external call has a timeout, a retry strategy, and a fallback. Not because the external service is unreliable, but because any external dependency can become unreliable.
• Error messages are specific and actionable. "Connection to payment-service timed out after 3000ms (attempt 2 of 3)" is useful. "An error occurred" is not.
• Errors propagate with context. When an error crosses a boundary, it carries enough context for the receiver to understand what happened without reading the source code.
• Partial failures are handled explicitly. If a batch operation processes 98 of 100 items successfully, the system knows which 2 failed and what to do about them.

Characteristic 3: The System Is Testable by Design

Good engineering does not add tests to a system that was designed without them. Good engineering designs the system so that testing is natural.

Testable design:

• Dependencies are injected, not created. A service receives its database connection, not creates it internally. This makes it possible to substitute a test database.
• Side effects are pushed to the edges. Pure business logic in the core, I/O at the boundaries. The core is easy to test in isolation.
• State is explicit. The system's state is visible and inspectable, not hidden in closures or global variables.
• Contracts are defined. Each module or service has a clear contract (inputs, outputs, invariants) that can be verified independently.

Characteristic 4: Deployments Are Boring

In well-engineered systems, deployments are non-events. Nobody holds their breath. Nobody watches dashboards nervously. The deployment pipeline handles validation, rollout, and monitoring automatically.

What makes deployments boring:

• Automated testing catches regressions before deployment
• Progressive rollout limits the blast radius of any issue
• Automated rollback triggers if key metrics degrade
• The deployment pipeline is the same for every service (no snowflakes)
• Zero-downtime deployment is the default, not a special procedure

When deployments are exciting, it means the system lacks the safety nets that would make them routine. That is a design problem.

Characteristic 5: The System Explains Itself

Good engineering produces systems that can answer questions about their own behavior. Not through external documentation that goes stale, but through built-in observability.

A system that explains itself:

• Exposes health check endpoints that report on each subsystem
• Emits metrics that capture both technical (latency, error rate) and business (orders processed, payments completed) behavior
• Produces structured logs that can reconstruct the decision path for any request
• Supports distributed tracing across service boundaries
• Has dashboards that answer "is the system healthy?" in under 10 seconds

Characteristic 6: Changes Are Safe

The ability to change a system safely is the clearest sign of good engineering. A system where every change is risky is a system with accumulated design debt.

Safe changeability requires:

• Low coupling: Changing one component does not require changing others.
• Comprehensive tests: Regressions are caught before they reach production.
• Clear contracts: The boundary between components is well-defined, so changes within a component do not leak.
• Backward compatibility: New versions can coexist with old versions during rollout.
• Feature flags: New behavior can be enabled and disabled without redeployment.

What Good Engineering Is Not

Key Takeaways

See also: Designing Event Schemas That Survive Product Changes.

• Good engineering is code that reads clearly, handles errors thoroughly, and deploys without drama.
• Testability is a design property, not something added after the fact.
• A system that explains itself through observability is more valuable than a system with external documentation.
• Safe changeability is the clearest indicator of engineering quality. If changes are risky, the design has accumulated debt.
• Good engineering is often boring. It is the absence of surprises, not the presence of sophistication.
• The right measure of engineering quality is how easy it is for the next person to work with the system.

---

Further Reading

• Engineering Principles I Apply Across Domains: Universal engineering principles that hold true regardless of language, framework, domain, or scale, distilled from years of building pro...
• How I Think About Engineering Risk: A framework for identifying, categorizing, and managing engineering risk across system design, team dynamics, and operational decisions.
• Engineering Decisions That Reduce Pager Fatigue: Architectural and operational decisions that reduce the frequency and severity of production pages, based on patterns from years of on-ca...

Final Thoughts

The best-engineered systems I have worked on shared a common trait: they were unremarkable. The code was clear but not clever. The architecture was simple but not simplistic. The deployments were routine. The on-call rotation was quiet. There was nothing to write a conference talk about because everything just worked. That is what good engineering looks like in practice.