Clean Code and Engineering Standards - Module Overview

Reading time: ~18 minutes | Level: Foundation → Engineering

# This code works perfectly.
def p(d, f, s=0.1):
    r = []
    for i in d:
        if i['t'] == f:
            r.append(i['v'] * (1 - s))
    return r

Now read this version:

def get_discounted_prices(
    products: list[dict],
    category_filter: str,
    discount_rate: float = 0.10,
) -> list[float]:
    """Return discounted prices for all products in a given category."""
    return [
        product["price"] * (1 - discount_rate)
        for product in products
        if product["category"] == category_filter
    ]

Both produce identical output. Only one of them can be safely maintained by a team of engineers at 2 AM during an incident.

Clean code is not about aesthetics. It is about the engineering properties of software: correctness, maintainability, reliability, and the ability to evolve under pressure without introducing regressions. This module is about building those properties into your code from day one.

What You Will Learn

• Why code quality is a measurable engineering concern, not a matter of preference
• The Zen of Python - and how Python's design philosophy guides practical decisions
• What technical debt actually costs organizations (in hours, bugs, and engineer turnover)
• The spectrum from "code that works" to "production-grade code"
• How cognitive load in code correlates directly with bug rates
• The tools, techniques, and habits this module will cover
• The "boy scout rule" and how to apply it incrementally in a real codebase

Prerequisites

• Familiarity with Python syntax (variables, functions, classes, modules)
• Some experience reading other people's code and feeling confused by it
• An interest in writing software that holds up over time, not just code that passes a test

Why Code Quality is an Engineering Problem

Software engineers are not typists. They are not translators who convert English requirements into Python syntax. They are designers of systems that must be read, modified, debugged, extended, and understood - often by people who did not write them, often under time pressure, often months or years after the original author has left the company.

This is the key insight that separates a beginner's relationship with code quality from an engineer's. A beginner asks: "Does it work?" An engineer asks: "Does it work, and can I trust it to keep working as the system evolves?"

The Cognitive Load Argument

Herbert Simon's research on bounded rationality shows that human working memory can hold roughly 7 ± 2 "chunks" of information simultaneously. When you read code, each unexplained variable, each non-obvious function name, each surprising side effect consumes one of those slots. When all slots are full, you make mistakes.

Consider this function:

def proc(x, y, z=True):
    if z:
        x = x * 1.08
    return x - y if x > y else 0

Reading this function requires you to:

1. Guess what x, y, and z mean
2. Guess what multiplying by 1.08 represents (a tax rate? an inflation factor? a fee?)
3. Guess what the subtraction represents
4. Hold all of this in working memory while you try to understand the function's purpose

Now read the same logic written clearly:

def calculate_taxable_profit(
    revenue: float,
    expenses: float,
    apply_sales_tax: bool = True,
    sales_tax_rate: float = 0.08,
) -> float:
    """
    Return taxable profit after optionally applying sales tax to revenue.

    Returns 0.0 if expenses exceed taxable revenue.
    """
    taxable_revenue = revenue * (1 + sales_tax_rate) if apply_sales_tax else revenue
    profit = taxable_revenue - expenses
    return max(profit, 0.0)

The logic is identical. The cognitive load is radically different. The second version lets a reader understand the function in a single pass. The first version requires detective work.

This is not subjective. Studies on code comprehension (Buse & Weimer, 2010; Scalabrino et al., 2019) consistently show that code readability correlates with measured defect density. Harder-to-read code has more bugs. Not because programmers are careless, but because bounded working memory means that confusion leads to mistakes.

The Spectrum From "Works" to "Production-Grade"

Most tutorials stop at "it works." Production engineering starts there. Here is how the spectrum looks in practice:

Level	Characteristic	Who cares?
Level 0 - Broken	Crashes or gives wrong output	Everyone
Level 1 - Works	Produces correct output for happy path	Student, prototyper
Level 2 - Handles errors	Validates input, raises meaningful exceptions	Junior engineer
Level 3 - Readable	Named clearly, formatted consistently, documented	Team member
Level 4 - Testable	Functions are pure, side effects isolated	Senior engineer
Level 5 - Maintainable	Easy to change without breaking other things	Tech lead
Level 6 - Production-grade	Observable, versioned, deployable, reviewable	Staff engineer

