vault_

> - A big queue of PR's for reviewers to review

This is a feature. I would infinitely prefer 12 PRs that each take 5 minutes to review than 1 PR that takes an hour. Finding a few 5-15 minute chunks of time to make progress on the queue is much easier than finding an uninterrupted hour where it can be my primary focus.

> - The of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)

It increases it a little bit, sure, but it also helps keep things focused. Reviewing, for example, a refactor plus a new feature enabled by that refactor in a single PR typically results in worse reviews of either part. And good tooling also helps. This style of code review needs PRs tied together in some way to keep track of the series. If I'm reading a PR and think "why are they doing it like this" I can always peek a couple PRs ahead and get an answer.

> - You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you

This is a tooling problem. Git and Github are especially bad in this regard. Something like Graphite, Jujutsu, Sapling, git-branchless, or any VCS that supports stacks makes this essentially a non-issue.

Where this breaks down, as I've experienced at least, is that the product management side maintains basically zero awareness of the production constraints engineers are working within. If you've built out a painting production line around spray guns and beige, that has knock-on effects as to what results are attainable. A PM asking for polka-dots next sprint is throwing into question the entire body of practice, but this happens with extreme frequency in software.

I didn't realize they were actually selling a 10 Gbps service tier as part of this branding. It's never been available in my market, so I assumed that they were advertising the uplink capability of the thing my modem was connected to! Happy to see this go, but I'm still shocked to learn that the name was _less_ misleading than I had thought.

Autoscaling seems like a downstream concern from the techniques being discussed here. Autoscaling tends to have a pretty high latency, so you still need a strategy for being overloaded while that extra capacity comes online. There's also a question of how the autoscaler knows what "load" is and when it's "too high." Just going off of CPU/memory usage probably means you're over-provisioning. Instead, if you have back-pressure or load-shedding built into your system you can use those as signals to the autoscaler.

> Real products built today have a finite amount of demand, and global cloud capacity is larger than that.

This isn't really true, and it's especially not true when specialized hardware comes into play. If you have a "web-scale" GPU workload, it's not unlikely that you'll hit resource availability constraints from time to time. The question isn't whether cloud capacity is larger than your demand for a particular resource, it's whether cloud capacity is larger than the aggregate peak demand for that resource. Cloud providers aren't magic. They engage in capacity planning, sometimes underestimate, and are sometimes unable to actually procure as much hardware as they want to.

Yeah, I don't think circuit breakers are really the appropriate choice in most of the situations the article is describing. Rate limiting and backpressure seem like better options most of the time.

The way I see it, circuit breakers are safety devices. They're for when you need to keep a system in a safe control region and are wiling to sacrifice some reliability in order to achieve that. e.g. preventing customers from accidentally turning your globally distributed whatever into a DDOS platform or limiting the blast radius when infrastructure automation decides it should delete everything.

Nested replies are definitely better as a way of consuming a post and its comments once and then never thinking about it again. For an asynchronous discussion between several people they get unwieldy after a few rounds of replying. They also make it harder to coherently reference points made cross-tree. That plus algorithmic ranking gives a constant feeling of "gotta refresh to see if there's new stuff" that serves a site like Reddit well, but it makes it much harder to have a longer discussion with more back and forth.

Having recently started participating in a community where most useful discussions are on a PhpBB forum, going back to linear posting was actually refreshing. It's easy to stay on top of because you can check in once a day or so and see just the conversations that have updates since you've last checked them. Threads being sorted by most recently updated means you focus on where there's active discussion. And once you've read those things there's no reason to stick around. "That's it! Get back to doing something useful."

Obviously, this doesn't really scale to a community the size of reddit, but I think it's really pleasant for medium-sized communities.

> A doctor knows what his practice is worth and wants every cent he can get out of it - but the next generation of doctor is not going to be able to compete with debt financing what a PE cash-buyer can get.

