Code Quality

Code Quality

Commitment to Quality

Engineering Excellence is not a hobby; it is our survival strategy. We are facing significant technical debt that slows us down. This stops today.

We are raising the bar. We are moving from “Getting it done” to “Getting it done right.”

Why this matters to you

As an engineer at this company, you are not just a coder, you are an architect of our future.

TLDR;

  1. Delivering a feature with poor code quality is NOT a delivery. It is a liability.
  2. If it’s not testable, maintainable, and robust, it does not go to production.

Ownership & Accountability

Quality is not a “Nice-to-Have”. It is your Job Description.

Your Code is Your Signature

  • Total Ownership: You are responsible for every line of code you write, from the IDE to Production. Do not rely on QA to catch your bugs. Do not rely on SRE to fix your alerts.
  • Code Review is a Gate, Not a Rubber Stamp:
    • For Authors: Submitting sloppy code to a reviewer is disrespectful. It shows a lack of ownership.
    • For Reviewers: Approving bad code makes you equally responsible for the outage it causes.

Clarify the Consequences

Let’s be transparent about how quality impacts your career here:

  1. Performance & Promotion: You cannot be promoted to a Senior level or above if you generate technical debt. High output with low quality is negative performance.
  2. PIP (Performance Improvement Plan): Consistently merging code that breaks builds, lacks tests, or violates standards will trigger a formal performance review.
    • We hire engineers to solve problems, not to create cleanup work for others.

What “Good” Looks Like

We define high quality through Engineering Principles, not personal opinions.

1. Maintainability > Cleverness

Code is read 10 times more often than it is written.

  • Reject: Complex one-liners, “magic” logic, and over-engineering.
  • Accept: Boring, predictable, and obvious code.

2. Zero Broken Windows

We do not walk past mistakes.

  • Legacy Code: “I didn’t write it” is not an excuse to leave it broken. If you touch a file, leave it cleaner than you found it (The Boy Scout Rule).
  • Technical Debt: We pay our debts. We do not declare bankruptcy.

3. Automated Quality

  • Trust the Tools: If the CI pipeline fails, you failed. Fix it.
  • Test Coverage: No tests = No merge. This is non-negotiable.

The Rules of Game

We follow Industry Standards. We do not waste valuable engineering cycles debating syntax. We adopt the best-in-class standards and enforce them ruthlessly via tooling.

Tooling: The Enforcers

We use tools to remove human error. Bypassing these tools is a violation of engineering protocol.

How tooling enforces quality in the SDLC 

  flowchart TD
    A[Code in IDE] --> B[Format on Save]
    B --> C[Pre-commit Hooks：format + lint + quick tests]
    C --> D[Push / PR]
    D --> E[CI Pipeline：lint + typecheck + unit tests]
    E --> F[Quality Gates： SonarQube / SAST]
    F -->|pass| G[Merge]
    F -->|fail| X[Fix & Iterate]
    G --> H[CD Deploy]
    H --> I[Runtime Observability： logs + metrics + traces]
    I --> J[Feedback Loop： postmortems + rule updates]
    X --> C
    J --> A

Feedback Loop

We are not perfect. We are always learning. We welcome feedback on this document. If you have suggestions, please comment on this document or email us at Engineering Excellence Initiative.