Rookies in the Bike Shed | Hacker News Reader

Rookies in the Bike Shed

david.heinemeierhansson.com

74 pointsjashkenas41 comments

The Rails commit that spurred this post, apparently: https://github.com/rails/rails/pull/5329

Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match.

Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request?

The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction.

It's debatable who's actually bikeshedding here.

Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!

Fair enough, I wont argue with your elastic defence ;).

Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.

Did I? Perhaps you could elaborate for my benefit then.

This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not.

An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint.

Ah, but if real life were only so black & white.

In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.

Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.

Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one.

So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie.

However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.

To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0.

@fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.)

Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again.

And so the bike shedding continued...

Indeed, it took me some 24 hours to revert. I reflected about it for some time.

After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.

Ah I'm sorry, I should have rechecked before posting this. I meant no offense.

There you see how closely I follow this story... :)

I hate to be harsh, but just to give some perspective: You really come across as stubborn and intractable there. Your rationale basically boils down to "People might think I was wrong if we change this." The reason given is not anything like "The code I am reverting is inferior," it's just "This code doesn't support the point I want to make." You even said that if his commit message had been different — not the code, just the commit message — you would have left it.

Try imagining this from somebody else's eyes — what does it look like?

I can only say you basically have no idea what you are talking about. I know my motivations, you can't read my mind chc.

That is true, and I'm sorry if it sounded that way. I was speaking from the perspective of interacting with other people, not your inner thoughts. You might actually have had very good reasons why your choice was superior, but you did not share them with anyone else, and from an impartial observer's perspective, it looks like this stonewalling is what made a simple PR turn into a huge bikeshedding flamefest. If this doesn't matter to you, I apologize for wasting your time. It just seemed like something I would want to hear if I were in your place.

If that was the intention I appreciate it.

Yes it matters to me, but up to a point. I cannot do things in my life seeking approval or saying yes to some people when I am convinced the answer is no.

Also, saying no, and not applying the PR the way I did, with the rationales and respect I showed, should not be taken as an offense. People just get upset when they see the red label "Closed".

On the other hand, for every 24 haters, I can present 24 lovers. It just doesn't matter, one has to do what he thinks is the correct action. Do it politely, but do it.

It's more than that though. It seemed really clear that a lot of people thought this was useful, and you blew off all objections without really explaining sufficiently why. It's not that big of a deal, and it sucks that everyone wasted so much time on it, but the thing that bothers me about it is that I (and it sounds like a number of other people) have come away from this still not understanding why the change is rejected. We understand what you wrote about predicates not guaranteeing a boolean, but your attitude kind of implied that predicates should not return a boolean and, clearly, a number of people don't understand why that makes sense.

What you failed to address was why your way was better than returning a boolean true/false. Everyone understood your comments that predicates don't necessarily need to return those, but your comments kind of read like "my way is perfectly valid Ruby" while the other people's perspective seemed to be "our way is perfectly valid Ruby also, and it alleviates some potential annoyances or pitfalls". You never really addressed any of that, it always seemed to just go back to "my way is valid Ruby".

Maybe this wasn't really your intention, but it honestly seemed as though you were deliberately trying to frustrate people. I think that's why there was so much push-back (in the form of about three other PRs being opened). Not because people felt so strongly about xhr?, but because it just seemed like you were just rejecting everyone's opinions without really expressing why returning true/false is worse than returning 0/nil.

I'm basically a total outsider since I haven't contributed to Rails yet, so feel free to completely ignore my perspective.

Yes, good point - all the more reason to be mindful of the impressions you make on others, since their perception is their reality.

Thanks for not allowing code convention to be based on mob psychologoy.

It was my pull request. It was spurred by a compatibility break that took all of two seconds to fix in our app, but the principle of the matter is what irked me.

And it wasn't from passing it to JavaScript, it was from parameterization from Ruby to Ruby.

I didn't really care that much about it getting merged in, so long as the docs changed (fxn's argument about using a fixed-width font in html docs to indicate the singleton true vs a truthy value is something that really ought to change). That stance is unfriendly to developers and follows what seems to be the Principle of Most Surprise.

At the end of the day, it's not worth all the trouble for something so trivial. I'd rather rails-core deal with more important issues. And that's the last time I ever send a pull request on principle to a project I don't own.

I found this comment https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.

Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding.

