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

151–160 of 188 posts

Re: Why I close pull requests

#151

Post by kuschku »

zardeh wrote: post #131
kuschku wrote: post #127

Earlier quoted context omitted.

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.

But that’s even not the case, that’s the point. Most governments let their government agencies just do things, without unreasonable bureaucracies like these.

Re: Why I close pull requests

#152

Post by dang »

realstuff wrote: post #128

Sounds like an arrogant bastard.

You've posted quite a few uncivil and/or unsubstantive comments to HN. That's not what this site is for, so please stop doing that. You can read the following to get an idea of what we're looking for here:

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Why I close pull requests

#153

Post by beat »

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…

I can tell you've never dealt with one of those trivial backouts on a product that moves a hundred billion dollars a day and is a key component of the entire US economy. Or a product where a bad software deployment can actually kill people.

Process is the scar tissue of the enterprise. Those scars are there because the enterprise was wounded. Lots of process, many scars.

Re: Why I close pull requests

#154

Post by beat »

dcosson wrote: post #116
fdsfsaa wrote: post #47

Earlier quoted context omitted.

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…

> A culture that requires permissions and signoffs before work can begin is a culture that leaves products stagnant for years. I've also seen the exact opposite being the case. A culture where everyone does whatever they're in the mood for without running ideas by other teammates who will have different experience in different areas of the codebase, can leave products stagnant for years. Tech debt builds up and the s…

I call that "The inmates running the asylum".

Re: Why I close pull requests

#155

Post by beat »

fdsfsaa wrote: post #110
dismantlethesun wrote: post #89

Earlier quoted context omitted.

I thought design documents and reporting were mandatory for 'engineering'. As is things like ethics, and organizational standards, and testability. Move fast and break something is the domain of hacking.

If it produces results, does it matter whether you call it "engineering" or "hacking"?

It depends on the result. If the result is public embarrassment of the company and the loss of millions in market worth? If the result is someone dying?

Re: Why I close pull requests

#156

Post by beat »

fdsfsaa wrote: post #97
optionalparens wrote: post #91

Earlier quoted context omitted.

This attitude strikes me as very SV/HN and while I can appreciate certain elements here, the answer is the typical one - "It depends." Rather than regurgitate what most people here already said, let me list a few programming projects, domains, and tasks where at least thinking about design if not writing design documents or spending days, weeks, or months figuring it all out is worthwhile. * Programming Languages * D…

> 99% of them are idiots and have no business being programmers I feel the same way. If you have a group of idiots, you need process as a harm reduction measure. A very high contributor bar is a prerequisite for a process-light environment, because if you can't trust people to do the right thing, you need a system to force them into a conservative approximation of the right thing, and this system is called process.

So what you're proposing is that every company hire only the best?

That's what they all think they're doing. Math doesn't work that way.

Re: Why I close pull requests

#157

Post by user7474 »

stinkytaco wrote: post #50
fdsfsaa wrote: post #47

Earlier quoted context omitted.

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…

I can't comment on Google's culture, but: >Design documents turn every feature into a half-assed, lowest-common-denominator risk-minimized shell of itself. Sounds like a sentence written by someone who is an engineer and not a support staff or a user, i.e the people who have to deal with the fallout of every feature change and every engineering decision. I could just as easily substitute "feature driven design" into…

Ouch. I don't think I've ever met a competant engineer who would agree with the sentence. The person who posted it is obviously very junior and I don't think I'll ever call him/her an engineer if they don't manage to mature away from that kind of prattle.

Re: Why I close pull requests

#158

Post by scaryclam »

nathancahill wrote: post #67
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…

As a less formal version of PEP/design docs, I always open an issue on Github projects proposing the changes that I would submit in a PR before I do the work, and end by asking if there's interest in a PR that implements those changes. That requires very little effort and avoids a lot of wasted time on both sides.

This, unless my PR is addressing an already open issue. For larger ideas/changes that may be difficult to explain, I may open an initial PR, but make it clear that it's for illustrative purposes and that I don't expect it to be accepted or to remain open.

On occasion I've saved myself a whole lot of time when one of the maintainers agrees with the proposal and reveals they're working on something very similar already.

Re: Why I close pull requests

#159

Post by scaryclam »

sfifs wrote: post #121
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…

this strategy is ok as long as you explicitly indicate in the issue you might not get around to reviewing soon but to go ahead and fork. I've seen too many folks who just leave PRs hanging which leads to frustration. People will remember and think twice about contributing to anything with your name/id in it.

I'm actually quite bad for this. I think this year I might make it a new years resolution to retroactively apologise and add comments about forking, and try to make sure any future PRs get an answer one way or another.

Re: Why I close pull requests

#160

Post by yawz »

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's much better to move fast and iterate quickly than to create an illusion of care and add friction to every aspect of the development process."

This!

Post reply on HN