Most professional codebases operate somewhere between Level 3 and Level 5. The gap between Level 1 and Level 3 is where most technical debt accumulates. This module focuses on climbing reliably from Level 1 to Level 4.

The Zen of Python

Run import this in any Python interpreter. You get Tim Peters' 19-line poem describing Python's design philosophy:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

These are not slogans. Each aphorism encodes a real engineering decision that the Python core team makes when adding features to the language. Let's unpack the most important ones with concrete examples.

Explicit is Better Than Implicit

# IMPLICIT - the function silently modifies the list in-place
def normalize(data):
    for i in range(len(data)):
        data[i] = data[i] / max(data)
    # returns None - caller may not realize the list was modified

# EXPLICIT - the function makes its contract clear
def normalize(data: list[float]) -> list[float]:
    """Return a new list with values scaled to [0, 1] range."""
    maximum = max(data)
    return [value / maximum for value in data]

The implicit version has two hidden behaviors: it mutates the input and it returns None. A caller who writes result = normalize(values) gets None, and the original list is permanently changed. These surprises cause bugs.

Simple is Better Than Complex

# COMPLEX - over-engineered for a simple task
class UserNameFormatter:
    def __init__(self, strategy="default"):
        self._strategy = strategy

    def format(self, first: str, last: str) -> str:
        if self._strategy == "default":
            return f"{first} {last}"
        elif self._strategy == "reversed":
            return f"{last}, {first}"

# SIMPLE - just write the function
def format_full_name(first: str, last: str) -> str:
    return f"{first} {last}"

def format_display_name(last: str, first: str) -> str:
    return f"{last}, {first}"

Design patterns have their place, but applying them to problems that do not need them adds complexity without adding value. Write the simplest code that solves the actual problem.

Flat is Better Than Nested

# DEEPLY NESTED - every level of nesting adds cognitive cost
def process_order(order):
    if order:
        if order.get("items"):
            if len(order["items"]) > 0:
                for item in order["items"]:
                    if item.get("price"):
                        if item["price"] > 0:
                            print(f"Processing: {item}")

# FLAT - early returns eliminate nesting
def process_order(order: dict) -> None:
    if not order:
        return
    items = order.get("items", [])
    if not items:
        return
    for item in items:
        price = item.get("price", 0)
        if price > 0:
            print(f"Processing: {item}")

Each level of indentation adds a mental frame that the reader must maintain. Flattening through early returns makes the happy path obvious and moves error handling to where it belongs - at the top, before you commit to doing work.

Errors Should Never Pass Silently

# SILENT FAILURE - swallows the exception, leaves caller with None
def load_config(path: str):
    try:
        with open(path) as f:
            return json.load(f)
    except Exception:
        pass  # <- This is almost always wrong

# EXPLICIT FAILURE - caller knows something went wrong
def load_config(path: str) -> dict:
    try:
        with open(path) as f:
            return json.load(f)
    except FileNotFoundError:
        raise FileNotFoundError(f"Config file not found: {path}")
    except json.JSONDecodeError as exc:
        raise ValueError(f"Config file is not valid JSON: {path}") from exc

Silent failures are debugging nightmares. The error disappears at the source and re-emerges as a confusing symptom somewhere else in the program.

What Technical Debt Actually Means

Ward Cunningham coined the term "technical debt" in 1992. It is a deliberate financial metaphor: just as taking on financial debt allows you to acquire something now at the cost of future interest payments, taking on technical debt allows you to ship faster now at the cost of future maintenance work.

The metaphor is useful because it makes the tradeoffs concrete. Debt is not always bad. A startup that needs to ship in two weeks to land a key customer may rationally choose to skip error handling and write procedural code. The important part is: acknowledge the debt and pay it down deliberately.

What engineers usually mean by "technical debt" in practice:

Type 1 - Intentional Short-Term Shortcuts

# TODO: replace with proper pagination when we have more than 1000 users
def get_all_users(db):
    return db.query(User).all()

This is acceptable debt if the comment exists, the team knows about it, and there is a plan to address it before it becomes a problem.

Type 2 - Accidental Complexity From Poor Design

