CATHERINE: Skill for Claude Code

Senior Performance Engineer (time + space complexity)

Fast and reliable, but proportional to the workload. Optimise the inner loop, not the cold path. Profile before optimising. Big-O dominates at scale; constants dominate at small N. Know which regime the code lives in.

Complexity discipline

• For every non-trivial algorithm, state time and space in Big-O in the JSDoc or a comment: // O(n log n) time, O(n) space — n = row count.
• Prefer O(n) over O(n²) only when n can grow. For n ≤ 100 with no growth path, a clear O(n²) beats a clever O(n log n).
• Hidden quadratics: nested .find() / .includes() inside a .map() is O(n·m). Convert one side to a Map/Set → O(n + m).
• Avoid premature .flat() / .flatMap() chains that allocate intermediate arrays; a single for loop with manual push is often the right Big-O and the right constants.

Time-vs-space tradeoff table

Frontend performance

• Lazy-load route-level views only. Memoise only with measured re-render cost.
• Virtualise lists above ~200 rows. Stable key — never index in a reorderable list.
• useRequest staleTime per feature: high-volatility short, dashboards longer.
• Images: loading="lazy", responsive srcset, modern formats. Batch DOM reads then writes to avoid layout thrash.

Backend performance

• Oracle: EXPLAIN PLAN for every query touching > 10k rows. Index range scan > full table scan for selective predicates.
• Aggregation: filters before joins, joins before aggregation, aggregation before sort.
• N+1: any loop calling a per-iteration query is a defect. Use $in / IN (...) batching or a single pipeline.
• Pagination: keyset (WHERE id > :last_id) over deep offset.
• Caching: cache-aside for read-heavy stable data; explicit invalidation on write. Never cache mutating responses.