I asked ChatGPT these questions and got sensible answers.
How much more is one half than one third?
[subtraction answer: 1/6 more]
That’s one possibility, but what about the other way to interpret that question?
[ratio answer, but expressed as “1.5 times as much” rather than “1/2 more”]
Oh. I just noticed the extraneous word in the search, which might be throwing off the LLM trying to understand it.
I agree with your assessment regarding the intention of the phrase. We’re back at the silly arithmetic meme that hinges on not grouping terms explicitly.
Still, the actual mistake remains. Why an extra 1/6 of the pizza? 1/3 of 1/3 is 1/9, not 1/6. That’s 1/2 of 1/3.
There are two meanings being conflated here.
“1/3 more” can mean “+ 1/3” or "* (1 + 1/3)“.
So “1/3 more than 1/3” could be 2/3 or 4/9, but not 1/2.
Instead 1/2 is 1/2 more than 1/3, not 1/3 more. That’s the meme I’ve seen go around recently.
1/3 more than 1/3 is 4/9. What you wrote is 1/2 more than 1/3, not 1/3 more of it.
Pitch me. I could switch, but it would help a great deal to understand more about why. I’m open to change, but not eager to change.
I’m very happy. I had the same early experience as you, but I kept with it. I’ve been using it several years now. When I’m forced back to vim, my fingers remember just enough, but I have to undo pretty often.
I kakoune instead.
You want candy?
Write comments that explain why the code isn’t obvious just by reading it. Why did you do things the long way? What did you need to work around? Why didn’t you do the thing that anyone reading the code would expect you to do?
Also write comments that explain the purpose of the functions you use, in case the names of those functions don’t make it clear on their own.
The fact that the loop is doing “find first driver matching these strange criteria” seems most obviously obscured by the pattern of assigning a value, then killing the loop or not. This strikes me as the part that makes the algorithm tedious to test, since it forces us to use a collection to test the intricacies of the inner conditions.
Once we isolate “find first driver matching condition” from computing the condition for each driver, I consider the rest a question of personal taste. Specification pattern, composition of filters, something like that. Whatever you find easier to follow.
I don’t think I’ll forget.
This is true Customer empathy.
Yes, any programmer who doesn’t care will do damage, but when I see durationInMilliseconds, I think more about what the int means than when I see merely “duration”. I don’t know how to help the people who read that and ignore it.
The story of the 125 mph knuckleball might help.
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.
Yikes! That’s also a great cautionary tale for Primitive Obsession/Whole Value as well as a bunch of other design principles.
I’m thinking about how I’d have done that refactoring and now I wish I had the code base to try it on. It sounds like it would make a really good real-life exercise in a workshop. “Remember folks, you have to get this right. There’s not really a way to check this with the real hardware, and if you get it wrong, someone’s going to get hurt.”
Thanks again.
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…
I don’t need to win that badly.
Aha, yes. Somehow I forgot the difference interpretation for a moment. Oops!