Why I close pull requests • Hacker News Board

Re: Why I close pull requests

#71

Post by zardeh » Thu, Dec 29, 2016, 3:20 AM UTC

fdsfsaa wrote: post #59

skj wrote: post #57

Earlier quoted context omitted.

We write design docs at Google to communicate ideas with each other. They're useful for promo committees because effective communication between engineers is something that is prerequisite for effective engineering. Of course a full design doc is not needed for every change. Many changes are small and straightforward. Only big things, where the team needs to discuss and understand options. Or bigger things, where dir…

> We write design docs at Google to communicate ideas with each other. I have no problem with individual developers choosing to circulate documents in order to solicit feedback. My objection is to rigid processes that force engineers to write documents. Mandatory design documents for "communication" invariably morph into checklists of required signoffs from people who have little incentive to say "yes". In this way,…

To clarify here, what kinds of changes do you think require a design document?

Re: Why I close pull requests

#72

Post by mikeash » Thu, Dec 29, 2016, 3:30 AM UTC

ageofwant wrote: post #68

mikeash wrote: post #44

Earlier quoted context omitted.

How does that help? Are you just using the presence of the fork in your account as a sort of bookmark?

Yes, a complete and fully featured bookmark that won't disappear. It costs me absolutely nothing, and is ready to go when and if I need it. Why wouldn't I do that if I could ?

It makes perfect sense. This isn't what I've seen some people do, though.

Re: Why I close pull requests

#73

Post by akkartik » Thu, Dec 29, 2016, 3:33 AM UTC

caconym_ wrote: post #15

hk__2 wrote: post #11

Earlier quoted context omitted.

You should report this to the blog author; not to HN readers.

My assumption is that the OP, "geerlingguy", and the post's actual author Jeff Geerling, are one and the same. Not unreasonable, I think. If he wants to post his work on HN and not read the discussion (which is obviously going to be relevant to his work), that's on him.

Grandparent's point wasn't that the author may not be reading, but that HN is better when comments benefit everyone here.

This isn't a hard and fast rule; I've certainly done my share of 1:1 conversations on HN. But for typos my usual approach is to go look at the author's profile, maybe click through to his website. Sometimes I'll even `git clone` a repo just to harvest an email address ;)

Just my 2 cents. You can keep reporting typos here as well. I'm sure authors would rather get bug reports somehow than not at all. Certainly not the most egregious thing one will see here on any given day.

Re: Why I close pull requests

#74

Post by jimmywanger » Thu, Dec 29, 2016, 3:52 AM UTC

fdsfsaa wrote: post #59

skj wrote: post #57

Earlier quoted context omitted.

We write design docs at Google to communicate ideas with each other. They're useful for promo committees because effective communication between engineers is something that is prerequisite for effective engineering. Of course a full design doc is not needed for every change. Many changes are small and straightforward. Only big things, where the team needs to discuss and understand options. Or bigger things, where dir…

> We write design docs at Google to communicate ideas with each other. I have no problem with individual developers choosing to circulate documents in order to solicit feedback. My objection is to rigid processes that force engineers to write documents. Mandatory design documents for "communication" invariably morph into checklists of required signoffs from people who have little incentive to say "yes". In this way,…

> Prove it. Provide evidence. In my experience...

That's amusing, that you want solid evidence, yet you're willing to use your own anecdotes.

> Mandatory design documents for "communication" invariably morph into checklists of required signoffs from people who have little incentive to say "yes".

Or they make you think about things that are not obvious on first glance, especially at Google scale. For any customer facing feature, you have to make sure that PII is taken care of, that security is implemented properly (SQL injection and XSS vulnerabilities for example), that internationalization is taken care of (especially right to left languages), and that UI fit and finish plays well with design guidelines, in both web and mobile, and that cross browser compatibility is at least thought about, as well as other issues.

> One developer's "unmotivated feature" is another developer's essential use case.

One developer's essential use case is another three dozen developers' backwards compatibility breaking change.

> Through numerous small steps, each apparently reasonable, a nimble organization becomes an ossified nightmare in which it takes six months to add a checkbox.

When you're serving up traffic at those volumes, with datacenters all over the world, accumulating revenue that quickly, yes, it's worth taking six months adding a checkbox to take every possible step possible to ensure that doesn't leak a security vulnerability somewhere.

Just because your individual progress is slow, doesn't mean that the progress of the team is slow. One breaking change in say Google adwords can undo literally man years of work.

Re: Why I close pull requests

#75

Post by debaserab2 » Thu, Dec 29, 2016, 4:03 AM UTC

fdsfsaa wrote: post #47

yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

It sounds like you have some experience dealing with some serious bureaucratic red tape manifesting itself in design doc's.

I don't know if design documents need to be a huge thing with stakeholder sign off and approval processes necessarily - maybe when you're google size. At my (small) company, we use something similar (we simply call them spec's) and it's more of a way to express your concept than it is to get sign off. Sometimes just spelling out an idea helps you validate it.

Really, you should be able to defend a certain amount of criticism if you're writing code that someone (and probably not you, eventually) will have to maintain. Bad changes can be backed out if caught early, but if left they find ways to creep into other areas and cement themselves when they are built upon.

I don't disagree with your main point though, but I do believe there is a balance.

Re: Why I close pull requests

#76

Post by tlogan » Thu, Dec 29, 2016, 4:06 AM UTC

fdsfsaa wrote: post #47

yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

Design, functionality, and test specifications are very important. But the process must be monitored and be very flexible.

I'm not familiar with Google system, but in other big corporations the problem is that you end up with system which does not allow exceptions - so engineers end up requiring writing 10 different documents to make a small change which can be explain on one page and everybody will get it: support, testing, doc writers, etc.

And these documents ended up begin written so that management is happy and not actual intended audience: tester, support, maintenance, documentation writers, etc. So these documents ended up being useless so ....

The worst result is that engineers which do not write good code but write good essays end up with promotion and eventually destroying the entire product (not their fault - they just not talented programers).

Re: Why I close pull requests

#77

Post by unixhero » Thu, Dec 29, 2016, 4:16 AM UTC

zardeh wrote: post #69

fdsfsaa wrote: post #58

Earlier quoted context omitted.

Counterexample: the Linux kernel.

Which leads to problems: see systemd. Also, to be clear, Linux is relatively small compared to Google or Microsoft, or indeed many corporations codebases. Someone could conceivably read the entire Linux kernel codebase. That's not true for BigCorp.

I beg to differ.

https://youtu.be/yVpbFMhOAwE

Re: Why I close pull requests

#78

Post by unixhero » Thu, Dec 29, 2016, 4:24 AM UTC

fourthark wrote: post #27

I know it's not best practice, but I leave them open. For years. They may be fixable, they may be useful to someone. I've no need to reject them unless I really think they're a bad idea. I'm sure this can be frustrating to users and contributors, but I also see it as a way of encouraging forks. "I haven't had a chance to review this, but you might try PR #NN..." The most useful ones get replaced by better versions by…

Yeah. But it is not the way PR and Git is intended

Re: Why I close pull requests

#79

Post by mikepurvis » Thu, Dec 29, 2016, 4:27 AM UTC

akkartik wrote: post #66

mikepurvis wrote: post #37

Earlier quoted context omitted.

I don't know about "automatically", since all the hashes would change, but I definitely do wish that Github had better tools for managing long term forks, especially web workflows for: - rebase this branch on upstream - resolve merge/rebase conflicts - make my master be upstream's master with PRs X, Y, and Z applied to it in that order. I find the last one in particular to be awful, where I'm iterating on multiple PR…

Have you considered just constantly rebasing as you pull? This works well for private forks, but it may also be doable for public forks if you explain what's going on in the Readme. Just an idea. I know it goes against everything we learn about Git, but perhaps it's not so bad in this particular situation.

Yeah, I mean that's basically what you do, but it becomes a huge pain if you're making more than one contribution upstream. You feature-branch-1, feature-branch-2, and then the upstream master with those two branches merged into it. When you update either one of the two PRs, you need to rewind the upstream master and reapply the two merges onto it.

Maybe that doesn't sound so bad, but it feels super awkward to me.

Re: Why I close pull requests

#80

Post by tytso » Thu, Dec 29, 2016, 4:39 AM UTC

fdsfsaa wrote: post #47

yegle wrote: post #13

At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…

Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…

At least in the part of Google where I work (Technical Infrastructure), in general most of the obvious optimizations that can be made at only one level (within the scope of a single programmer, or a single team), have been made long ago. So most of the changes to make the system more efficient will require coordinated changes across multiple teams, and multiple pieces of software, and in some cases, may impact more than one SRE team.

In that kind of situation, you betcha we need to have design docs! And in terms of making it easy for other developers to shoot down ideas, very often they may know about some dependency or key assumption in some other piece of code that you didn't know about it. And it's better to find out about it during the design phase, than to have to rework 50% of your work when you find out about it at code review time, or worse, if it gets deployed and you get angry notes from SRE's that were woken up at 3am and you need to send them a bottle of whiskey to apologize for your f*ck up....