mark242

> I challenge anyone to show a meaningful improvement that derived from telemetry of this kind

Which features of our software are people using, and where do we need to concentrate the most with our limited resources and bandwidth to provide our users the best possible experience.

What are the biggest build- and run-time errors, and are they a result of the developer experience, and can we fix this through either better documentation or better error messaging.

What are the paths to successful adoption of our software, and can we nudge potential users (through documentation or developer outreach) to get on one of those paths.

We polled our users and they said that they want feature A, but our usage data shows that a vast majority of our users need feature B to be more successful faster.

Our software is used most often with other-tool-A. Can we strike up an agreement with the team that makes A, in order to give our users a better experience when integrating both tools through documentation, tighter API integrations, etc.

A fair warning-- there are precisely zero companies in the world to which the answer to all of these questions is positive. Many of the questions are contradictory when applied across the entire scale of an org and will only serve to frustrate all but the most persistent investors.

The true title for this article should be, "A Turing test to see how risk-averse you are."

Most of this article is great; the delete button is terrible.

The majority of your users are likely accessing your site on their mobile device. We crossed the 50% threshold for mobile views a long, long time ago. Desktop web browsing is -- maybe not surprisingly -- becoming a generational gap. For people who grew up entertained by their parents phones and tablets, it's rare for them to casually browse on their laptop (if they even have one).

The entire demonstration falls flat on mobile. There are no hover states on mobile. The feedback animations don't work on mobile. Holding the button down causes weird text highlighting issues. Even just the button itself is too small on a phone. It's a real demonstration of "let me just graft on the mobile layout later" after going through the desktop song and dance, which is missing a large chunk of your userbase.

The other critique I would have is around "novel" UX on web. If you're making someone learn a new way to hold down a delete button, that's a cognitive load on your user that in reality only serves to drive your users away from your product. How many of us flubbed the hold-to-delete interaction the first time, because we expected a button on a webpage to behave like a button on a webpage? I'd venture almost 100% of us. Some of us picked up on the slider that indicated that we had to keep holding it down to make the button work, but a lot of us probably didn't, and certainly a good chunk of your users will abandon their task because they can't figure out that interaction.

The author is talking about the gaming paradigm; this is where you get those random, wacky "tap twice to double jump" weird modal dialogs in games, because the complexity is so high and a user literally has to learn how to control their character. Doing this on the web is a guaranteed ticket to a high abandonment rate.

Definitely add "juice" to your pages, but don't do it at the price of _predictability_. Let your website behave like a website. Your users will thank you.

Just how out of touch is this guy? 50% inflation MoM within the next 90 days? Does he not understand the multiple system shocks that would need to take place for that to even come close to reality?

Balaji, please - get out of your bubble. Go talk to your neighbors. They're all concerned about where to go for their kids spring break, the next episode of Mandalorian, and whether or not their bracket is still in contention.

Let's game out what it would take for 50% inflation MoM -- you'd need severe supply issues up and down for every possible good, including goods created domestically. You'd need the Fed to fire up the printing presses in a way that surpasses even 2008, which, good luck on that one. You'd need interest rates to go negative. You'd need the real estate market to do a 180 from "nothing's really selling right now" to "people can't buy houses fast enough". You'd need a confluence of black swan events to happen globally in order to knock the dollar from being a reserve currency. How does that possibly happen?

Just dumb, all around.

That is just fundamentally not true.

Disneyland in particular has had a steady, growing problem over the past 15-20 years, accelerated recently with the rise of photo-sharing-sites like Instagram, where they are fighting a balance between keeping the parks accessible and affordable, while also trying to limit overall attendance.

A family who books a vacation for a couple of days at Disneyland will struggle to see and experience everything that they want, for the simple reason that there are 50,000+ people (on quiet days!) all trying to do the same things. This isn't manufactured or made up. It is a real inconvenience, and one that existed before smartphones and mass data tracking. The real solution is in eliminating the annual pass program (and raising the ire of the millions of Southern California locals who go to the park on the regular) but that's for another conversation.

"A few minutes shaved" is absolutely a tangible benefit, 100%, especially for a family who has paid thousands of dollars to travel, stay, and visit the park. "the app was a necessity, a non-negotiable" - that "non-negotiable" is because compared to the experience even four years ago, pre-app, your day does allow for more experiences, and I suspect you felt that while breezing through the Space Mountain line.

Look, I do not work for Disney. Disney does not need me to "shill" for them. But "personal data autonomy" is not enough of a real, tangible benefit to the average person, especially compared to the real conveniences of even the slightest opt-in. It does not take a massive data surveillance program to know that our family are Star Wars fans. We literally do not care if the app is more likely to recommend we go on Star Tours more often. We do care that we're able to go on Star Tours without an hourlong wait.

