I'm more on the extreme end of you can never name too much, as long as the names add more signal than noise, so I may be biased. But I feel like the two exampl

I'm more on the extreme end of you can never name too much, as long as the names add more signal than noise, so I may be biased. But I feel like the two examples given don't really support the case against. In git, branches are close to meaningless. You can use git without branch names quite well, it's just not as nice of an experience as jj. The only thing you can not do in git without having a named branch (or rather a ref of some kind, does not have to be a branch) is moving commits between local and remote repository. In git, branches are only meaningful – briefly – when communicating with other people, in which case naming them really matters! For your own temporary use, sure, don't name then. For me that's more of a flaw of git. In most git workflows you're meant to destroy history, so it doesn't matter that the branches are also destroyed, which again results in their names being meaningless. For things that are not throwaway I'll stand by putting as much effort into naming them as is needed. Utility CSS classes are names. They're an API. Although I understand the reasoning, Tailwind is actually a perfect example of terrible naming. Everything has a single letter name or a name composed of initials. As a beginner you have absolutely no idea what you're reading, until you learn all the cryptic names. I'll restate that I understand why it is this way, but again for me it's a flaw of Tailwind and maybe utility classes in general. Then there's the final example of lambda functions, where supposedly everyone accepts that naming isn't important. I think this one is the best example of why naming is important. If each step here had a proper name, you wouldn't have to write out what the function does, the code itself would explain it. If I don't trust it I can verify that the code the name is given to matches the name. Once I've verified it I can forget the code and substitute it with the idea of what it's supposed to do. Or if I don't want to verify it I can just trust the name and still understand what it's supposed to do. Good naming helps readability tremendously for me. I don't have to spend any brain processing power on parsing that `.filter(|i| *i % 2 == 0)` means `filter even numbers`, I can just read it. PS. Actually there are already two good names there: `into_iter()` and `sum()`. I don't need to know how they're implemented to understand what they're meant to do there. It's the lambda that's the problem and shows why naming is important.