Why does a strict, tense-based naming convention for commands, events, and queries matter more on a real team than it might seem?

On a codebase with many message classes, a consistent convention — imperative names for commands, past-tense names for events, question-phrased names for queries — lets any engineer read a class name and instantly know its behavior contract without opening the file: whether it can be rejected, whether it's a permanent fact, or whether it's a side-effect-free read. Without that convention, a name like UpdateCustomer is ambiguous — it could be a request that might fail or a fact that already happened, and the only way to find out is to read the handling code and trace how it's used. On a large team where many engineers are adding new message types independently, this ambiguity compounds quickly and makes the codebase noticeably harder to navigate, while a consistently enforced convention keeps that cost from ever building up.