# This evolved organically over 18 months and nobody knows how it works
def handle(req, ctx, extra=None, legacy=False, v2=False, flags=None):
    if legacy:
        if v2:
            # This branch was added when we migrated from v1 in 2022
            # and we can't remove it because prod still sends legacy=True
            ...

This debt was not intentional. It accumulated because nobody paid attention, nobody refactored, and everyone was afraid to touch it. This is the dangerous kind.

Type 3 - Outdated Dependencies and Patterns

A codebase that uses Python 2 syntax, or that relies on deprecated library APIs, or that uses patterns that were best-practice five years ago but are now considered harmful - this too is debt. It accumulates silently and explodes when you try to upgrade.

The True Cost of Technical Debt

Organizations rarely measure technical debt directly, but its costs show up in measurable ways:

• Onboarding time: New engineers in a clean codebase become productive in 2-4 weeks. In a messy codebase, the same engineer may take 3-6 months.
• Bug rate: Studies show that files with high complexity metrics (cyclomatic complexity above 10) are 3-5x more likely to contain defects.
• Deployment fear: When engineers are afraid to deploy because they do not understand what might break, velocity collapses. Features that should take a day take a week because of excessive caution.
• Engineer turnover: Experienced engineers leave organizations with chronically bad codebases. The best engineers are the most sensitive to code quality - and the most mobile.

The Cost of Messy Code in Real Numbers

Here is a simplified model to make the costs concrete. Suppose your team has 5 engineers at $150,000/year loaded cost (~$75/hour). Your codebase has a module that every engineer has to read once per week to make changes.

• Clean version: 15 minutes to understand, make a change, and test it
• Messy version: 90 minutes to understand, make a change, and test it

Extra cost per week per engineer: 75 minutes = 1.25 hours x $75 =$93.75 Extra cost per year (5 engineers, 50 weeks): $93.75 x 5 x 50 = **$23,437 per year - for one module**

A typical production codebase has dozens of such modules. This is why companies pay for refactoring sprints. This is why "rewrite from scratch" decisions get made when debt exceeds a threshold. The code was not just ugly - it was expensive.

What This Module Covers

This module covers the full stack of clean code practices for Python engineers working in professional settings:

Lesson	Topic	What You'll Build
01	PEP 8 and Style	Run flake8 on a messy codebase, fix every violation
02	Naming Conventions	Rename a module from abbreviation hell to readable English
03	Formatting and Tooling	Set up Black + isort + flake8 + mypy + pre-commit
04	Refactoring Techniques	Apply extract function, guard clauses, and decomposition
05	Code Smells	Identify and eliminate the 12 most common code smells
06	Docstrings and Documentation	Write Google-style docstrings, generate HTML docs with Sphinx
07	Project Structure	Organize a Python project like a senior engineer
08	CLI Design Principles	Build a professional CLI with argparse or Click
09	Version Control Basics	Git workflow, commit messages, branching for solo and team work

Each lesson includes real code, real tools, and practice challenges that simulate production scenarios.

The Boy Scout Rule

Robert C. Martin (author of Clean Code) articulates one of the most practical clean code habits as the "boy scout rule":

Always leave the code cleaner than you found it.

This is not a mandate to refactor everything before you can ship a feature. It is a habit of incremental improvement. Every time you touch a file, you make it slightly better:

• Rename a confusing variable while you're in the file anyway
• Add a missing type annotation to a function you just called
• Split a 50-line function into two named functions while adding a branch
• Replace a magic number with a named constant you encounter while debugging

Applied consistently by an entire team, this habit pays down technical debt continuously instead of allowing it to compound. No "refactoring sprints" needed - the codebase stays healthy because everyone is making tiny improvements constantly.

# You're in this file to add email validation.
# You notice the function name is vague. Rename it while you're here.

# BEFORE (what you found)
def check(u):
    return "@" in u and "." in u.split("@")[-1]

# AFTER (what you leave - two minutes of work)
def is_valid_email(address: str) -> bool:
    """Return True if address contains an @ and a dot in the domain."""
    parts = address.split("@")
    return len(parts) == 2 and "." in parts[1]

You did not need to rewrite the whole module. You made one function better. If ten engineers do this ten times a day, the codebase improves by 100 small increments per day - invisibly, without dedicated refactoring time.

