vault_ (u/vault_) - Readit News

vault_ commented on The Theatre of Pull Requests and Code Review meks.quest/blogs/the-thea... · Posted by u/todsacerdoti

davedx · 6 months ago

It's a very common refrain but I don't really agree with it:

"How do you create a PR that can be reviewed in 5-10 minutes? By reducing the scope. A full feature should often be multiple PRs. A good rule of thumb is 300 lines of code changes - once you get above 500 lines, you're entering unreviewable territory."

The problem with doing this is if you're building something a lot bigger and more complex than 500 lines of code, splitting that up across multiple PR's will result in:

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

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

- 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

The right answer for the size of a PR is NOT in lines of code. Exercise judgement as to what is logically easier to review. Sometimes bigger is actually better, it depends. Learn from experience, communicate with each other, try to be kind when reviewing and don't block things up unnecessarily.

vault_ · 6 months ago

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

vault_ commented on Scrum's “Product Owner” Problem rethinkingsoftware.substa... · Posted by u/rbanffy

ungreased0675 · a year ago

I have to disagree with the central argument, which is to give engineers more product management responsibilities. A way I’ve handled priorities as a PM is by setting the order of the backlog. At sprint planning, the team collectively decides what to pull off the backlog, and it doesn’t have to be the top stories that add up to our expected points goal. If the team goes diving to the bottom of the list for a bunch of trivial stories, then that sparks a conversation about why we have different priorities. Product owner isn’t a dictator, but they are ultimately responsible for the product.

Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role. I think some engineers like the side quests because they’re fun. In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls. If everyone in the kitchen had to do market research at other restaurants, pick up ingredients from local farms, and test new menu concepts, the place would be out of business in short order.

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

vault_ · a year ago

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.

vault_ commented on iPhone 16 Pro and iPhone 16 Pro Max apple.com/newsroom/2024/0... · Posted by u/mfiguiere

laweijfmvo · 2 years ago

So did they just give up on Blood-Oxygen sensing on the Watch? Thought it might be a good time to update my Watch 6 (black titanium) to a 10, since they brought back the black titanium, but they just have no answer for the blood-oxygen lawsuit?

vault_ · 2 years ago

Probably a result of the patent dispute over the feature: https://apnews.com/article/apple-watch-patent-dispute-sales-...

vault_ commented on Comcast reluctantly agrees to stop its misleading "10G Network" claims arstechnica.com/tech-poli... · Posted by u/thunderbong

vault_ · 2 years ago

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.

vault_ commented on Queues don't fix overload (2014) ferd.ca/queues-don-t-fix-... · Posted by u/akbarnama

0xbadcafebee · 2 years ago

The only real solution to overload (that is, the eventuality of the system not having enough capacity), in modern systems, is autoscaling. Nobody seems to talk about this, I guess because it's taken for granted? But you can literally just keep adding capacity now. We didn't really have that before the cloud; you had the servers you bought, and maybe you'd rush to repurpose some servers to add capacity. Now an algorithm just adds servers magically when your load gets high.

Of course the system still has limits. But if you go from zonal to regional to global autoscaling, and you architect specifically to scale up each point in the system using autoscaling, it kind of doesn't have a limit? (that any one product would hit, at a global level)

In the past I have spun up a duplicate distributed system in another region and just split the traffic between the two. IaC is crazy.

vault_ · 2 years ago

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.

vault_ commented on Queues don't fix overload (2014) ferd.ca/queues-don-t-fix-... · Posted by u/akbarnama

0xbadcafebee · 2 years ago

There's no product in the world that would hit a limit if autoscaled globally on AWS. Sure, you could write an app whose literal sole purpose is "take up all memory, CPU and bandwidth, recursively, infinitely", but nobody is making that product. Real products built today have a finite amount of demand, and global cloud capacity is larger than that.

You can't say what architecture is or isn't profitable in general, business is more complicated than that. But besides the realities of commerce, you can easily architect a system such that the autoscaling cost is a fraction of opex.

