I’ve found utility in <i>removing</i> code.<p>I feel that doing the job with the fewest lines of code, is best.<p>I also believe in focused/pure scope. If I write a type or API to do a job, then it should do that job, and <i>only</i> that job. If I want to add functionality that is out-of-scope, then I’ll often write another type, instead of adding it to the existing one. Making this type of decision is always fraught.<p>But, like in all things, it depends. Sometimes, reducing the overhead of things like setup and testing is a good reason to not introduce a whole new resource, but I should make it a point to document the <i>reason</i> for the incongruity.<p>This is especially true, when designing user interface. I’ve found that, usually (not all the time, though), less is more.<p>Josef Albers is known (amongst other things), for the quote “Sometimes, in design, one plus one is three or more.”.
The counterpoint is that building software is not building a fence. When you create something in software, nothing tangible changes until that's accepted and running on all the places that you deploy to. A PR is just a hey, here's a fence that the contributor built elsewhere that proves that building something like this is possible.<p>The corollary is design your open source libraries so they're obvious enough that the chesterton's gaps are obvious. Anytime an AI tool submits something that breaks your expectation of things not being necessary it usually highlights that there's a missing gap in the explanation of what is necessary.
I’m not sure I share your view of PRs. I still see submitting PRs as something that puts pressure on maintainers. Even incorrect PRs take time to verify and review.<p>I also don’t see how this differs between the “gap” and the “fence” part of the metaphor. Whether someone submits a rewrite/removal (fence) or a new feature (gap) for PR review, it’s still going to cost me attention.
It's only pressure if you believe the social contract in a PR is that everything that is written is something you're obligated to read / respond to. If you flip that a bit to a PR being the first step in a way of saying "I tried a thing and it worked, what's necessary to make that an actual thing that other can use", then you will sort of land here.<p>Previously I wrote <a href="https://news.ycombinator.com/item?id=48517931">https://news.ycombinator.com/item?id=48517931</a>
Related to this, the concept of "free as in puppies" from D. Richard Hipp, creator of SQLite:<p>> Suppose you had a pull request for SQLite. "Hey, I've got this new feature for SQLite. Here's the pull request." When you want me to pull that into the tree, you say, "Oh, it's free."<p>> No, it's not free. What you're doing is asking me - you've got this cool feature, and you want me to maintain it for you, to document it for you, to test it for you, to maintain it for you for the next twenty-five years. That's not free.<p>> Linus Torvalds is famous for saying there's free as in beer and free as in speech. But there's another kind of freedom: free as in puppies. "Oh look, I've got a free puppy for you." You see where this is going?<p>> A pull request is a free puppy. And then you've just got a kennel full of puppies at the end of the day. And you can't just throw them out - you're morally obligated to take care of them for their natural life.<p>> I don't want any free puppies.<p>source: <a href="https://youtu.be/x8_ZZhRL3YU?t=1715" rel="nofollow">https://youtu.be/x8_ZZhRL3YU?t=1715</a>
Thanks! This is very similar indeed. Related: I see a lot of “drive-by” PRs by agents, who obviously have no intent of ever maintaining the code they wrote.
FYI there are quite a few glitches in there:<p>> and want you want me to maintain it for you<p>> to to document it for you<p>> Linus Torvalds is famous famous<p>> A pool request<p>> They're you you're you're morally obligated