gracenotes

I think we both agree that cars have some significant utility to them, although having utility doesn't mean that any amount of cost is acceptable. This is my problem with "cars pay for themselves, therefore other forms of transit should pay for themselves", which I have seen evidence against (see linked pdf) and nothing conclusively for. The meaningful discussion to have is what we want to support as a society, like your argument.

Trucks on last mile delivery are invaluable for some deliveries, as you mention, but then... why else does any other vehicle need to use most streets? Is it reasonable for someone who orders a truck to pay 33% of the cost of that truck on the road? What about 0%, or 100%? Which is best?

In cases where alternatives to trucks or cars are less costly overall in some situation, or additional efficiency can be achieved with batching, how much of that is ignored because of these accidentally created incentives? Not even mentioning the indirect cost to communities (walkability, clean air, autonomy of disabled people).

I don't have the answers, but I think these are good questions to be asking. For the specifics of policies, we need to base that on data ofc.

I think you're seeing the influence of math on programming conventions. If I think of something like (!a && !b), I can immediately start doing boolean algebra in my head. I can manipulate it like an algebraic expression and get the job done 10x faster than if I had to work through the "real" meaning.

Anyone's productivity in programming can be enhanced by taking a mathematical outlook, although I suppose the beauty of programming is that you don't have to.

To throw in a Dijkstra, "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." What do you do when certain semantic levels require some mathematical background - do you choose a less precise abstraction or do you just require that background? I'm not sure what the answer should be for this kind of blog post, but at least intro-to-programming materials should be as accessible as possible.

Oddly enough I've been getting into UE4 and things would be so much easier for me if the core classes were better decoupled.

For instance, I'd like to have a quadraped skeleton with the ability to apply a movement vector. Unfortunately, in the Actor->Pawn->Character hierarchy, you cannot have movement (applying vectors, walk/jump/fall state) without a capsule root component - which is the only one respected for collision - so either I have to rewrite all of the movement code or somehow make the capsule vestigial and carefully maintain its state.

In short, in some cases it's useful to say that a Pawn is an Actor with a set of extra features, or that a Character is a Pawn with a set of extra features, but even there, the way inheritance forces you to adapt an exact set of extra features and no others and also those features are not piecewise reusable elsewhere is a pretty big structural problem.

I've already done enough arguing about OOP for one career in programming, I think, but the more I see what's out there, the more that I think the real enemy is any use of class inheritance - even the TAPL formalization of OOP uses interfaces only.

It's worth looking at "for no reason" in greater detail for cars, which is different from those other medical cases in significant ways. We collectively as a society decided that motorization of roads was worth pursuing at the expense of human health and safety, if you look at rhetoric at the time of cars' introduction, in no small part due to input from car manufacturers. This wasn't about driving skills; it was about restructuring all of society to make cars close to the bottom rung, not infrequently at the expense of minority groups. More recently, car-related deaths occur from bad design and usually refusal to fix it until sufficiently many lives have been taken. Any kind of "Vision Zero" which is focused on enforcement rather than infrastructure fixes is bound to fail.

So if "bad things happen to good people for no reason" is unpalatable and it's the narrative for mass transit, and "bad things happen to drivers for reasons in their control" is the easy narrative for cars, I'd say "bad things happen to good people for reasons that are in our control but we still do nothing" is closer to the true narrative for cars, but it is also unpalatable. There is an element of this in many risk-related scenarios, but it is especially clear here.

Yes. It is a slow, slow decline into the kind of behavior described in the article that could have been stopped or mitigated at any point along the way but wasn't. Not necessarily in terms of how someone is deep down, but in terms of their understanding of how they can/should interact with people around them.

Rather than refuse to understand how someone could have gotten there, let's try to understand the assumptions they made along the way. Then rather than pretending we're unaffected by the culture around us, let's see if we share some of those assumptions. If we want to fix things rather than be blindsided by them, these are at least the first steps.

It's better to try to understand what's happening than handwave and say "it's all bunk". That is way more political of an action than trying to determine causality through data. The social sciences are valuable in that they're trying to figure things out about the world which are critical to making good policy, rather than winging it and accidentally or intentionally screwing over people who are different than you.

> Some of these articles are implying a size of an effect that is completely ridiculous, there is just no way that diversity "could increase revenue by 41%" - we'd see way more diversity in work places if this was true.

This seems to be rejecting data and substituting and a handwave. From the original study, 41% is the actual coefficient, controlling for a ton of things. Likely there are latent factors that make workplaces both gender-diverse and performant, so just swapping out half of a workplace would not hit all of these, which the paper acknowledges. We are seeing more diversity thanks to studies like these and explicit diversity initiatives, but given all of the biases that can exist in hiring pipelines, I can't think of any reason why it would happen naturally.

The paper you link is trying to measure firm productivity (could not 100% figure out what this means) based on data from Denmark, mainly non-white-collar jobs. It notes that demographic diversity promotes "better problem-solving abilities and more creativity and knowledge spillover" and can be a "substantial competitive advantage", limited by people not trusting/communicating with each other (i.e. integrating effectively).

I do occasionally ask newer employees who are not experienced with code reviews to split up a review into multiple smaller reviews. Actually there is a natural equilibrium that happens here. There is an exponential relationship between complexity and size of a single change and review latency, just because that's most efficient for reviewers (assuming some hard limit on acceptable latency as well). Most changes take on a uniform medium size as a result of this. The sheer number of changes isn't as big a factor here because most reviewers look at reviews in batch anyway.

Separately, minimizing diffs with the codebase is not just easier for the reviewer, it also makes 'blame' and resolving problems with existing code easier. You shouldn't break your back to minimize diffs, but as a form of hygiene it is not without merit.

Your definition of continuous integration is interesting in that I haven't seen it used in that way, or rather with that emphasis. Smaller syncs-to-master than "this is the entire feature" are great, but their effectiveness depends on automated testing, building, and deploying. When code under review is a coherent, high-quality, and tested thing, this can be a boon for CI because you get a small chunk with clear before and after states, which you might not get from just winging it. You can also work on code while other code is under review, especially with a Scrum/Kanban-type task system.

As several other commenters have pointed out, code reviews are not a silver bullet. It is widely known that there is no silver bullet.

That said, if your goal is to make a quality product, you shouldn't have to choose between code reviews and continuous integration. You shouldn't have to choose between code reviews and code coverage, or manual QA processes. These are all widely regarded as best practices and if implemented "correctly" and appropriately to the team their combination forms a virtuous cycle for code health and team culture.