If "close enough" works, then it's nice to have the skill. Having the skill requires occasionally using it.
Where accuracy is important, since we almost always have a calculator with us now, that's a no-brainer.
Maybe more to the point, though, understanding how percentages work is wise. It's one of the few arithmetic topics that we encounter regularly in life.
In this case, 23% of 53 and 53% of 23 each have their own little trick, depending whether you'd rather overestimate a little with 1/4 of 52 or underestimate a little with half of 24. I find it handy to be able to think that way, especially for example when trying to get out of a taxi and paying cash.
I like our local shared ownership model: neighborhood cat visits, we chill on the deck, I offer him water, he doesn't seem to need it, he wanders off. Every so often, there's just this cat at the back door checking in.
Name expands as I understand better the structural role of a thing. Duplication in names begins to become easier to spot.
Removing duplication in names means introducing helpful structures, resulting in shortening names again, particularly as the intent/purpose of thing becomes clearer.
Long names stay unnecessarily long when we don't notice the patterns that suggest the missing structures.
The more examples of this kind of thing, the better!
(And my preferred name for that is rolesByEmployee. In general, "values by key".)
I see that they've gone back to the name "The Daily WTF". For some time, they changed to "Worse than failure" in order to avoid not even the word "fuck". 🤷
I've been where you are. Most important: don't let yourself start to take responsibility for managerial decisions. If they want you to stand in the corner on your head and cluck like a chicken, it's their money. 🤷 Don't let that change how you see yourself as a programmer.
Is this a problem for you or merely annoying? I mean the difference between you being blamed for their poor results and you merely being inconvenienced by doing extra work.
You might need to train yourself to accept the situation as it is and hope for someone in authority to make things better. It's not easy, but this might be a good chance for you to build that skill. 🤷
Can you talk openly with your manager about this situation? Would it be helpful to you to propose to your manager that you help that group? Maybe your manager would appreciate your attempt at leadership.
I like test names that are full sentences. Doing this for its own sake is unnecessary. It's probably wise to practise this for a year, then decide when you still need it.
For me, quite often, a combination of the test group name (often naming a behavior) and test function name (often naming a special case of that behavior) suffices, even though it is not a full sentence. (Example: test class SellOneItem, test method productNotFound. Is this not clear enough?)
Test function names that merely repeatedly duplicate details ("conversion should..." to start 12 test names) indicate a test group trying to emerge ("Conversion Tests"). Insisting on full sentences for its own sake often either masks this risk (and delays helpful refactoring) or represents redundancy (merely reiterating what has been helpfully refactored).
I have found this attention to full sentence names most helpful for tests whose audience is not programmers, since those folks are not accustomed to common source code conventions and patterns. For Programmer Tests, I think "should" turns this helpful advice into a risky overstatement.
My original joke was based on the assumption that "She lay" was intended to be in the present tense (and why wouldn't it be?) and therefore a humorous use of colloquial English (in place of "she lays", possibly invoking African American English for humorous effect. We can argue about whether this is culturally sensitive.). The corresponding correction would therefore be "She lie", rather than the grammatically standard "She lies".
✅