In 2017, a colleague graciously shared this technique with me, thoughtfully nitpicking one of my first pull requests on the job. I've since made it my own, and even got it to rub off on some others.
Nitpicking has a bit of a negative connotation. By definition it's picking apart things we shouldn't concern ourselves with. And oftentimes, when presented with someone else's code, we tend to skip over little stuff. Things that are technically correct, but we might've done differently ourselves. We don't want to annoy our colleagues, right? Well, what if we didn't do that?
Let's remember we're all people after all. When reviewing a change like this, it's likely it was done intentionally, but there's also a pretty good chance the person simply didn't notice or think about it. By calling it out, we're ensuring they have the chance to actively ignore it, or do something about it. That's it. And by starting off with "Nit:", we're signaling we know what we're doing and we're only really looking for acknowledgement.
I believe in writing code for the next person. The less code that's written, the less code there is to understand. Consistency is also key. I don't think good code leaves room for interpretation. In Go, the entire language was built around these principles – that code should look the same no matter who wrote it. Not all languages provide that level of enforced consistency – and that's where nits come in.
If you want to do your colleagues a favor, start treating all of their code as your own and be as vocal about it as you need to be. And before you know it, they might start doing the same back. In the end, we all grow together.