> you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities ha

> you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed Excellent insight! If you use cutesy names, the intent of the component will get muddled and responsibilities will be strewn about. I've never seen an exception. Your components become a fuzzy set of containers into which all ideas are tossed without any design intent. The only way I've seen to avoid this is to develop your own taxonomy/dictionary defining what all the cutesy names mean, what their interfaces/boundaries should be, etc. At that point, consider how much time you've wasted building and training your team on a bespoke vocabulary ... why not just encode the meaning into the name itself? Precise naming leads to better design and most importantly, encourages future developers to actually following that design.