TDD
Test-Driven Development is a workflow where you write a failing test first, write the minimum code to make it pass, then refactor, repeated in tight loops. Popularised by Kent Beck in the early 2000s, TDD's main value isn't bug catching but design pressure: the act of writing the test forces you to think about the interface before the implementation, producing cleaner code.
TDD's tight loop (write test → run it red → write code → run it green → refactor → repeat) is sometimes called Red-Green-Refactor. The discipline pays off most when the code under test has clear behavioural boundaries, pure functions, data transformations, business logic. It's awkward for UI work, integration with hard-to-mock systems, and exploratory programming where you don't yet know the right interface. Teams that adopt TDD report fewer defects shipping but often slower initial development speed; the trade-off shifts in TDD's favour as the codebase ages.