I have settled into this pattern:

1. Name expands as I understand better the structural role of a thing. Duplication in names begins to become easier to spot.
2. 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”.)

It’s much more likely that we sound like children than we sound like an LLM.

I use Spectacle for taking screenshots and I’ve enjoyed using it for several years. After that, I’d crop it in any image editor that has a freehand selector tool. Gimp would be the first thing I tried, but I’m sure you could find something easily enough.

Dumb question: do you have a key on your keyboard that disables the microphone? I don’t have my laptop in front of me, but I know there’s a key that disables the trackpad and another that disables the camera. I realized that I’d accidentally hit those by going through something similar to this.

Good luck.

Best Practices thinking considered harmful. 🤷

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.

Boo.

I applaud your plan. Have fun!

Obligatory mention of lazygit for those who prefer vi and its descendants.

No, I’m not making any claim regarding which is better. Hold your cards and letters. In many other universes, I’m a daily user of magit.

Not constantly changing things until there is something significant to release is a path to the stability that I value. Meantime, packages run and the system works.

I never wanted a hobby, but rather an operating system. I’ve been using Pop! for over six years. I only had one stretch where I felt like I was chasing annoying bugs and I don’t remember it clearly enough to remember how long it lasted.

Combine with jc to process CSV files. This is how I get data into my plain text accounting system.

Do you struggle to remember the names of commands or how to use them or how you have used them in the past?

Underrated or not widely known?

I love lazygit and I’m still surprised at how many people are shocked when they see it for the first time. Not exactly a command, but a very handy text UI tool.

For more elementary tools, I can’t believe how many people know about ! and ctrl+r who don’t also know about fc and edit-and-execute-command.

The Handmaid’s Tale

We

Nightfall

The Terminal Experiment

Indeed, this is a time for naming conventions that communicate the details that the type system can’t clarify. This leads to the long names that senior programmers make fun of. Don’t listen to them; let them laugh then make this kind of mistake.

Wow. I love that story and I’m glad nobody was hurt.

I wonder whether that happened as a result of unexpected behavior by the pitching machine or an incorrect assumption about the pitching machine in that coworker’s tests.

I find this story compelling because it illustrates the points about managing risk and the limits of testing, but it doesn’t sound like the typical story that’s obviously hyperbole and could never happen to me.

Thank you for sharing it.

This seems to happen quite often when programmers try to save time when writing tests, instead of writing very simple tests and allowing the duplication to accumulate before removing it. I understand how they feel: they see the pattern and want to skip the boring parts.

No worries. If you skip the boring parts, then much of the time you’ll be less bored, but sometimes this will happen. If you want to avoid this, then you’ll have to accept some boredom then refactor the tests later. Maybe never, if your pattern ends up with only two or three instances. If you want to know which path is shorter before you start, then so would I. I can sometimes guess correctly. I mostly never know, because I pick one path and stick with it, so I can never compare.

This also tends to happen when the code they’re testing has painful hardwired dependencies on expensive external resources. The “bug” in the test is a symptom of the design of the production code. Yay! You learned something! Time to roll up your sleeves and start breaking things apart… assuming that you need to change it at all. Worst case, leave a warning for the next person.

If you’d like a simple rule to follow, here’s one: no branching in your tests. If you think you want a branch, then split the tests into two or more tests, then write them individually, then maybe refactor to remove the duplication. It’s not a perfect rule, but it’ll take you far…