The comment I would have to the author is this -- it is all well and good to demonstrate how difficult it is to opt out of marketing surveillance. Great. Completely on board. The question is, how did this make your experience of the park any better? Other than personal gratification of "yay this awkward face paint is stopping cameras from recognizing me", what is it, exactly, that you got that the other 50,000+ people in the park didn't get?

Because the completely opposite argument is much more compelling to the general public. Download this app, turn on your location data, and you get notifications for a little personal guided tour. Attach your payment information and you can mobile order food for a quick pickup and save time that you can spend going on the rides. Add your party contacts and you can set up fast-passes to jump the lines for your entire party all at once, again saving you time.

If the idea of opting out (which again, great, admirable, etc) doesn't come with a clear benefit, nobody will do it, and the paper attached gets into Howard-Hughes-level of data paranoia.

> Duping though is not a practical concern. NFT contracts have stood the test of public interest and time.

A large number of contracts have had multi-million-dollar vulnerabilities. Even one vulnerability in a cross-game-item contract would affect not just the game where the item was created, but literally every single "connected" game. Those in-game-economies would all die simultaneously, and players would abandon en masse.

Bartle's point is valid; this is not something you just issue a patch for in a game. It is a fundamental catastrophic flaw with trying to transfer objects from one virtual world to another, blockchain or no.

* Whatever you already know

* And has good IDE support for opinionated formatting

* And doesn't require a ton of setup-to-build effort (ie, no debugging your build tools)

* And has a quick pipeline from local development to production

That's it. Language, database, framework, it doesn't matter as long as you meet those four criteria.

Stripe.js should include an invisible captcha by default. You effectively need to have that built into any payment form you create; someone must pass the captcha before generating a Stripe token. That's the only way to slow down a card-testing scheme.

> The ability to have your new game instantly have access to a giant catalog of compatible things is useful for game studios.

Again - you have a fundamental misunderstanding of what drives game development. It is neither useful nor desirable for a studio to immediately have to work through balance issues in a game before they have even written one line of code. Think about this for half a second. You don't get to wave your arms and just magically get a functioning, workable in-game economy. There is a huge amount of real world capital and human overhead to make sure this magical spec of yours doesn't completely wreck people's enjoyment of playing, which is, you know, the entire point of a game.

The moment that people recognize "oh, I can get a +1% health bump by going into game X and doing some mundane task, then go into game Y where a 1% health bump is the difference between winning and losing a PVP battle" guess what's going to happen over and over and over and over again. You are talking about a fractal amount of complexity for a game designer, developer, product manager, design team, the list just goes on and on. Nobody who wanted their game to be successful would ever latch onto this.

> They would need to come up with some kind of standard.

You have a fundamental misunderstanding of what motivates game studios.

I'm trying to envision the pitch to, for example, Fromsoftware, makers of Elden Ring. Ignore the cross-game component for a second because that's mind-bogglingly dumb.

"You could have artificial scarcity of Rivers of Blood*! Imagine that only 1000 people could own it, and could auction it off, and you'd make a percentage of every single transaction! You'd have a brand new monetary stream in-game!"

Alright. Now try to wrap your head around a scenario in which, for a primarily single-player game, people wouldn't completely excoriate Fromsoftware for doing that. It breaks the story. It breaks the sense of achievement in-game. It breaks even the loose sense of community that the game has. It breaks the fundamental nature of the game itself, which is "you have the freedom to build your character how you want as long as you git gud**".

I just don't see the value added at all. There's zero point to it. There used to be games that allowed you to import your characters from older games in the series, for example Ultima. That was interesting for a minute as a bit of a novelty, but that quickly died off because it turns out that people really just want to start out at zero and work their way up. The idea of paying for it is just wildly crazy.

* note to reader: massively overpowered weapon that you get later in the game which takes your character to a completely other level.

** learn the game mechanics, enemies, strengths/weaknesses of weapons, armor, etc. An artificially scarce weapon would never get used.

You look at the biggest games of the year: God of War, Elden Ring, Stray, etc. Shoehorning in NFT-style assets into these games is just a ridiculous proposal, especially ones with any kind of "marketplace" that you would have to support. All of the time and effort and maintenance and customer service, all of that would hit the bottom line of the game. The better studios -- that is, the ones who make game-of-the-year candidates -- just won't bother when they can be spending their finite development time on the game itself.

And the idea that they'd buy into a cross-game shared-asset economy is just ludicrous and is a fundamental misunderstanding of P&L at a studio level. There is absolutely zero chance of, say, EA and Activision collaborating on a spec to share assets across brands. Zero, no matter how much you could spin it to executives. "So a BF player could use COD skins?" would get you laughed out of your pitch.