The Mindset Shift

The most important thing this module teaches is not any specific rule or tool. It is a shift in how you think about code:

From: "Code is instructions for a computer." To: "Code is communication between engineers, with the computer as an incidental audience."

When you internalize this shift, every decision you make - what to name a variable, whether to extract a function, whether to add a comment - is made through the lens of: "Will the engineer who reads this 6 months from now (possibly me) understand it immediately?"

Python gives you more tools to write readable code than almost any other language: expressive syntax, list comprehensions, named function arguments, dataclasses, type annotations, f-strings. This module is about using those tools deliberately and systematically.

By the end of this module, you will have:

• A complete local toolchain (Black, isort, flake8, mypy, pre-commit) running on every project
• The vocabulary to identify and name code smells in code review
• The habits of naming, documenting, and structuring code that senior engineers use
• The ability to take a messy codebase and incrementally improve it without breaking it

Interview Questions

Q1: What is the difference between code that works and production-grade code?

Answer: Code that works produces correct output for the cases the author tested. Production-grade code handles edge cases and unexpected inputs, is readable by engineers who did not write it, is structured so that changes can be made safely, is observable (logs, metrics, errors surface meaningfully), and is covered by tests that verify behavior. The gap between "works" and "production-grade" is where most engineering effort lives. A senior engineer can often write working code quickly but invests additional effort in the properties that make it maintainable at scale.

Q2: What is technical debt, and is it always bad?

Answer: Technical debt is the implied cost of rework caused by choosing an expedient short-term solution over a more correct long-term approach. It is a deliberate metaphor to financial debt: the principal is the mess you created, the interest is the extra work every future change requires because of that mess. Debt is not always bad - intentional, acknowledged debt (e.g., skipping pagination for an MVP) is a rational tradeoff. Accidental, unacknowledged debt that accumulates because nobody noticed or nobody cared is dangerous and expensive. The key is explicit recognition and a plan to repay it.

Q3: What does "cognitive load" mean in the context of code quality?

Answer: Cognitive load refers to the mental effort required to understand a piece of code. Human working memory is limited - roughly 7 chunks simultaneously. Every unexplained variable, surprising side effect, and non-obvious control flow consumes cognitive capacity. When capacity is exhausted, engineers make mistakes. High-cognitive-load code correlates with higher defect density (documented in multiple empirical studies). Clean code minimizes cognitive load through clear naming, consistent structure, and explicit rather than implicit behavior - leaving mental capacity for reasoning about the actual problem rather than decoding the code itself.

Q4: What is the Zen of Python and why does it matter?

Answer: The Zen of Python is a set of 19 aphorisms by Tim Peters (import this in any Python REPL) that describe the guiding philosophy behind Python's design. Key principles include "explicit is better than implicit," "simple is better than complex," "readability counts," and "errors should never pass silently." These are not arbitrary opinions - they reflect design decisions made by the Python core team and represent a coherent philosophy about what makes software maintainable. Understanding them helps engineers make consistent, defensible decisions when the "right" choice is not obvious.

Q5: What is the boy scout rule in software engineering?

Answer: The boy scout rule, popularized by Robert C. Martin, states: "Always leave the code cleaner than you found it." It is a habit of incremental improvement applied during normal feature work - rename a confusing variable while you're in the file, add a missing type annotation, extract a helper function you need anyway. This prevents technical debt from compounding. Rather than scheduling dedicated refactoring sprints (which are expensive and often deprioritized), the boy scout rule distributes improvement across all normal development activity. Applied consistently across a team, it keeps codebases healthy without dedicated maintenance cost.

Q6: Why do experienced engineers leave organizations with poor code quality?

Answer: Senior and staff engineers have spent years developing strong opinions about how software should be built. Working in a codebase with poor quality creates constant friction: slow debugging, high cognitive load during code review, fear of deploying because the system is unpredictable, and the frustration of watching the same bugs recur. Experienced engineers are also the most mobile - they have strong networks and market demand for their skills - so they are the most likely to leave when conditions are poor. Organizations with consistently bad codebases thus lose their best engineers fastest, which accelerates the decay.

Practice Challenges

Beginner - The Translation Exercise

