I'm nitpicking a bit on code naming...

In a code review that I did today, I left a final note to the author of some new piece of code:

Sorry for nitpicking on code naming. The approaches you take are good, but naming is hard (but important!):

There are only two hard things in Computer Science: cache invalidation and naming things.

(see here a list of variations on these two hard problem ‘jokes’ in Computer Science)

I enjoy the ruby programming language because you can get a long way by just assuming things. A collection implements each, every object has nil?, in rails, I can get the relationship of a record and use scopes to filter the relationships as defined in the class of that related record. If it ands with a questionmark, it returns a boolean(y). Anyway.

So while they might say: “never assume things”, and sure, a lot of things are chaos, but ideally not our code base :) I prefer to work from assuming things, and if it doesn’t match to my assumption choose:

1. make sure that the method name doesn’t pretend something it is not
2. make it so that what I assumed to be working actually works (and I never ever have to think about or bother by it anymore)

… and/or maybe, I am just wrong and I should level up my understanding of things. We all have our internal models of how things work, sometimes they are wrong and these internal models need some adjustments, but ideally the API that we create guides us.