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 can't find that info about funding sources in the urban.org article, or what "sales tax" is generated from specifically. The article does say that HTF is not fully self-funded. If something comes from general revenues/tax, that means that all taxpayers are paying for it, whether or not they use a car.
If this is in fact the case, I don't think it's a bad thing. The problem in that case comes from double standards, where the ground-level understanding of how society operates includes costs incurred by individuals/businesses which effectively disappear into a vacuum rather than being directly paid/passed onto customers, yet is used as evidence of the completely natural and inherent utility of cars over alternatives.
For a different doc more directly about who pays for roads, I've found this one useful. Made by a so-so thinktank, but seems well-sourced and rigorous.
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.
Reification doesn't just impose a substantial complexity cost on dynamic languages in the CLR, either. See this F# feature request from 2011 that is effectively unimplementable:
As GP mentions, Haskell is a great example of achieving both superb type safety and superb type expression with type erasure. That said, sometimes you don't want superb type safety - things like dependency injection and mocks are examples of frameworks you can use in languages with some amount of type reification without restructuring your entire codebase. Java/JVM achieve a decent balance here imo.
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.
I recommend reading the entire post - it's not too long, and links to other great materials - but this is a good relevant quote:
> The point of rigour is not to destroy all intuition; instead, it should be used to destroy bad intuition while clarifying and elevating good intuition.
I was going to link this one if someone did not already. It is a natural followup from this article and must-read for getting intuition on DFT and its limitations, many of which are just limitations of sampling.
As far as progressing even further into DSP, especially for audio processing, I've found https://www.dsprelated.com/freebooks/filters/ to be a good map of the territory. But as someone with a CS degree rather than an engineering or math degree, it's all pretty overwhelming.
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.
I am not sure what molly-coddling means in this context, but as a single data point you can look at the platform page of a minority advocacy group: [0]. The actual low-level details of many of the policies (if not the headlines) share a lot in common with Sanders' platform, for instance.
I'd like to think that, for the most part, trying to address a societal problem like [1] is better than denying that any action is needed, even if the increased visibility causes strife—[2] is of interest here—or we don't get it right the first time. It's hard to discuss because many Americans begin on vastly different pages with vastly different experiences.
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).
Maybe? The type of diversity that companies care about (to contrast with the many strawmen out there) happens to be good for the bottom line. That is, a team with 5 men and 5 women is likelier to perform better than one with 10 men [1]. Some explanations I have heard are that diversity brings perspective that wouldn't be present in a monoculture, and that it improves psychological safety which is a huge determiner of team performance [2]. There are models out there made by actual social scientists of why diversity helps. See [3] for instance, has both elements.
It does seem like age-based discrimination would have a negative effect on psychological safety, as with any discrimination due to conscious or unconscious biases. Regarding perspective, an experienced individual could either bring in valuable insight from their experience or constantly veer towards the status quo, partly depending on how you want to look at it.
I think the answer is: it is complicated. You now have my ideas on why diversity is valuable. Does age fit that model? (Even if not, of course, age-based discrimination is not good.)
I am not sure I agree with this focus. As someone who does not exactly do single-question technical interviews but more like two- or three-question ones, my goal is somewhere in the vicinity of measuring the software engineering version of IQ. Granted, free form technical interviews are well known to be bad at this, but all the other ways seem worse.
Bloom's taxonomy[1] is useful here I think. Assessment ideally shouldn't stall at 'understand' or 'remember'. I do agree it is important to know about a large variety of things. The more specialized the job is, the more important it is for a candidate to do a decent subset of it on day 1. But sometimes you can explore a candidate's knowledge through 'apply' (use X to do Y) or 'analyze' and 'evaluate' (do Y), such as in a system design question, to see the structure of their thought process rather than something more scattershot.
Finally, regarding skipping a question, sometimes you can sense that a candidate's knowledge is limited in some area, which is a good time to just move on and try to go deep on something else. Not everyone has been afforded the same opportunities and has the same amount of experience. Software is a job where the potential to grow can do you better than a fixed skill set, especially if you see hiring as similar to making an investment.
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.
One of the most important things in "professional" writing, which includes technical writing, is clarity. Sticking to a style in that context is important because you shouldn't draw attention away from what you're saying to how you're saying it. The same thing is true of code style, where I think style guides really do improve productivity in codebases touched by multiple people.
As you mention, you could also see specific usage patterns as shows of "professionalism" (again in quotes... it's a word that I think should be used carefully re systemic biases). But it's perhaps a little reductionist to view informal contexts as not-caring-about-correctness at one end and professional contexts as caring, because there are many aspects of communication in both that are "incorrect" for different reasons. Usage patterns in work environments are not strictly more correct, then.
As the article proposes, being bothered by ungrammatical language is more often just an issue of sensitivity to stimuli. At least in conversations, those of us with the good sense to be descriptivists can hopefully tell when additional clarity would be helpful and when it's just putting other people down to try to look smart.
I have been a little mad at Safari while building a website recently (https://windmill.thefifthmatt.com), and the issues I ran into seemed like Safari's "fault"—it does not implement several web features such as requestPointerLock which Chrome and Firefox implement, so I had to jerry-rig worse experiences for Safari users. I had to neuter a Content-Security-Policy header because Safari refused to render a font no matter what font-src was... still have not figured that one out. Mobile browsers are similar here, although I have not tried out Safari remote debugging (only Chrome remote debugging).
Obviously both browsers are developed by highly talented software engineers (disclaimer: biased Google employee here, not in Chrome, speaking for self). But I think type of website and upfront ecosystem investment have some effect on where the most development pain comes from. My naive guess is that rich content consumption sites are easier to do in Safari, more app-like long-tail-of-features stuff easier in Chrome. If this is true, why? My guess is that Apple has its own idea of which general-purpose platform it'd prefer to most invest in.
> Treat nonlogged in users as second class citizens. By always giving logged out always cached content Akamai bears the brunt for reddit’s traffic. Huge performance improvement.
I have ended up using this philosophy in a website I've been working on lately, where people can post puzzles from The Witness. This includes simplifying decisions such as not tracking solved puzzles unless you have a user id, and not allowing navigating to a random puzzle either, as this routine depends on stored solves and upvotes. Supporting not-logged-in users just means extra code for me.
In general, I don't think this is a bad attitude for a website to have.
It is perhaps different in the case of GitHub, a highly depended-on and well established website which is actually removing functionality here. I would still assume good faith about the reason. And mobile login rates are a problem for everyone, I'm pretty sure, not just GitHub.
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.