> It can often do entire drives with no human input. And not just simple drives, but some pretty complex scenarios too.

This is just patently false. I have been in the beta for months, and I have yet to have "an entire drive" without having to disengage. FSD behaves like a fifteen-year-old who has just gotten their learner's permit and has zero long-term memory.

Any intersection that has a dedicated right-turn lane, when that lane comes out of a widening right lane (as most of them do), FSD will fail on, and will at the very last moment swerve to make the lane change, endangering human drivers coming up from behind, who are correctly getting into the space on the right. Every single time. I cannot count the number of times that a left turn onto a road with a slightly raised middle divider (planters, whatever) will fail. Every single time. At a four-way stop sign FSD does not know when it has the right-of-way and will always defer to every other car. This often leaves you sitting waiting for the intersection to completely clear before FSD will decide to proceed. It took me exactly 48 hours with FSD to realize that Tesla isn't close.

"Green light chime", come on.

This is already true. iPhones, and Macs for the past few years, are so integrated with iCloud that losing access to your Apple ID is going to give you a very, very bad day. Apple clearly recognizes this with their work on physically pairing devices via iCloud.

WebAuthN is, on the whole, a very good thing. Cross-browser authentication that gets lifted up to a biometric or token level will reduce the vast, vast majority of customer support and friction to creating accounts. Additionally it reduces the dependence on OAuth2, having to "register" applications and requiring customers to remember "did I use Google to sign in here? Did I use Facebook?" etc etc.

You may want to check your branding -- https://www.avo.app/

I am going to go out on a limb and guess that this is almost entirely down to your finance department attempting to understand and control the monthly cloud spend. This is obviously fine, but rather than "oh, another 2xlarge, we have to add a couple hundred bucks to our budget" the reverse should be true; you have $x to spend per month on average with a reasonable growth plan built in.

