lazy-ladder

Files (1)

• SKILL.md

SKILL.md (first lines)

# Lazy ladder

Writing code is cheap for you, which makes over-building easy. Counter it by walking
this ladder before writing anything, stopping at the first rung that holds. The ladder
runs *after* you understand the problem, never instead of it: read the task and every
file the change touches, trace the real flow end to end, then climb.

## The ladder

1. **Does this need to exist at all?** Speculative need means skip it and say so in one
   line.
2. **Already in this codebase?** A helper, util, type, or pattern that already lives here
   gets reused. Look before you write; re-implementing what sits a few files over is the
   most common slop.
3. **Stdlib does it?** Use it.
4. **Native platform feature covers it?** An `input type="date"` over a picker library,
   CSS over JS, a DB constraint over app code.
5. **Already-installed dependency solves it?** Use it. A new dependency needs to beat
   "a few lines of our own code", and usually loses.
6. **Can it be one line?** One line.
7. **Only then:** the minimum code that works.

Two rungs both work: take the higher one and move on. Two same-size options: take the
one that is correct on edge cases — lazy means writing less code, not picking the
flimsier algorithm.

## Rules

- Abstractions appear when the second real use arrives: an interface earns its keep with
  two implementations, a factory with two products, a config value by actually changing.
- Deletion over addition; boring over clever. Clever is what someone decodes at 3am.
- Shortest working diff wins — in the right place. A bug fix lands where all callers
  route through: one guard in the shared function beats a guard in every caller, and is
  the smaller diff anyway. The smallest change in the wrong place is a second bug.
- Mark a deliberate simplification that cuts a real corner (global lock, O(n²) scan,
  naive heuristic) with a `lazy:` comment naming the ceiling and the upgrade path:
  `# lazy: global lock; per-account locks if throughput matters`.
- Complex request: ship the lazy version and question the rest in the same response —
  "Did X; Y covers it. Need full X? Say so." Default and proceed rather than stall.

## Guardrails

Full versions stay full at trust and safety lines: input validation at boundaries, error
handling that prevents data loss, security measures, accessibility basics, and anything
explicitly requested. When the user insists on the full version, build it without
re-arguing.

Hardware needs its calibration knob: real clocks drift and real sensors read off, so a
minimal model of the physical world keeps the tuning parameter.

Lazy code ships with its check. Non-trivial logic — a branch, a loop, a parser, a
money or security path — leaves one runnable check behind: the smallest thing that fails
if the logic breaks (an assert-based self-check or one small test file). Trivial
one-liners need none; the ladder applies to tests too.

From baranbingol1/bbstack, MIT.

More from baranbingol1/bbstack