When you are hired by a software engineering company for the first time it won’t take long for you to create your first pull request. Once you have shared this with your peers you will get your first taste of the code review process.
It’s almost guaranteed that as you learn the ropes you will receive comments on your proposed changes ranging from implementation feedback to requests to add automated tests to cover your changes.
One specific type of comment you may receive could look something like this:
“nit: replace the spaces with tabs on this line”
or
“nit: please use single quotes here instead of double quotes”
When you see this for the first time you’re likely to ask ‘What on earth does nit mean?’.
What is a nit code review comment?
A ’nit’ (short for nitpick) indicates that the following comment contains feedback that is minor or inconsequential. It could be referring to some styling preferences in the code. These comments are usually so pedantic that they typically don’t even warrant being written. But when written (as they inevitably are) they can be considered non-blocking and merely suggestions.
Why nit comments are a waste of time
Nit comments are a waste of time because the implication when writing one is that it can be ignored. The fact that it is possible for some code changes to make it to code review containing ’nit-pickable’ issues indicates a gap in automation. This is low-hanging fruit. The vast majority of nit comments can be solved using an code formatter (such as Prettier) or linter (such as ESLint) that automatically applies a set of rules to your code every time you save a file. This is such a valuable investment because it saves all the headspace used to remember ‘do we use double or single quotes’ etc.
Any time you or a teammate are tempted to leave a nit comment it should be a signal that you are missing some rule from your code formatter or linter. So instead, take that thought and find a way to automate it so that no one has to be subject to this particular nit again.
Secondly, it’s common for junior engineers to fret over every single comment left on their code review, especially if it’s from a senior individual on the team. So any nit comments left on their pull request are wasting the time of both colleagues as well as distracting the junior engineer from more valuable feedback.