In the build and test example, the answer to "how much compute is running?" is based off developer velocity and so "it depends" is a fair answer. When nobody is shipping any builds, your cost should be $0. (I've found that this is kind of hard for enterprise-y finance departments to wrap their heads around and is why all those esoteric billing notifications AWS services even exist)

Pre-cloud services days, finance departments had a much easier time. You had racks of physical boxes that had static costs attached to them, you had a static monthly bandwidth bill that let you run at a certain speed, and you had salary costs which are also pretty static month-to-month. The idea of "scale to 0" was completely unheard of. What do you mean your QA environment doesn't cost anything on the weekends when nobody's doing anything? etc etc etc, you get my point.

Having used Puppet, the promise of Puppet was very different than the realities of Puppet and imo more accurately reflects the "different complexities" point. The point of those provision-bare-metal-on-the-fly frameworks just evaporated when, for example, you could launch a container on Fargate with, again, a single text file, or similar on Heroku.

Another quick example - serving up product image assets to customers. Let's say you want to ship 1TB of images to customers per month.

In pre-cloud times, you would spend untold piles of money spinning up racks of storage arrays, switches, firewalls, leasing out gigantic pipes for bandwidth, and again all of the requisite people in order to get that running. You'd rent space in multiple distributed global datacenters, so again you'd have an unreal amount of bash-script-file-sync services so that when someone uploads a new image it gets replicated all over the globe. Millions and millions of dollars. You'd probably have to write a custom resizing service with ImageMagick, hooked into your frontend, so that you were serving customers the correct size and not blowing through your bandwidth allocation. Just incredibly complex.

Today, you click a button in your CDN provider's console; most of that functionality from above just comes for free.

Again you have to do a little bit of munging your front-end to take into consideration the vagaries of your CDN provider, but overall it's such a huge savings of mental energy and time. Put a circa-1999 systems architect in front of the Cloudflare console from today and they wouldn't believe it was real.

They absolutely do reduce complexity! For example, think about building, testing, and deployments.

In pre-cloud Internet times, you'd have an untold number of extremely brittle bash scripts, cron jobs, rsync ssh key setup, fleets of build + test boxes to manually worry about disk space, pre-provisioned dev/QA database servers with also untold brittle sql startup/teardown scripts, and all of the requisite people whose job it was to solely maintain this infrastructure along with database tuning, build fleet monitoring, the list of menial tasks just goes on and on and on.

Today, you have a yaml file in your .github/workflows directory.

Now I agree that there are "different" requirements. Understanding the complexity of your workflows etc is no small feat-- but you're replacing such a huge amount of what used to be extremely expensive and brittle architecture with, basically, a text file or two. That's a huge cost savings.

The key to this is just searching the archives of Usenet. That will almost guarantee you the "oldest" result since you're seeing essentially 20th century social-media-message-board streams that existed long, long before the web.

This is the best comment here. The most successful children in elementary school are the ones who have gone through those social conflicts in preschool and worked things out for themselves. Sometimes that means mental conflict, sometimes that means not engaging with your peers and then having to forgive, barter, trade, etc.

Of course -- you're still writing code to delete a key in Elasticache within your lambda. You're writing yaml code for deployments. Hence the "in the future" portion of this slide.

The scale-to-X and scale-to-zero features of Lambda, along with the guaranteed interface to your lambda with predictable input and output requirements, is incredibly empowering for an engineering team. I can absolutely guarantee that we have spent far, far, far less time maintaining our infrastructure than what we would need to be doing if we had a big-buncha-EC2 setup.

Imagine that the environment issues get taken care of, because Amazon has teams and teams and teams of engineers who are working on just that. Cloudflare has the zero-cold-start isolates. All these platforms are heavily invested in making your development and deployment experience as easy as it can be. Concentrate on writing your code, and you'll reap the benefits.

> If I was ever at a high level in a company I'd never go farther than some AWS load balancing or whatever on cloud instances we still have root on.

Your competitors would salivate at this statement, fyi. Speed is a competitive advantage. AWS is not "let's rent a big ball of EC2 servers and call it a day", and anyone who treats it like that is going to get eaten alive. If you have not looked at -- for example -- Dynamo, you should. If you have not looked at SQS, you should. The ability to have predictable, scalable services for your engineers to use and deploy against is like dumping kerosene onto a fire, it unlocks abilities and velocity that more traditional software dev shops just can't compete against.

> Is cloud administration less time consuming than system administration?

Infinitely, and if you look at it from a startup lens it only makes sense. One needs to point only at the recent log4j incident. This is obviously a gigantic black swan event, but even just ongoing security patching at the OS level can be a full-time gig. There is absolutely no substitution for being able to ship code to a platform that just runs it and scales it for you.

Andy Jassey had a great slide a few years back at Reinvent, when talking about Lambda -- "in the future, 100% of the code that you write will be business logic". If you really think about that: how many times have you had to write some kind of database sharding logic, or cache invalidation, or maintaining encrypted environment variables, whatever. That idea that you can toss that -- and what that gives to teams, not having to spend massive timesinks and budgets and hiring and all of that on -- effectively -- solved problems, you really start to understand how you can move faster.

The image amplifies what we already know is a fundamental problem with OAuth; people, instead of forgetting their username/password combo, now are forgetting which provider they use to sign into a service.

That "Web 3.0 login" portion of the slide only makes that problem worse. Decentralization and a variety of choices absolutely fall apart when they meet non-tech users who have no idea what icon means what.

"Permissionless data" is actively harmful to people who do not want their data put into an immutable datastore. It smacks of "moderation-free content" which is simply a nonstarter.

If web3 is truly about privacy and data portability, then 90% of the people working on DeFi should shift their efforts to making a better browser, possibly one that incorporates IPFS natively and quickly.

The encampment underneath the 101 on Gower is extremely dangerous. There is a stop sign at the end of the exit from the highway, and cross-traffic does not stop. When you want to go south on Gower and there is any amount of traffic, you need to hustle to make the left.

The encampment has taken over one of the lanes of southbound traffic, and when you hustle to make that left, unless you overcorrect on the turn and slow down, you are going to run into the encampment. It was a very difficult turn to make pre-pandemic when there was maybe 1 or 2 tents on the sidewalk underneath the highway; now that it's the sidewalk plus a lane of traffic, it is only a matter of time before someone gets run over.

As a very-short-term fix, the city needs to move some of those people to the encampment on El Centro, a couple of blocks away.

On edit: Google streetview from February, you can almost see how the encampment takes over a lane of traffic -- https://goo.gl/maps/dySMxTxFmgx43uNj7

Fender Digital | Multiple Roles | Full-Time | Remote (US)

We are spinning up an entire Commerce Cloud team and need an engineering manager who can help grow the team and own the engineering side of Commerce Cloud. You don't need to know the internals of SFCC as long as you have ecommerce and Javascript knowledge.

https://boards.greenhouse.io/fender/jobs/3262844?gh_jid=3262...

We also have openings for Android engineers for our digital learning platform, where you'll work alongside React, React Native, iOS, and other Android engineers to help grow our platform.

https://boards.greenhouse.io/fender/jobs/3004857?gh_jid=3004...

The only outstanding FDA approval is around the length of protection. The CDC has said that the covid vaccines are safe and effective. Worldwide, there are 900 million datapoints that say that the vaccines are safe. It will be safe for you and your family.

https://www.cdc.gov/coronavirus/2019-ncov/vaccines/safety/sa...