429 karma · joined February 24, 2013
And even if the benefits are entirely "inflated away" in aggregate (which is extremely dubious given that UBI produces real economic value in terms of stability), that's just the aggregate effect. To take an extreme example, if the Fed prints 1,000,000 exadollars and distributes them equally, then yeah it's pure inflation, but it also massively redistributes wealth to the point where everyone is practically identical. Hopefully that example demonstrates that the effect isn't zero even if it's just "inflating itself away."
Finally, I object to treating this question in pure economic terms. We shouldn't be overly concerned with optimizing aggregate economic outcomes for society. Those at the top end can more than afford to give up some wealth, and those at the bottom are struggling to a heartbreaking degree. The utility function of holding wealth is not linear and if you're interested in increasing everyone's well-being then that's a fact you have to address.
On a more meta note, this is an incredibly common and obvious answer to your question, and I wonder if it's even asked in good faith. If you've "yet to hear an UBI proponent explain" this to you then you really don't understand it at all.
Your hustle-culture narrative is appallingly toxic and your entire argument amounts to learning to love being treated like garbage so that you don't feel bad when you do it to others once you're the one on top.
* Why did the web disrupt desktop?
It's not even really worth addressing these, because they're all so weak. None of the actual reasons that web was successful are here. And the ones that are there are nonsense. For example, to suggest that security in the browser was a significant factor in the success of the web on the desktop is utterly detached from reality. Even if average people cared (which they didn't) then they'd be better off trusting software bought at the store than going into the wild west of the internet with the shambles that we called browser security back then.
* Why didn’t the web disrupt mobile?
- the web’s network advantage had evaporated
If anything this argues against the thesis that "make anaerobes do photosynthesis" is insufficient. How would apps become successful by merely matching the existing networked nature of the web? At best this item is filler that adds nothing.
- The iPhone was a completely new thing
Yes, this is actually a good point. New paradigms and new APIs for a new type of device. Makes sense.
- The basis of performance shifted from small binaries to smooth interaction
What? No. This is silly. There's no way that the web prioritizing download size had a significant impact here. And "smooth interaction" has absolutely nothing to do with binary size, so I have no idea why the author is associating them.
- Navigation shifted from keyboard to springboard
Kind of a repeat of the smartphone being a new device, but okay, good additional flavor.
- Log-in disappeared completely
I mean I guess. But if there's any difference, it's more a matter of shared devices not being so much of a thing with phones. Web is perfectly capable of "one-and-done" logins, and many sites do that. And you could easily have a longer session cookie on your mobile site based on the single-user-per-device assumption.
- Discovery shifted from search to app store
Decent point, but only by accident. "Lowering the friction of software install" is nothing, since web has zero friction in that regard. I don't think that typing-free discovery was really that huge of a deal either. But having a large ecosystem of app developers, with ratings and featured content, was enormously influential. This might have been possible with web technologies but obviously nobody did it well enough to gain critical mass.
- Engagement shifted from links to icons
You could have single-page applications on web, with shortcuts on your home screen, send notifications through the browser, etc. You can use icons instead of links on web. Behind the pile of buzzwords, this item is nothing. "Deep, branded experiences" really?
- Business models expanded to IAP, subscriptions, and app purchase.
Yeah I think this is a good point. Having a single payment processor in the play store / app store that knows your payment details did reduce friction.
- Security shifted from sandbox to app review
No, no, no. Not this again. People don't really care about security, and anyway again, app security was still dogshit by the time it had won on mobile, just like browser security was by the time it had won on the desktop. Apps requesting tons of permissions to spy on users were rampant for years and years, even with apps being reviewed by apple/google. And how does this item even constitute a competitive advantage? You can have a browser remember permission to access your location or camera or whatever. There's nothing here.
I feel like this article really dazzled with its introduction tying in business and evolution and setting up the framework for the problem, but then fell to absolute pieces when it came time for the author to actually know anything about technology. Even if there are some good points here, the missteps really undermine their credibility. The analysis of the success of web on desktop is especially lacking, but I don't feel like it's a great analysis on the web vs app section either...
It's basically engineering with the goal of creating a perception of privacy rather than actual privacy. I don't really care that much about Apple policing what you upload to iCloud, but this disingenuous architecture does annoy me a bit, and there's also the added insult of having a device in your pocket that by design works against its owner (reminiscent of "treacherous computing"). These problems would go away if they just did the check on the server side.
This spoken-word work from 1970 conveys the sentiment well: https://www.youtube.com/watch?v=goh2x_G0ct4
"Public bad private good" isn't a coherent strategy. If NASA isn't good enough then the preference should be to improve NASA rather than to insert an unnecessary layer of profit-taking for SpaceX or Boeing to do the same thing anyway.
This whole subject is really interesting and you should at least check out some Wikipedia articles:
https://en.wikipedia.org/wiki/NMDA_receptor_antagonist
Those unwritten rules that govern social behavior can induce real internal change too. People's attitudes and beliefs are shaped by what they perceive to be customary and deviant in their culture.
And I seriously doubt that anyone will claim that a knife sharpened by a robot arm reproducing the exact movements of a human will produce an inferior product. The problem is that most automated sharpeners are some variant of a rotary grinding wheel run linearly along the blade and, unless you're sharpening a machete, there are all sorts of aspects of the blade geometry that are ignored by this process but can be accounted for by a skilled worker at a whetstone.
I'm pretty sure this is the opposite of the actual situation. Cities attract both tourists and high-income residents, and the latter combined with high population density drive the development of much more diverse eating options within a reasonable range than a person in a more rural area has available to them.
Anecdotally, the organic grocery stores and vegan eateries I see in SF just don't exist where my parents live.
And if I'm sick, and there are clinical details that are important to my treatment, then I'm absolutely not going to be satisfied with a low-accuracy simplification.
> Throughput is the amount of work that comes out of your project by unit of time. It’s up to you to decide what units make sense for your context. Days, weeks, sprints, stories, bugs, epics – anything goes as long as you’re consistent.
Using days/weeks/sprints as your unit of work for determining throughput seems circular. If you want to know how many weeks of work your team can produce per week then you don't need a monte carlo simulation to tell you that.
Using stories/bugs/epics is flawed too, I think. You can have a fantastic model for your team's throughput in stories per week, but that doesn't tell you anything about when the project is going to be done unless you know how many stories there will be. There are two variables here (throughput and quantity) and you can't get useful information out of the product of them for free.
To see why, imagine that you take only the minimum amount of effort to very roughly divide the project into sensible-seeming chunks. In that case, your throughput in chunks per week will be meaningless (i.e. your model will have a confidence window which is uselessly wide) because the chunk division will have barely any relationship at all to the amount of actual work in each chunk. Now imagine that you're a bit more diligent in your project planning and look in a bit more detail at the work that will be involved. You've done some work to clarify what code will need to be written, and your confidence window will narrow accordingly. Now imagine that you're even more diligent. And so on, and so on. You eventually end up with zero error in your model, but in the process you've completely determined what code will need to be written, and the project is finished! Congratulations, you've invented waterfall. There's no free lunch here as the intro paragraphs of the blog post promise.
I assume that in practice you're stopping at some point in the middle of the extremes of doing nothing and planning out every line of code, and then applying your statistical model at that point, but I think you'll still be thwarted by the (at that point) partial disconnect between the chunk divisions and the actual amount of work in each chunk. We've all experienced innocent-seeming tasks that end up consuming vast amounts of time unexpectedly, and various degrees of this phenomenon is what fundamentally ties the amount of error in any pure "stories per week" model to the amount of effort you spend planning and estimating the stories. No free lunch.