I still remember the first time I heard about the concept of linting. My initial response was unfavorable to the concept.
That was partially because the person speaking up in favor of linting didn’t have the best reputation at the organization where I worked. It was partially because my mentor at the time seemed to be anti linting, and it was partially because the concept of something telling me that I was doing a ‘bad’ job writing code sounded as pleasant as going in for unnecessary dental work.
Fast forward several years, and now I’ve been working for a few months in a codebase that has linting enabled.
My takeaway now? Why wouldn’t you want an automated tool that automatically highlights stuff that you forgot to address while you were working?
Sure, in any big organization, there are likely going to be some linting rules that you think take things too far, but the value to having something help debug your work even before it has a chance to break is incredible.
I guess, for me, it’s a lot like Typescript. There’s a reason that big organizations tend to use linting. It’s not because they are dinosaurs who can’t change and who like to move slowly. It’s because they’ve realized that it’s a great way to increase developer efficiency by reducing the number of bugs that get out the door.