Hacker News Reader

Comment by burlesona | Hacker News Reader

It’s funny, this is the kind of thing that’s meant to end bike shedding, but to me this is the ultimate bike shed.

I like linters, and having a good default config out of the box is a good idea. But the idea that you need an entire language community to agree to only ever do anything one specific way is just kind of silly IMO.

What projects like these say to me is that there are too many teams with poor leadership who spend far too much time bickering over things like which linter rules to use, and thus feel that invoking a higher power (the “standard,” in this case), is the only thing that will save them.

Now that this problem is “solved,” what new crisis caused by a lack of leadership will present itself?

View on HN

It's the ultimate bike shed and it's trying to push the idea that it's only taking away choice that doesn't matter. But generally with tools like this, if you try arguing for different settings, you'll find very quickly that the reasons these tools have the rules they do is that the people writing these tools tend to have very strong ideas about what the rules should be and how important it is they're all the same.

That's how I generally feel about it. Strategies like these are usually covering up the symptoms while leaving the root problems in place. "We aren't arguing so it's clearly going well".

Thing is, I _want_ my team members to argue over coding styles and patterns. I _want_ people to present different techniques and approaches, and for everyone to weigh in with what they like and they don't like. I _want_ people to be pushed to consider new things and and perspectives, and to challenge their accepted notions on how to code.

The true root cause, I think, is that many people know how to argue, but very few people now how to argue constructively. Where the goal isn't for one person to win, but for everyone to discuss ideas while tracing back our shared interests until the proper solution presents itself. I wish more people took the time to develop such a skill.

As somebody who was faced today with the lack of that specific skill, can you recommend any good reading?

I don't know of any good reading, but I suggest you start with some proactive good listening.

I learned a lot about how to debate more constructively second-hand from my business partner who took the class referenced here [1]. The “crossing the net” tool was especially helpful to me once I started actively noticing how often I did it. Really trying to follow that forced me to ask better questions to understand where my views differed and why. All 5 tips are good areas to reflect on and experiment with, though.

[1] https://www.quora.com/What-are-the-key-lessons-from-the-Touc...

Patterns are good but the minutiae that most linters deal with aren’t that. A discussion over formatting rules is more often than not a distraction and a waste of time — if it’s not there, better discussion can come out of code review.

Notice how in these threads, the people who think that the specific formatting doesn't matter tends to be the ones supporting tools that tries to force a specific formatting.

To me the formatting does matter. It is a major factor in how comprehensible a code-base is, and often having freedom to deviate from the expected rules to line things up in certain ways helps to convey patterns and similarity that matters.

That differs from my opinion on the matter. If two programmers disagree over formatting, I want to learn the needs of each programmer and how those needs inform their formatting preference. Understanding each others needs, and being respectful of each others needs, is a primary component of good teamwork. Those needs aren't exposed when a linter prevents the variance from ever becoming clear.

To me it seems less like they think this ought to be forced upon or adopted by the entire Ruby community or whatever.

The big benefit to me would be as a maintainer of an open source project. I can use this, & I never have to consider whether or not someone’s suggestion to change a linter rule is worth listening to or not.

You achieve exactly the same by insisting your project, your linter rules. There's no difference, because someone can just as well argue you should replace your use of this project with something else.

That’s a fair point, should probably just include stuff like than in READMEs at this point

Reply on news.ycombinator.com