If you read the original source for the term at http://bikeshed.com/, Kamp shows his respect for the submitter of the change:

  I bow my head in respect to the original proposer because 
  he stuck to his guns through this carpet blanking from
  the peanut gallery, and the change is in our tree today.
  I would have turned my back and walked away after less
  than a handful of messages in that thread.

This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me.

(Edit: formatting.)

To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.

Maybe they are just trying to optimize for pedantry.

That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons.

It's not bikeshedding, but there ought to be a name for that.

My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort.

The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.

I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.)

Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.

It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.

And this is why people reinvent the wheel. If you disagree with the core teams decision here, you are at an impasse. So, you fork and move on. Or, you think about it, and decide to create your own framework that will be like Rails, but do things the way you want to do them, including making xhr? work the way you think it should.

Reinventing the wheel gets a bad wrap. People suggest you should contribute to existing projects. The problem is when that existing project's direction diverges from your needs. Reinventing the wheel is part of the power of open source.

On a side note, considering the sheer number of types of wheels, "reinventing the wheel" comes across as a bit odd.

This is exactly the point of the original post. That if you're willing to redo Rails because a predicate method does not return singletons, you're a rookie who don't know the value of time.

Of course, people don't actually do this. They talk about doing it, but don't actually carry through.

> That if you're willing to redo Rails because a predicate method...

I wasn't clear. My mistake. The issue isn't one of a predicate method, but rather, overall approach. If Rails doesn't work the way you want, you don't whine and complain it doesn't work. You either accept it, or move on and do something better.

The if the attitude demonstrated here is something you can't work with, you move on. It's not just this issue, but every issue like it as well.

I agree with the premise of the post (bike shedding is pointless); however, if you need a garage and not a bike shed, trying to get people who want that bike shed and are building that bike shed to instead build a garage, your better off moving on.

I saw one post mention File.world_readable? I don't know Ruby and the result surprised me.

  irb(main):002:0> File.world_readable?('/etc/passwd')
  => 420
  irb(main):003:0> File.world_readable?('/etc/shadow')
  => nil

420 is decimal for octal 0644 which is the permissions on my /etc/passwd file. Fair enough, but as someone looking from the outside it seems weird to leak partial and unreliable information like that. Especially if I was to write

  readable = File.world_readable?('/etc/passwd')

and later readable has an integer in it representing an octal value which can't be used for more than a true/false value. Is it common to throw !! in front of truthy/falsey calls to get down to the boolean literal?

It's not a common idiom to use !! in Ruby.

This post raises some interesting points about the difficulty of contributing to open source for the first time. Over the last year, I've taught myself to code. I want to contribute to open source, and I think I can provide value to smaller projects. But the public nature and unique culture of open source have left me feeling a bit overwhelmed. So I observe instead.

What's the best way for a rookie to find small, welcoming open-source projects to contribute to?

Find a small project you use for something you're building. Do you run into any issues with using it, that could be improved? Improve those and send a pull request. Make your first commit small and obvious.

Find a "small" project is probably best. I've contributed to probably over a dozen opensource projects on Github in the past year or so. I highly encourage you to find a few that you use and like. They don't even have to be really small, but I'd probably avoid projects like Ruby, Rails or the Linux kernel for now.

Try to get into a bugmash of some kind. I started this way with Rails and I wrote about it http://www.rohitarondekar.com/articles/my-first-rails-bugmas...

Many companies and tech groups have these around the world during meetups and conferences.

But most importantly dont let this pull request fool you. Rails is nice to contribute to even if you are starting out and the rails core team especially jose valim and santiago pastorino are super helpful.

Start your own project.

Open source is not strictly about contributing to existing projects. You can start as many new projects as you'd like.

My experience is that many big projects started out as personal (read small) projects that grew out of adoption.

What kind of projects should you start?

Pick something that you reason you can solve with your current knowledge, and get working.

I very recently wrote http://collectiveidea.com/blog/archives/2012/03/16/your-iden... and I think it's very relevant in encouraging people just beginning to contribute to open source.

I agree this is a good approach for any open source project leader to have.

It's valuable to let rookies argue small debates so they can learn the ropes and get a feel for the community; it's even more valuable for the veterans and leadership to make decisions, set priorities, and maintain focus on what's important. Both are necessary to grow and sustain an open community project. You bring people in and get them engaged whilst reinforcing what the project is focused on, its tone, style, and mission.

Making a decision civilly, whether everyone agrees or not, is very reassuring to newcomers and oldtimers alike. It proves that the community is fun and worthwhile.

This reminded me a bit of this thread:

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38

Reply on news.ycombinator.com