The linked paper is a very nice overview. Of course there problems are known and there are people trying to fix all of the issues (mostly in the relative obscurity of non-overhyped corners of academia), but the concise example-guided description of these problems is great.
Somehow I think the most fundamentally damning critique, and causality shares this problem, is also the most vague. That applied scientists/experimentalists look at the "automation" that these approaches are supposed to enable and say "that's either doing the trivial part of the job or giving you BS answers".
I've always felt bayesian statistics got more attention from researchers than was warranted (including today despite deterministic methods taking over the world) because it has a nice principled "theory of everything" starting point. But then of course you have to approximate the heck out of it to be able to solve it. Often far more than with other methods.
You have to approximate the heck out of the Schrödinger equation as well, otherwise we would be stuck describing the Hydrogen and maybe the Helium atoms and nothing more.
Yes, however as I said in the subsequent sentence, the approximation is "often far more than other methods". For the most obvious example, a point estimate like MAP doesn't need to compute the denominator in Bayes law. That's two (generally easier) terms to approximate rather than three. Those using Bayesian methods point out the value in providing a full distribution, but the necessary additional approximations to get it means the location of its maximum can now actually be less accurate than a simple MAP estimate. But what always bugged me is multivariate problems where the Bayesian paper presumes everything is independent and Gaussian. Great after getting all psyched by that intro talk about the value of getting a distribution, we get the simplest imaginable one, just a mean and variance for each variable.
> Your problem is you can't define meritocratic in a way that everyone will agree with
Of course you can't. One man's merit is another man's vice. The very notion of a meritocracy is literally a sarcastic joke [1].
But the problem is even worse than that. EVEN IF if you could define a universally agreeable "meritocratic" system, you would still have the problem that people with power would abuse the system to lock out others.
Suppose 100% "meritocratic" people were selected at random. They then immediately change the rules. Now 99.99% of people disagree with the legal definition of "meritocratic". But tough shit, cause this ain't a democracy, and the other 00.01% of people have all the power.
It's not a joke, but it is relative (like most conceptual words). A vote decides on the definition of merit in the least relative way possible: by letting everyone contribute to the definition. A definition of merit decided by the heads of a bureaucracy is extremely relative - to whatever those few people think they want.
What is considered “merit-worthy” is defined by the society implementing it. There is no such thing as objective universal merit across time and culture.
I don’t see why this is controversial. It’s no different than “fair” or “justified” or innumerable other values that a society has to work out a definition for.
> What is considered “merit-worthy” is defined by the society implementing it. There is no such thing as objective universal merit across time and culture.
I think the point of the comment you're responding to is that it's not defined by the society implementing it, but by those in power. So whether the idea of 'merit' changes across time and culture might be true, but is beside the point.
I think maybe the difference here is the fact that SpaceX probably treats software as a first class citizen; just like Tesla does, and is likely to have a modern view on how to build and evolve software. Additionally, software is a key component for them that is very much determining the abilities of the hardware. Tesla even ships pure software features that they charge money for. That's unheard off in the car market. And I would expect, Elon Musk to drive a similar strategy in SpaceX.
I suspect Boeing maybe treats software the same way as they've always done, just one of many boxes that need to be ticked in a long waterfall like process. They just throw more people at it hoping it gets done on whatever time line they imagine it needs to be done. They are likely to be very conservative with respect to tools, technologies, and practices (i.e. not much has changed there in decades).
The fact that SpaceX is able to come up with a new design for Starship and can then get it and the software working for several successful hovers & hops in around 9 months, tells me they are able to iterate quickly and adapt to quite major design changes. They launch a lot of rockets and they seem to be learning a lot every time they do this. I don't see how they'd be able to do this without very solid software development practices. I'd expect lots of CI & test harnasses, probably lots of emulators and other tools, and I have a hunch they probably use a lot of static code analysis etc. to prevent preventable bugs from happening.
Any engineer or tech at SpaceX is likely worth their weight in gold at any other company due to the company's perceived high bar. Additionally, I don't hear complaints about their pay either, which is likely extremely good.
No one is locking them into cages and telling them they can't leave. I would bet most everyone who is there strongly believes in the mission.
EDIT: Eh. They aren't paid fantastically but not slave wages either. Additionally this is spread out over three very different cities.
> No one is locking them into cages and telling them they can't leave. I would bet most everyone who is there strongly believes in the mission.
That's true for a lot of other companies where people here have advocated the employees would benefit from unionization.
For the record, I am conflicted on engineer unionization, and my original statement was intended to be neutral.
As to this specific example, on one hand I understand the drive that comes from having a real mission (as opposed to an MBA-concocted "mission") and how a team who share that drive can execute with amazing speed; conversely, I have seen how poorly teams of clock-punchers putting in the bare minimum can perform.
On the other hand, I have also seen "the mission" used as a means to guilt trip people into overwork or accepting substandard compensation.
Of the two, I lean towards the SpaceX approach being the better one. In the absolute I don't particularly like either of them.
> EDIT: Eh. They aren't paid fantastically but not slave wages either. Additionally this is spread out over three very different cities.
Those salaries look to be in line with what equivalent engineers at Raytheon, Lockheed, and Boeing are making in those same locations, maybe a bit higher. Thus, if the WLB reports from SpaceX are to be believed, their per-hour pay is much lower. It's hard to tell, though, without a proper breakdown by years of experience. Also, there are certainly teams within those companies where the engineers put in just as much time and effort as SpaceX engineers. Boeing is the only one I am aware of that has unionized engineers, though.
Eh, I wouldn't say that there's a perceived high bar at SpaceX or Tesla. At this point they're mostly known (within my corner of the aerospace world anyway) for working their employees to the bone. Very few people I know who have worked for SpaceX have lasted more than a year or two there.
Logic says that would negatively impact the quality of the software. If you are working 50+ hours a week in software development, a lot of what you do will be done when you are too tired to properly reason about what you are doing.
Not that it's impossible, but you'll need tooling that prevents you from making the mistakes you'll unavoidably make when tired.
Sorry but anyone who has worked in a professional high-tech environment should be aware of that an 8 hour days is not productive. You NEED to spend you entire day on this, you mind always needs to be on it to work on that level.
Einstein would certainly not have solved relativity by saying "Uh I guess from 9 to 5 I will work on this with a one hour break in between and then I am heading off to the fun stuff called leisure time".
No... Only if you think about these problems day in and day out you can work at in the top percentiles and this is the kind of people that get hired there.
This is getting cause and effect totally screwed up.
People want to work on cool stuff (in the sense of rockets or in the sense of making the world better, or both). They will accept lower pay (per hour) to do that. Therefore, working on cool stuff demands longer hours and lower pay compared to less glamorous things. It's not an inherent requirement of the field; it's a side effect of human preferences.
Engineering companies have capital expenses that eclipse what a software shop has to deal with. The rock stars can't demand such a large chunk of revenue.
The author of this piece is a computer scientist (as opposed to a humanities professor), and in that domain their advice is quite reasonably universal.
It's almost unimaginable to write a (PhD) thesis in computer science without an extremely detailed outline. The thesis is not some thing you come up with whole-cloth, and it is certainly not a substantial dump of novel work.
The CS PhD thesis is typically a function of between three and 10+ previously published & peer reviewed papers. The exact function used to combine these previous publications into a thesis can range from `concat` (the "big stapler" thesis) to a substantial rewriting.
The level of rewriting depends on many factors, e.g., the advisor's style, the norms in the department/country, the quality of previous published papers, and of course pedestrian things such as the student's promised start date for their first post-graduation position and/or the amount remaining grant money.
But in any case, there's going to be a rather small design space in terms of the overall high level outline. The choice of chapters -- and even the internal organization of those chapters -- will mostly match previously published work.
In some sense, CS theses are closer to an anthology than a book. There's a bit of design work you can do around the edges to make things into a coherent whole, but you're not going to be making substantial modifications to the meat of the thing.
> I can totally imagine that for a beginner developer it can make the difference... I believe in writing every character of my code and testing it thoroughly, I wrote many bug free codebases with it, that's my experience.
I'm entirely split between vigorous agreement and shaking my head.
At some point I just lost interest in committing various interfaces to working memory. The more trivial the more virulent my disinterest. Web stuff, especially front end? Unless it's crucial UX for something Very Important, it's just not worth the effort. Bring on the program synthesizers, even if they're limited to tab completing. I would literally rather memorize gibberish. If I wanted to memorize things I don't actually need to, I would've gone to med school.
At the same time, for code that actually matters and requires deep thought, I type every character and think about each one a lot.
Hopefully at some point program synthesis will be good enough that we don't have to make this choice. In the meantime, pretty much everyone doing something other than code-for-the-sake-of-code is writing some software where understanding every character really matters and some software that just needs to do the dumb thing right more than half the time to be worth it.
> It automatically formats your code, so the codebase doesn't resemble the one in your head anymore.
Same thing. One the one hand, your coworkers are not your psychologists. On the other hand, who is going to explain the code if you can't? And again, the resolution is: does this code being correct really matter?
I had the same reaction as you, for the same reasons. That said, I'm a bit more skeptical about the proliferation of automated code formatters run e.g. as pre-commit hooks. A project-wide consistent formatting style is the right thing to have in 90% of the cases, but neither the style guides nor the tools enforcing them are perfect. There are situations where a particular piece of code will suffer a readability penalty if formatted in a standard way. For those situations, the formatter must have a way to locally disable it.
Requirements to become a professor of Mathematics at Cedarville University include:
• Commitment to biblical integration of faith and science in and out of the classroom
• Qualified applicant must be a born-again Christian
• Qualified applicant must agree with and be willing to abide by Cedarville University's Doctrinal Statement, Community Covenant, and General Work Place Standards.
You are, doesn't mean it's correct. Look at it this way. It's been happening for a while, on multiple platforms, where other software isn't exhibiting the problem, applying Occam's razor suggests the issue lies with the software.
I accept your point of view, but the GP was suggesting this is another in a long list of bugs introduced into Catalina. Since, anecdotally, I have first hand experience of this affecting me on other platforms as well as previous macOS versions, logic and reason suggest that the problem was not in fact introduced in Catalina, but lies squarely at the foot of Mozilla. Not everything is fair and balanced. I believe, in this case, that Mozilla are solely at fault, not any of the OS vendors/distributors.
Apologies if this comes across as tetchy; I've been dealing with pettiness and unreasonableness all day. My intention was not to defend Apple (or anyone else) or to besmirch Mozilla. I was merely trying to be helpful by pointing out that this problem affects the same software in the same way on different platform.
The alternative interpretation is that Firefox is a particularly effective toolkit for finding OS bugs.
No OS should ever fall over because of a misbehaving application. That's one of their fundamental jobs, and failing at it is a defect. The fact that all the major OSes do doesn't vindicate them; nor is it particularly surprising that Catalina doesn't pull away from the pack. It is, however, disappointing.
> The alternative interpretation is that Firefox is a particularly effective toolkit for finding OS bugs.
That is one way of looking at it. I'd argue that it's not a particularly usefully of looking at it. Ideologies aside, your last sentence says a lot. The fact remains that buggy software from a cross platform vendor is causing this issue across the platforms they provide the software for. Be under no illusion, the issue is Mozilla's a no-one else.
They define a discrete list of "outdoor activities" that are relevant to their members -- mostly equipment provides for niche sports/activities with expensive equipment needs (climbing, skiing, cycling, camping/backpacking, fishing, hunting, scuba diving, etc.).
In particular, someone who walks in their local park every day or plays pickup soccer/basketball at the local outdoor sports field would answer that they didn't participate in any of the listed activities.
Ah, that explains it. They're using an exceptionally narrow definition. Although that I'd argue that camping/backpacking doesn't require expensive equipment unless you're seeking to maximize your physical comfort.
That headline is wrong. Nearly half of Americans didn't participate in a list of 42 outdoor recreation activities that this particular trade group profits from, which is quite different from "didn't go outside for recreation".
That's a pretty decent list, but it excludes what are probably by far the two most common forms of recreation that occur outdoors: walking in local parks and playing team sports outside (organized or pickup). But for some reason does include _indoor_ climbing!? Probably because this is a trade group comprised of companies that make an enormous amount of money from gym climbing but make exactly $0.00 when kids spend all summer playing in the community park ;-)
What a weird list. I haven't done a single item of that list in years, but I would say I go outside for recreation about 100-200 times per year. Walking around the neighborhood? Kicking a soccer ball around in the backyard? Shooting hoops with a hoop attachment to a garage? None of that counts? What a ridiculous headline!
Pew did a comprehensive study of urban, suburban, and rural communities (link below). Their empirically-backed findings are pretty divergent from these common stereotypes.
There's even an entire portion of the report that basically boils down to "everyone thinks others do not understand their community's problems but is pretty confident they understand other community's problems".
Interesting, I wonder if this has been changing due to the arrival of the telephone, internet, etc. Like maybe other factors contribute to local vs global thinking more than geography.
I'm honestly at kind of a loss as to why politics is so polarized right now. I've tried just about everything I can think of, but can't create a self-consistent system of logic that explains the reasoning behind why people vote the opposite way that I do. It must be something subjective like religion or some context that I'm not privvy to.
I'm kind of joking and kind of not when I say that I wish we had an AI trained to be either liberal or conservative so that we could study it and see where it diverged. It's like we're way out on separate branches of a large search tree, so lack the context to understand where the other side is coming from. It really messes with me, because I should be able to understand a system of logic even if I don't agree with it. But I can't even get that far. What gives?!
Somehow I think the most fundamentally damning critique, and causality shares this problem, is also the most vague. That applied scientists/experimentalists look at the "automation" that these approaches are supposed to enable and say "that's either doing the trivial part of the job or giving you BS answers".