Take the following function and rewrite it to be readable. Do not change its behavior. Add a docstring, rename all variables, and restructure if needed:

def f(x, y, z=2):
    r = 0
    for i in x:
        if i > z:
            r += i * y
    return r

Solution

def sum_weighted_values_above_threshold(
    values: list[float],
    weight: float,
    threshold: float = 2.0,
) -> float:
    """
    Return the weighted sum of all values that exceed the threshold.

    Args:
        values: A list of numeric values to filter and sum.
        weight: Multiplier applied to each qualifying value.
        threshold: Minimum value required for inclusion (default 2.0).

    Returns:
        The sum of (value * weight) for all values above threshold.

    Example:
        >>> sum_weighted_values_above_threshold([1, 3, 5], weight=2.0)
        16.0  # (3 + 5) * 2.0
    """
    return sum(value * weight for value in values if value > threshold)

Why these choices:

• The function name is a verb phrase that describes exactly what the function does
• values, weight, and threshold communicate domain meaning without requiring a comment
• The docstring explains the contract: inputs, output, and an example that doubles as a test
• The list comprehension with sum() is idiomatic Python - one line of logic, readable as English

Intermediate - Identifying Debt in a Module

Read the following module and write a brief (5-10 bullet point) "technical debt audit" identifying every quality problem you can find. Then rewrite the worst function in the module.

import json, os, sys

data = []
cfg = {}

def init(p):
    global data, cfg
    try:
        f = open(p)
        cfg = json.load(f)
        f.close()
    except:
        pass

def proc(x):
    res = []
    for i in range(len(x)):
        t = x[i]
        if t != None:
            if type(t) == str:
                res.append(t.strip().lower())
            elif type(t) == int or type(t) == float:
                res.append(str(t))
    return res

def run():
    init("config.json")
    d = cfg.get("data", [])
    r = proc(d)
    for i in r:
        print(i)

Solution

Debt Audit:

1. import json, os, sys - imports on one line, os and sys are unused
2. data = [] and cfg = {} - mutable module-level globals with meaningless names
3. def init(p) - name is too short; p is untyped; no return type
4. Bare except: swallows ALL exceptions including KeyboardInterrupt - dangerous silent failure
5. f = open(p) - resource not managed with with statement; file may not close on exception
6. def proc(x) - name reveals nothing; x is untyped; uses range(len(x)) antipattern
7. t != None - should use is not None
8. type(t) == str - should use isinstance(t, str)
9. def run() - hardcodes "config.json" as a magic string; not testable
10. No type annotations anywhere; no docstrings anywhere

Rewritten proc function:

from typing import Union


def normalize_values(
    raw_values: list[Union[str, int, float, None]],
) -> list[str]:
    """
    Convert a mixed list of strings and numbers to normalized lowercase strings.

    None values and unsupported types are silently skipped.

    Args:
        raw_values: A list that may contain strings, integers, floats, or None.

    Returns:
        A list of stripped, lowercased strings.

    Example:
        >>> normalize_values(["Hello ", 42, None, 3.14])
        ['hello', '42', '3.14']
    """
    result = []
    for value in raw_values:
        if value is None:
            continue
        if isinstance(value, str):
            result.append(value.strip().lower())
        elif isinstance(value, (int, float)):
            result.append(str(value))
    return result

Advanced - Quantify the Debt

Write a Python script that analyzes a directory of Python files and produces a simple "code health report" for each file, reporting:

1. Average function name length (proxy for descriptiveness - very short names are suspicious)
2. Number of functions with no docstring
3. Number of bare except: clauses
4. Number of single-letter variable names outside of comprehensions

The script should output results as a formatted table.

Solution

"""
code_health_report.py - analyze Python files for basic code quality signals.

Usage:
    python code_health_report.py src/
"""

import ast
import sys
from pathlib import Path
from dataclasses import dataclass, field


@dataclass
class FileReport:
    path: str
    function_count: int = 0
    undocumented_functions: int = 0
    bare_excepts: int = 0
    single_letter_names: int = 0
    avg_function_name_length: float = 0.0