vault_ · 2 years ago

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

vault_ commented on Architecture Patterns: The Circuit-Breaker lab.scub.net/architecture... · Posted by u/kiyanwang

jerf · 2 years ago

I would think the first resort in most of the non-flooding-related cases[1] is backpressure. If you've got too many requests coming in, be sure that internally you start parking the excess incoming requests in some low-resource-usage configuration (e.g., simply noting the incoming TCP connection but then not even read()ing from it until you are ready), and let the system push back naturally by the way its latency increases. This obviously naturally pairs with both client-side and server-side timeouts, giving both a vote in how long they're willing to wait.

This is generally what you want. Actively breaking the connections if I think I'm overloaded is only something I'd add if there is some additional constraint on the system that suggests it's a good idea due to some specific local concerns. Circuit breaking produces a much sharper (for lack of a better term) performance graph, where instead of degrading gracefully like backpressure will, you suddenly start getting active failures.

I've built a lot of backpressure in my systems; I'm yet to need a circuit breaker. YMMV, of course, but I see some people referring to it as a basic tool and I would disagree; the basic tool is backpressure.

[1]: Flooding is its own thing. In general, to weather DOS attacks but still have the service functional requires another system or likely set of systems in front of the service that can handle the DOS issues. I say this just to point out that circuit breakers aren't really for this case, because no system can on its own handle a full-on DOS flood, no matter what code you write, when the DOS flood may literally be coming in at a speed where it is faster than you can even reject connections, let alone do any work.

vault_ · 2 years ago

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.

vault_ commented on PhpBB phpbb.com... · Posted by u/rpastuszak

babypuncher · 3 years ago

The way reddit's threads work with nested replies is also a vastly superior UX over the linear firehose approach of a conventional forum. So much so that pretty much everyone has resorted to copying it over the last 15 years.

There's a reason phpbb went the way of the dinosaur and won't be making a comeback. The future is going to be something that learns from Reddit's mistakes without regressing to 2001 usability.

vault_ · 3 years ago

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.

vault_ commented on Private equity is buying everything from vet offices to tech conglomerates theverge.com/23758492/pri... · Posted by u/Brajeshwar

legitster · 3 years ago

Despite the directions the interviewer tried steering this conversation into, this is a really interesting interview.

But when it comes to the private equity roll-ups, I think everyone is missing the forest for the trees. If you are a doctor looking to retire and sell your business there is no one else right now who would buy it. The same goes for every category of "mom and pop" business in the US. Even if you could find someone experienced enough and interested in running it - that person could not afford the business.

So there is kind of a double problem happening right now. One is simply demographic - experienced business owners are retiring at a much faster rate than they are being replaced. Secondly, there is the capitalization problem. 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 addition, there is a problem specific to medical practices - you can't just hand them over to your kid! (unless they also happened to pursue the exact same medical training you did). And in addition to this medical schools (as I have been told) are really underprepared new doctors for running a business.

Keep in mind owner-operators already get a huge income and tax incentive over PE firms. It's kind of a perfect storm that makes medical clinics such a special target vs plumbers or landscapers or whatever.

If you want clinics to stay independent and keep retiring doctors happy, we are going to have to carve out special programs or tax breaks for young doctors to buy up these businesses with debt. And keep in mind, these would be essentially subsidies for millionaires.

vault_ · 3 years ago

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

vault_ commented on Who owns private home security footage, and who can get access to it? politico.com/news/2023/03... · Posted by u/thunderbong

bcrosby95 · 3 years ago

I've long wondered why something like a general computing device maintenance service hasn't become a thing. I guess cloud storage stepped in and removed the need.

When my AC unit broke I didn't need to know the finer decisions surrounding which unit to choose.

I have weekly visits from the pool guy for a pool and gardener for the landscaping. A yearly termite check and AC/furnace maintenance. And so on.

vault_ · 3 years ago

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.