Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I close pull requests

jeffgeerling.com

Post reply on HN
Print view View original

131–140 of 188 posts

Re: Why I close pull requests

#131

Post by zardeh »

kuschku wrote: post #127
zardeh wrote: post #114

Earlier quoted context omitted.

I think the point is that every company that works at this scale does more or less the same thing out of necessity.

Do they? Not even governments do that – instead, they manage billions of people and trillions of dollar by having a hierarchical structure, instead of using a long legislative process for every decision.

Why do you think those two things are impossible to do at the same time. Most companies also have hierarchical structures, and most governments use some kind of bureaucratic process to approve major new projects, I'd expect it to be more bureaucratic than at most businesses.

Re: Why I close pull requests

#132

Post by fdsfsaa »

zardeh wrote: post #130
fdsfsaa wrote: post #125

Earlier quoted context omitted.

> secret If your culture is one of secrecy (Google's generally is not), then you need process to effect coordination, since nothing else can. Fortunately, good (IMHO) software companies are internally open, so there's no secrecy forcing them into heavyweight process. Process is one of the many costs of secrecy. > formalized process The problem with formalized anything is that it involves writing down rules. When you…

> internally open, Internally open does not mean that everyone can always see everything though. >Applying lots of formal rules to good developers just makes them unhappy. I'm not sure I agree with this. I'm a developer, and I'm happier when there are formal rules about human code review, code style, automated testing, and minimal test coverage. I'm happy about those things because they are a small inconvenience (if…

> Internally open does not mean that everyone can always see everything though.

If secrecy is rare in an organization, secrecy-induced problems in that organization are also rare.

> I'm not sure I agree with this. I'm a developer, and I'm happier when there are formal rules about human code review, code style, automated testing, and minimal test coverage.

It takes all kinds, I guess. Personally, nothing galls me more than having to follow a rigid set of rules when I know the original motivation for these rules doesn't apply to my situation. I'd make a terrible soldier.

I understand your social contract argument, but IME, the benefit to me of other people writing design documents isn't big enough to justify my having to do it. I find that subscribing to actual code reviews targeting directories that interest me gives me enough ability to see and affect (and unfortunately, sometimes block or delay) changes before they go live.

Re: Why I close pull requests

#133

Post by jon-wood »

fdsfsaa wrote: post #105
jimmywanger wrote: post #101

Earlier quoted context omitted.

> There are companies with data needs, user counts, and codebase sizes on par with Google that don't practice Google-style process, yet succeed anyway. Which? The ones I can think of are Apple and Microsoft, and I'm pretty sure they practice Google-style process. Amazon has its own flavour of process which is heavyweight in its own way. What are you thinking of? > Code-level concerns. You're not going to stop SQL inj…

It's funny that you mention Microsoft. A friend (he has ~100 reports, transitively) at Microsoft tells me that at least on his team, the old-fashioned three-specification (design, dev, test) document triplet, each with a multi-page checklist-laden Word template, has been supplanted by a lightweight scheme that boils down to one or two paragraphs. That's real progress. Microsoft even runs successful open source projec…

> Process should be proportional to the difficulty of undoing a mistake. If a mistake is easy to undo, it should be easy to do. If a mistake is very costly to undo, it's worth investing in not making the mistake in the first place. > The vast majority of programming errors are of the "easy to undo" variety.

At Google's scale even small issues will have widespread impact on real people. Let's say you break the ability to reply to email in GMail for ten minutes - cumulatively that could result in hundreds of hours of lost work across all their users.

Re: Why I close pull requests

#135

Post by tigershark »

zardeh wrote: post #113
fdsfsaa wrote: post #100

Earlier quoted context omitted.

I don't think any specific type of change should require a design document. That framing presupposes too much hierarchy. Design documents, like code reviews and tests, ought to be helpful tools for developers, not requirements imposed from above. I've worked at companies that didn't require design documents, but occasionally wrote them anyway because I wanted feedback. Another trigger could be a reviewer commenting,…

(to be clear, this is all made up) Well let's put it this way, let's say that I'm a googler, I work on the android team and I want to rewrite the launcher from the ground up because I have some whiz-bang idea. This falls under my general purview of stuff that my team works on, so I grab my coworker, and for a month we hack away at it and have a good MVP. It has great improvements over the existing homescreen. We've b…

This has absolutely nothing to do with design documents. As a developer you are not supposed to start working on whatever you like, you need to follow the big plan. Is it really like this in google with developers wasting their time just writing design documents on whatever they like that will obviously be rejected rather than doing the work that is expected from them? I don't think this is very productive with people working on a whim instead of following a plan in a coordinate way.

Re: Why I close pull requests

#136

Post by emmab »

If a given PR would be acceptable except for its maintenance burden, and you do not expect the PR submitter to provide sufficient help with maintenance to compensate, you could request the difference from them as payment for acceptance of the PR.

Re: Why I close pull requests

#137

Post by ageofwant »

sanxiyn wrote: post #83
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?

I use stars for this, but I guess one could use forks as kind of "super stars".

Yes, I'll almost certainly star a project if I forked it. I certainly star way more than I fork, I assume most people would do the same.

Re: Why I close pull requests

#138

Post by palunon »

unixhero wrote: post #78
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

Git is intended to work over email.

How do you close an email PR ?

Re: Why I close pull requests

#139

Post by fapjacks »

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 ?

Yeah, this is what I do, too. Also keep in mind, though, that you'll need to exfil your fork if you think it might disappear at all from Github. They yank the original repo and all of its forks for example if they get a DMCA notice. Years ago, I set up automation that pulls repos that I've forked, so for me, the act of forking ensures I get a copy of the code imported into my personal Gitlab instance on my home LAN.

Re: Why I close pull requests

#140

Post by Confusion »

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 creates a presumption of incompetence
No, it acknowledges the reality, that people, including you and I, don't know what is good for them.

Being forced to come up with design documents is very similar to forcing doctors to use checklists. They complained, and still complain, that they are professionals and don't need the bureaucracy and 'assumption of incompetence'. But the numbers speak for themselves: there are much fewer medical errors when they are forced to use simple checklists.

My colleagues are all competent, yet they produce much better work if they are forced to first come up with a design document.

Post reply on HN