In my opinion, the physician in this example is a monster. Profit maximization is a choice, not some kind of moral imperative. Am I supposed to have any respect for somebody selling out their employees and patients to vampires so they can retire to a beach or whatever?

The solution I'd want to see for situations like this is to find a way to sell to the people who have a continuing interest in how the business is run: employees and customers. The "exit" that does right by all interested parties would be something like having a newly formed employee coop gradually buy out the founder's ownership stake. To make a tech analogy, you don't have to sell your 0-day to foreign government just because they pay more than the bug bounty program! You don't have to sell out your community to vampires because they're the highest bidders! This is a choice that somebody is making.

It's not "general purpose computing" maintenance, but the service you're talking about does exist, though AFAIK mostly at the very high-end. It's typically for things like home theaters, whole-home audio systems, or smart-home type setups (predating and now merging with current consumer IoT/home automation platforms). Not sure how much that's "maintenance" in the typical sense so much as support for their custom install work, but I bet if you had a Sonos or Lutron system where your installer went out of business you'd be able to find a different guy to deal with it.

What's the confusion? The allegation is that choosing to build this represents, at best, incredibly poor judgment. The GitHub issue and GP post are good faith appeals to kindest possible interpretations of this work. To use your own example, explosives can be useful, but if you discovered that your neighbor was building pipe bombs in his garage, you'd probably want them to stop. "I'm not gonna use them. I just think they're neat." is not a convincing argument for them to continue. To extend the analogy a bit further, this seems comparable to discovering a box full of pipe bombs with a big "free" sign in front of their house.

This isn't a fair analogy. There's a cost to adding new tools to a software environment, and an ongoing cost to maintaining that tool. Closer, IMO, is you're speccing out a new house with a builder and ask for a swimming pool, a hot tub, jacuzzi tubs, and body sprayers in the showers. Getting all of those installed and running to spec is going to be much more expensive than getting one or two of them. If your builder says "You really need the pool. I'll see if I can get that dug in my free time, don't worry about it." you are probably going to worry about what you're actually getting. If you do have the budget to do everything properly, you also need to have the ongoing budget for cleaning and maintenance. Pools and tubs have very different maintenance profiles. The same is true for software.

Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.

How does being able to point at a database prevent land being stolen in the absence of a trusted third party? It's not like the land itself can authenticate the farmer. For the database to have any weight, there'd need to be an authority that can enforce what it says (and won't take bribes to ignore it, or collude in extorting "voluntary" transfers). If you do have such an agency, well, there's your trusted third party.

Interesting concept! A couple quick things I noticed trying to use the site.

First, you can't view product details without paying for a subscription. I wanted to look at the t-shirt to see basic details like sizes available, product measurements, material, and country of origin. I made an account but that still requires paying $70 before I can actually see product details. That's a tough pill to swallow for something I might not want to buy.

Next, there's not a return policy specified anywhere (maybe if you have a membership?). For online clothing stores, I tend to expect that returns are included, but the price-point here would make me more cautious. Does the membership pay for my returns?

Finally, the products themselves seem pretty generic (I realize that's the point). But there's a difference between "we created/are using a generic pattern" and "we are reselling blanks intended for printing. Specifically, why should I buy the latter from you? And if they’re original designs that are made well and from quality materials, what actually goes into that?

That really depends on what you're working on and to what degree it's coupled to the system it's a part of. A form on a web application, or an API endpoint? Sure, rewriting it is probably trivial. A new process scheduler for Linux? The caching system in an HTTP server? Maybe writing the code will be easy (though probably not), but building any confidence that it doesn't break something that's unexpectedly load bearing will be anything but cheap. And if what you're rewriting that started out as "just code and see what happens" it's going to be more expensive still.

Which isn't to say that rewriting can't be cheap, but some intentional design (or at least diligent maintenance and refactoring) must have gone into the system to support that style of development. At which point you're back to targeting "quality," even if it's no longer a focus of on the smaller scale.