KISS - Keep It Simple, Stupid
Given two designs that solve the same problem, the simpler one wins.
"Simpler" means fewer moving parts a reader has to hold in their head at once - not fewer characters. A fifteen-line function with an early return reads simpler than a clever six-line one-liner that needs a comment to explain what it does.
Why it exists
Complexity that the problem does not require is a cost with no offsetting benefit, and it is paid every single time someone has to change the code - not once, at write time, but on every future read. A clever expression saves the author thirty seconds today and costs every future reader (frequently the same author, six months later, having forgotten the trick) minutes of re-deriving what it does before they can safely touch it.
A clever line, and its plain equivalent
Try it yourself: before revealing the fix, decide what you would name each of the three clauses in the packed expression above. If you struggled to name one of them, that clause was probably doing two things at once - which is a KISS problem hiding as a naming problem.
The cost of overapplying it
KISS is easy to invoke as an excuse for cutting a case the requirements actually call for. Skipping the currency-conversion step because "keeping it simple" means only ever handling USD is not simplicity, it's an incomplete solution wearing simplicity's name. The test is not "does this handle fewer cases" but "given everything it must handle, is this the plainest way to handle it." Mistaking terse for simple, and mistaking simplistic (missing required behavior) for simple, are the two ways KISS gets misapplied in opposite directions.
How it relates to its neighbours
KISS and YAGNI are frequently conflated and answer different questions. YAGNI is about scope: don't build the feature nobody asked for yet. KISS is about form: given the scope you actually have to cover, implement it the plainest way that covers it. A method that handles exactly the three cases the spec requires, no more, can still fail KISS if it handles those three cases through a maze of nested ternaries instead of three named checks.
Where you'll see it in the pattern catalog
KISS is the voice that says most problems do not need a pattern at all - a pattern is a deliberate, named complexity, worth its cost only when the plain version has already shown a real seam. Where a pattern is warranted, KISS is why Strategy (a handful of interchangeable classes behind one interface) usually reads simpler than the conditional chain it replaced, even though it adds files - fewer moving parts to hold in your head at the call site is the whole point.
Check yourself
A six-line one-liner needs a comment explaining what it does. A fifteen-line version with named intermediate steps needs none. Which one wins under KISS?