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

171–180 of 188 posts

Re: Why I close pull requests

#171

Post by zardeh »

tigershark wrote: post #135
zardeh wrote: post #113

Earlier quoted context omitted.

(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 peopl…

You're exactly correct. Outside of 20% time, I can't see that example being really realistic (at least not at Google for an android launcher, there are other companies where I've heard of 10+ competing internal libraries for the same problem developed by different teams).

In the case that you're asked to implement a project from 'above', they're still useful, for practically the same set of reasons (maybe minus #5, but plus 'other people who you impact can provide feedback to reduce future friction')

Re: Why I close pull requests

#172

Post by digi_owl »

scaryclam wrote: post #161
digi_owl wrote: post #149

Between the responses here and on the more recent Chrome for business posting, i find myself wonder if there is a ever widening split between the "push to prod" web dev mentality, and the "clasic software" mentality.

I think there's always been a "just ship it" and "let's make sure it's well tested" split. I find that there's also the cowboy coders, who tend to create nasty problems constantly pushing to production and breaking things for users, and the folks who push to production often but make sure what they've pushed is well covered by unit and functional tests, as well as having been properly designed and signed off before s…

I feel it is a growing trend as the net makes it easier and easier to go "release now, patch later".

Except that rather than patch later it gets left in place. And then rewritten from scratch in whatever is the buzzword language of the day some years down the road as the guard changes.

Re: Why I close pull requests

#173

Post by jimmywanger »

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…

> Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google.

I don't know what you think of Google's process. A design doc is needed for any large user facing change or large infrastructure change, and it goes through sections and you skip the ones that are not applicable.

For instance, if you're not storing user information, you skip the PII section and so forth. If you're just making a change to adwords billing, you skip the entire I18N section.

Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integrations. You can play fast and loose with those, as opposed to Google, which doesn't really have any legacy code and has to support all existing users.

> When your developers are both smart and invested in the product's success, they learn about these things on their own. Sure, they can make mistakes, but so can some damned review committee.

The review committee does this for hours a day, and they see far more cases. That's like saying that it's better for you to assess the condition of the transmission of your car, because you care more and are more invested. I'd rather have the guy who rebuilds transmissions for a living, who has seen dozens of transmissions, and is familiar with common failure modes and pitfalls.

Specialized labor does help.

> The Brooklyn Bridge was designed to be six times stronger than it needed to be for its design load.

Well, heavier than air flight was impossible before the 1890's without investment in materials, engines, and construction techniques. Is it easier to build an airplane now? I still fail to see your point. We're talking about something where you have to invent the tools to make the tools to make what you want to make, vs. already having the tools available.

> Pseudolocalization and dogfooding help. I'd argue that rapid iteration helps most on UIs.

AB testing on wireframes helps and gets most of the edge cases. After you roll out to production things get hairy.

> It's a lot easier to back out a problem diff than to remove the staph you accidentally introduced into a patient's bloodstream.... The vast majority of programming errors are of the "easy to undo" variety.

Not really, when you're working on fundamental libraries that many products depend on. That can cause issues all up and down the product stack, and you're going to cause issues for developers who rely on your code who now have to throw away months of work.

> Uber recently delivered beer fully autonomously. In a truck. They're definitely planning for L5 autonomy.

That's a publicity stunt, and it's unknown whether or not they got paid or not. Also, Otto was based from Google expats, one from Google maps and one from the Google self driving car company. Your point is?

Re: Why I close pull requests

#174

Post by optionalparens »

beat wrote: post #156
fdsfsaa wrote: post #97

Earlier quoted context omitted.

> 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.

Not sure what you are replying to, but I think at least parent is saying because people aren't as good as they should be, you put processes in place. I don't think anyone is saying what you stated. Most companies might believe they are hiring the best, but their coworkers are the ones that know otherwise and do things like use design documents to give some structure where needed.

In other words, you take measures to catch errors, mitigate failures, and protect yourself rather than say "go code and push to production everyone, we can just roll back!" That might work as stated in some domains, but not others.

Re: Why I close pull requests

#175

Post by leepowers »

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…

Wait, you don't spec out project changes? You just start writing code and attempt to figure it out as you go along? That seems like a recipe for disaster, or at least a lot of wasted effort. How do you even quantify that you've done something useful if you haven't set a goal that everyone can agree on?

Re: Why I close pull requests

#176

Post by vickychijwani »

Marazan wrote: post #134

The fact they have to state they won't accept pull requests that break the build astounds me. Who is submitting pull requests that break the build? That is akin to trolling.

There are junior/newbie devs unfamiliar with the concept of CI etc, who will often submit working code without updated tests, and in that case it's up to the community/maintainer to point them in the right direction and help get their PR merged. An important first step to lay the foundation for future contributions :)

Re: Why I close pull requests

#178

Post by hhandoko »

fdsfsaa wrote: post #112
hhandoko wrote: post #106

Earlier quoted context omitted.

It helps identify potential problems / conflicts across teams even before a single code is written (or development time committed).

I don't think so. Who looks at design documents? Your own team. If you don't yourself catch that a change will cause problems with other teams, the existence of a design document won't magically alert that team. If you do suspect that there might be a bad interaction with another team, you can alert that team with or without a design document. So again: how does a design document requirement help?

You're making the assumption that other teams and other leaders won't review your docs. In my experience, they do and always come back with more questions.

> If you do suspect ...

And that's exactly it. If I suspect something then of course I can communicate it directly or redesign, but we're trying to assess impact on areas I might not have no awareness of.

So let's put it in another way:

Design docs is one of many formal methods of communication in any organisation. It preserves context, change history, and a good part of risk management. It protects you and potentially saves downstream rework.

Re: Why I close pull requests

#179

Post by fdsfsaa »

jimmywanger wrote: post #173
fdsfsaa wrote: post #105

Earlier quoted context omitted.

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…

> Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google. I don't know what you think of Google's process. A design doc is needed for any large user facing change or large infrastructure change, and it goes through sections and you skip the ones that are not applicable. For instance, if you're not storing user information, you skip the PII sec…

> Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integration

The example I have in mind is in a big legacy product. I can't get more specific without outing myself, but it's very far from greenfield.

> Specialized labor does help.

Specialization of labor can also hurt. I've found myself frustrated with security people in the past because they spend so much time thinking about security threats that they start to veto massively useful functionality on very flimsy security grounds. Broad exposure helps too.

> AB testing on wireframes helps and gets most of the edge cases. After you roll out to production things get hairy.

Why? There's no rule that says that everyone needs to see the same UI in production.

> Otto was based from Google expats, one from Google maps and one from the Google self driving car company. Your point is?

It's telling that Google autonomous drivers experts had to leave the company in order to get their work into a real live product.

Re: Why I close pull requests

#180

Post by taneq »

mdpopescu wrote: post #109
fdsfsaa wrote: post #59

Earlier quoted context omitted.

> 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,…

> Through numerous small steps, each apparently reasonable... I think I read somewhere that, on an online shop, each step you add to the checkout process halves the number of people who complete it. If true, that is a powerful argument for what you're saying. Also reminds me of Bastiat's "What is Not Seen". We don't see the developers who chose not to go through the whole process because it was too tedious.

> I think I read somewhere that, on an online shop, each step you add to the checkout process halves the number of people who complete it.

I wonder how much of that is just "more steps bad", and how much is that any step you add to a checkout process beyond what is necessary for the actual sale is (a) forcing you to do something you don't care about, and (b) going to make it more intrusive? Eg. forcing you to create an account, forcing you to validate an email address, forcing you to fill out a "quick survey", forcing you to unsubscribe from their marketing spam.

There have been plenty of times that I've wanted to buy an item from an online store but have decided against it because the store wants to "create a relationship" with me instead of just selling me the damn item.

Post reply on HN