the lazy dev

updated 2 Nov 2026. no framework, no build step, one file.

the flow

BEFORE YOU START

 [1]  does this need to exist? ── no ──> stop. nothing to write.
        │ yes
 [7]  who uses it, and how much?
        │
 [2]  read more than you write
        │
WHILE YOU WORK
        │
 [3]  think in test cases and edge cases
 [4]  never cut the core to make it quick
 [10] name things for the next reader
 [11] stuck for 30 min? ask              (when stuck)
 [9]  measure before you speed it up     (only if speed matters)
 [8]  small changes, easy to undo
        │
BEFORE YOU FINISH
        │
 [6]  test it, fail loudly
 [5]  write down the limits
        │
        v
      done

writing code

 1  already in the code, stdlib or platform? can it be skipped?
 7  just you, or real users? that sets how careful to be.
 2  read the code it touches and every caller.
 3  list what could break it: empty, zero, last item, wrong type.
 4  keep input checks, error handling, security, accessibility.
10  if a name needs a comment, rename it.
11  write down what you tried and expected, then ask.
 9  find where the time goes before changing anything.
 8  one idea per commit, on a branch.
 6  one small test for any real logic.
 5  note the shortcut and when to upgrade it.
    -> ship it.

reviewing

 1  could any of this be deleted or reused from what exists?
 7  who gets hurt if this is wrong, and how many?
 2  read the code around the change, not only the change.
 3  name an input that breaks it. no case, no comment.
 4  did the change drop a check or an error handler?
10  can you tell what each name holds without reading its code?
11  don't understand a part? ask the author.
 9  is any speed claim backed by a measurement?
 8  one idea, or several to split?
 6  would a test fail if this broke?
 5  are the known limits written down?
    -> approve, or send back numbered findings.

fixing a bug

 1  is the bug in code that shouldn't exist? deleting may be the fix.
 7  who is hit, how many, how badly? that sets the urgency.
 2  find every caller before you edit.
 3  write the exact input and the wrong result first.
 4  fix the cause. keep the check that caught it.
10  if a bad name caused it, rename as part of the fix.
11  can't reproduce it? ask for the exact steps.
 9  if it's slowness, measure before guessing.
 8  one fix per commit, easy to revert.
 6  turn the breaking input into a test.
 5  write down what you couldn't fix or check.
    -> add a line to the bug diary.

signs you're building too much

a library for something a few lines or the browser can do
an option "for later" nobody asked for
a wrapper that only passes calls through
the same code pasted a second time
a change touching far more files than the idea needs

how to grow faster

guess first, then check. see how far off you were.
read other people's fixes, PRs and mistakes.
keep a bug diary. one line per bug, and which habit would have caught it.
own something people use.
explain your code to someone. can't say why a line exists? look again.

practice with feedback beats waiting for experience.