There's perfectly reasonable reasons to mention IDE, for example some companies have propriety Eclipse (or Emacs) extensions to support their code base or use collaborative work capabilities that are integrated with IDEs.

Environmental setup also has an impact, a company might use project files that automatically setup the environment and set common standards. Sure you can come in and rewrite all of those things in your favourite IDE which you then have to manually sync when things change, but that's a lot of overhead.

There's also some people who will only work at companies that use their favourite editor (particularly common in Java with IntelliJ) and will ignore job ads which mention Eclipse.

It can also act as signalling (i.e "we're willing to pay for you to have the best-of-breed development tools") much like jobs ads which specify developer monitor sizes or hardware (Macbooks, SSDs, etc).

I agree with a lot of what you're saying actually, it's why this rule emits a notice rather than an error or warning. Considering that some of the rules are a little polarising, it would probably make sense to allow people to ignore certain rules. Thanks for the feedback

If you do pair programming, you may find it desirable to establish a common development environment, so pairs don't experience friction between one person and another's development environment. In that case, you might want to hire people who know that tooling, or, more likely, you might want to filter out people who have a passionate attachment to some other tooling.

If they mention that you must use this or that IDE, it's to let you know that it's probably a bad place to work.

The caveat is that if a team does pair programming, it's helpful that everyone is ok with using the same editor. Worth mentioning that fact in a job advert so people know before they interview.

Good point, pair programming, XP, agile, and all other such nonsense should be added to the rules.

Nothing is more unfashionable than last year's big fashion.

Or maybe people were willing to give something a chance, and found that though it has benefits, it's not everything it's cracked up to be? I am a solitary person so I found the entire idea of pair programming repugnant but some people really love it. I don't think it has anything to do with fashion more to do with what some would consider a failed experiment. Did coding this way yield quality code at a faster rate with less stress? Anecdotally I would say no, and that may be why it's called nonsense by some.

Thanks, and you're probably right about some temptations being applicable to bro culture.

On mentioning editors, I like your explanation of why it's not good. I'm intending on writing a list of explanations for each rule at some point so it's useful to get other people's opinion on them.

Thanks for putting this together. This is one of those nice projects that does more than just solve a problem or acts as a tool; it forces the user to think.

Overall, I hope this project goes toward helping people understand the thought process that gives rise to the "job lint" in the first place rather than just fixing the "lint". Eventually, they should learn to act as testers themselves and your explanations on why those lists exist as they are will definitely help.

Granted, lots of people use text editors. Some use text editors with plugins.

But some people use IDEs. Some IDEs have nice integrated features that make a difference in a team environment. E.g. one place I worked we used Visual Studio and I wrote an add-in for running our particular suite of integration tests. In the Microsoft ecosystem the whole integrated thing is very significant.

Although I suppose if you were applying for a .NET job the choice of IDEs would be assumed unless stated.