algorithm-pseudocode-design

Algorithm & Pseudocode Design

Design the algorithm before committing to a language's syntax. Pseudocode forces you to separate "what is the logic" from "how does this language express it" — bugs found at this stage are far cheaper than bugs found after a full implementation.

When to use

• The algorithm is non-trivial: non-obvious data structure choice, tricky control flow, concurrency, or a correctness property that's easy to get subtly wrong (rate limiting, cache eviction, ranking/scoring).
• Complexity matters and hasn't been thought through yet — "this might be O(n²) on the hot path" is worth catching on paper.
• Skip for code that's a direct, obvious translation of the requirement (simple CRUD, straightforward glue/plumbing) — pseudocode adds no value there.

Structure and syntax

Keep it language-agnostic — no language-specific syntax, so the logic reads the same regardless of what it'll be implemented in:

ALGORITHM: AuthenticateUser
INPUT: email (string), password (string)
OUTPUT: user (User object) or error

BEGIN
    IF email is empty OR password is empty THEN
        RETURN error("Invalid credentials")
    END IF

    user ← Database.findUserByEmail(email)
    IF user is null THEN
        RETURN error("User not found")
    END IF

    isValid ← PasswordHasher.verify(password, user.passwordHash)
    IF NOT isValid THEN
        SecurityLog.logFailedLogin(email)
        RETURN error("Invalid credentials")
    END IF

    session ← CreateUserSession(user)
    RETURN {user: user, session: session}
END

Data structure selection

Name the structure, its complexity per operation, and why it was chosen over the alternatives — not just what it is:

UserCache:
    Type: LRU cache with TTL
    Purpose: reduce DB queries for active users
    Operations: get O(1), set O(1), evict O(1)

PermissionTree:
    Type: trie (prefix tree)
    Purpose: efficient hierarchical permission checks
    Operations: hasPermission(path) O(m), m = path length