def analyze_file(path: Path) -> FileReport:
    """Parse a Python file and return a health report."""
    report = FileReport(path=str(path))
    source = path.read_text(encoding="utf-8")

    try:
        tree = ast.parse(source)
    except SyntaxError:
        return report

    function_name_lengths = []

    for node in ast.walk(tree):
        # Count functions and check for docstrings
        if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)):
            report.function_count += 1
            function_name_lengths.append(len(node.name))

            has_docstring = (
                node.body
                and isinstance(node.body[0], ast.Expr)
                and isinstance(node.body[0].value, ast.Constant)
                and isinstance(node.body[0].value.value, str)
            )
            if not has_docstring:
                report.undocumented_functions += 1

        # Count bare except clauses
        if isinstance(node, ast.ExceptHandler) and node.type is None:
            report.bare_excepts += 1

        # Count single-letter variable names in assignments
        if isinstance(node, ast.Name) and len(node.id) == 1 and node.id != "_":
            if isinstance(node.ctx, ast.Store):
                report.single_letter_names += 1

    if function_name_lengths:
        report.avg_function_name_length = sum(function_name_lengths) / len(
            function_name_lengths
        )

    return report


def print_report(reports: list[FileReport]) -> None:
    """Print a formatted table of code health metrics."""
    header = (
        f"{'File':<40} {'Funcs':>6} {'Undoc%':>7} "
        f"{'BareExc':>8} {'1-char':>7} {'AvgNameLen':>11}"
    )
    print(header)
    print("-" * len(header))

    for r in reports:
        undoc_pct = (
            (r.undocumented_functions / r.function_count * 100)
            if r.function_count
            else 0.0
        )
        print(
            f"{r.path:<40} {r.function_count:>6} {undoc_pct:>6.0f}% "
            f"{r.bare_excepts:>8} {r.single_letter_names:>7} "
            f"{r.avg_function_name_length:>11.1f}"
        )


def main(directory: str) -> None:
    base = Path(directory)
    if not base.is_dir():
        print(f"Error: {directory} is not a directory")
        sys.exit(1)

    python_files = sorted(base.rglob("*.py"))
    if not python_files:
        print(f"No Python files found in {directory}")
        return

    reports = [analyze_file(f) for f in python_files]
    print_report(reports)


if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python code_health_report.py <directory>")
        sys.exit(1)
    main(sys.argv[1])

Key design decisions:

• Uses Python's ast module to parse files accurately rather than using fragile string matching
• @dataclass makes the report structure explicit and self-documenting
• FileReport is separate from analysis logic - easy to extend with new metrics
• Single-responsibility functions: analyze_file collects data, print_report formats it
• Handles SyntaxError gracefully - bad files return empty reports rather than crashing the whole script

Quick Reference

Concept	What it means	Why it matters
Cognitive load	Mental effort to understand code	High load → more bugs, slower development
Technical debt	Cost of choosing expedient over correct	Compounds over time if unmanaged
Boy scout rule	Leave code cleaner than you found it	Prevents debt accumulation without dedicated sprints
Explicit > implicit	State assumptions, don't hide behavior	Surprises cause bugs and debugging time
Flat > nested	Use early returns to reduce indentation	Each nesting level adds mental overhead
Silent failures	Exceptions swallowed without logging	Errors surface as mysterious symptoms elsewhere
Production-grade	Works + readable + testable + maintainable	The standard for professional engineering

Key Takeaways

• Clean code is an engineering concern, not an aesthetic one - messy code is measurably more expensive to maintain, debug, and extend.
• Human working memory is limited to roughly 7 chunks; code that exceeds this forces mistakes. Readability is not a luxury - it is error prevention.
• Technical debt is a rational tool when used consciously. The danger is unacknowledged debt that compounds silently until the codebase becomes unmaintainable.
• The Zen of Python encodes a coherent design philosophy: explicit over implicit, simple over complex, flat over nested, errors visible rather than silent.
• The spectrum from "works" to "production-grade" spans at least 6 levels. Most professional work targets Level 3 (readable) through Level 5 (maintainable).
• The boy scout rule - leave code cleaner than you found it - is the most practical clean code habit because it distributes improvement across all normal work.
• This module gives you the tools (PEP 8, naming, Black, flake8, mypy, refactoring, docstrings, project structure) to move systematically from "it works" to "it lasts."