Getting Better All the Time: How to Escape Bad Code

Justice shows a restaurant list where adding has a loading state but deleting does not. Its 150 line component mixes unclear state names, nested JSX, inline asynchronous handlers, and styles. Those choices make it hard to add a separate deleting state for each row.

Justice defines bad code as code that makes a needed change difficult. Working around it can make later changes slower, while a full rewrite is a large commitment that may conflict with urgent fixes. With trusted tests, he instead extracts handlers, renames variables, and moves each restaurant row into its own component, then adds row level deleting state.

Justice describes refactoring as small changes to code structure that preserve behavior, checked by running tests after each step. Small changes can deliver value during ordinary feature work, and each step can be shipped if priorities change. TypeScript catches structural mistakes, but tests also check runtime behavior.

Justice presents test driven development as writing a failing test, adding enough code to pass it, then refactoring. His restaurant list example starts with tests for displayed names, errors, and loading states, adding tests for when messages should be absent before implementing those conditions. He says the tests need to cover behavior well enough to support future changes.

Justice argues that TDD’s biggest benefit is giving developers confidence to refactor continuously. He acknowledges that TDD takes effort, while living with difficult code also carries ongoing costs. His goal is a codebase whose tests let developers adapt the code to new requirements, even when the existing structure is poor.