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

161–170 of 188 posts

Re: Why I close pull requests

#161

Post by scaryclam »

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 starting work at all. The former seem to have commented a lot on this article, which I find quite sad if it's a growing trend :(

Re: Why I close pull requests

#162

Post by j1vms »

The article brings up a lot of great points. Though people do need to be mindful lest they be writing a follow-up, "Why my project got forked, and I now sidelined."

Re: Why I close pull requests

#163

Post by dmuhs »

This article gives a nice view for someone who hasn't had that much experience with OSS development like myself. While I'm kinda familiar with CI systems and the concept of coverage, could someone explain to me what the author means by "happy path" in coverage? Is that considered the most used path in standard behaviour?

Re: Why I close pull requests

#164

Post by geerlingguy »

dmuhs wrote: post #163

This article gives a nice view for someone who hasn't had that much experience with OSS development like myself. While I'm kinda familiar with CI systems and the concept of coverage, could someone explain to me what the author means by "happy path" in coverage? Is that considered the most used path in standard behaviour?

> Is that considered the most used path in standard behaviour?

Yes, basically. If you're building an application that allows people to submit a contact form, then the happy path would be something like:

  1. Load form
  2. Verify the correct fields are there
  3. Fill out form with valid data
  4. Submit form
  5. Verify submission went through correctly
The happy path is a minimum viable test to make sure things are working. For completeness, you'd also want to make sure that input is sanitized, invalid input (e.g. non-functional email addresses) causes a form submission to fail, and layout looks correct (e.g. CSS styles applied).

Re: Why I close pull requests

#165

Post by kingosticks »

alaaibrahim wrote: post #45
asdkjfsad888 wrote: post #22

Earlier quoted context omitted.

> I see a problem that I can fix... Remember, they said "out of the blue" which means "without prior contact to discuss doing so." This exact reason was explained in the parent post: maybe the maintainers and project owners don't see it as a problem or are already working on something. It's not just about being a machine that can crank out fixes to the individual issues in software wherever you see them. It's about p…

> Remember, they said "out of the blue" which means "without prior contact to discuss doing so." If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do. > If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road. I think you should always assume with…

> If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do.

There doesn't have to be a commitment to do anything. You are opening an issue and starting a dialogue. If you then disappear, someone else can come along later and implement/fix it with the benefit of the original discussion.

Re: Why I close pull requests

#166

Post by fdsfsaa »

user7474 wrote: post #157
stinkytaco wrote: post #50

Earlier quoted context omitted.

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.

Where are the mods? Does the rule against inflammatory ad-hominem attacks apply only to those holding unpopular opinions?

Believe me, I'm the furthest thing from junior you'll ever see. I don't particularly care what you call me, but I'm produced tons of value.

There's a certain type of mid-career programmer who's obsessed with "best practices" and thinks that anyone who doesn't stuff a program full of design patterns is being incompetent and irresponsible. It's a kind of "sanctimony porn". The attitude is that "if programming is hard for me, it'd better be hard for you too". It's this kind of programmer that shames other programmers for having opinions that result in the creation of simpler code.

I hope you grow out of this phase.

Re: Why I close pull requests

#167

Post by fdsfsaa »

beat wrote: post #155
fdsfsaa wrote: post #110

Earlier quoted context omitted.

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?

Do you have any actual evidence that a culture of design documents and signoffs produces code with fewer vulnerabilities?

Re: Why I close pull requests

#168

Post by fdsfsaa »

beat wrote: post #153
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 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.

I can choose not to work in an environment riddled with "scar tissue". Instead, I can go work at a startup and eat that enterprise's lunch with a tenth of the budget. Unfortunately, thanks to inflexible and sanctimonious attitudes some programmers adopt about what is and is not "responsible" engineering, the only way to change practices is to beat the old practices in the marketplace.

Re: Why I close pull requests

#169

Post by zardeh »

kuschku wrote: post #151
zardeh wrote: post #131

Earlier quoted context omitted.

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.

Really?

Everything I'm familiar with has approval and review on everything in government, bureaucracy is synonymous with government to many people for exactly this reason.

Re: Why I close pull requests

#170

Post by fdsfsaa »

jon-wood wrote: post #133
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…

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

What about all the hundreds of decades of work lost because extreme risk aversion makes it impossible to add productivity features to GMail for fear of breaking what works already?

Some people like to cower behind "Google scale" as a reason never to change anything. Not me.

Post reply on HN