I am trying my best to build in an inordinate amount of upfront linting and automated checks just to avoid such things - and then I still need to do a roadshow, or lots of explanations- but that’s probably good.
But the good idea is to say “we all have the same brutal linting standards (including full stops in docs!) - so hopefully the human linger will actually start reading the code for what it is, not what it says”
I'm also a fan of linting everything. Custom linter rules ftw.
This and documenting non-lintable standards so that people are on the same page ("we do controllers like this").
This is how I like to build and run my teams. This makes juniors so much more confident because they can ship stuff from the get go without going through a lengthy nitpicky brutal review process. And more senior devs need to actually look at code and business rules rather than nitpicking silly shit.
> This makes juniors so much more confident because they can ship stuff from the get go without going through a lengthy nitpicky brutal review process.
I had not considered that linters could greatly help new developers in this way, especially if you make it a one-button linting process for all established development environments.
Thanks for the insight! I will use this for the future.
But the good idea is to say “we all have the same brutal linting standards (including full stops in docs!) - so hopefully the human linger will actually start reading the code for what it is, not what it says”