nkohari
Joined 19 years ago
Joined 19 years ago
Basically, Theseus reads your pull request and your codebase, categorizes the kinds of edits that were made, and writes human-readable documentation that describes what changed. Then, it shows the explanation side-by-side with the code, but presented in a way where you can decide what you want to skim and what you want to deeply review.
I don't think engineers should have to choose between wading through thousands of lines of slop and just smashing LGTM on every pull request. The problem is that the tools for code review are built for an age where code was expensive to write. Now that code is cheap, we need to start experimenting with tools that allow us to stay in sync with what's going on, while also not needing to review every single line individually.
But, that has very little to do with the work described in the OP. Maybe EmDash will fail to gain sufficient traction to have their own network effects, but in the meantime, doing moderation on plugins in their marketplace is still important work. Automated moderation to prevent abuse and malware is useful, and is orthogonal to the social proof you're talking about.
It's difficult to put the blame for that on the consumer, who has no visibility into manufacturing or logistics, and who has vanishingly-small options for not participating. Buying domestic goods is very difficult or impossible, and goods which are manufactured in more environmentally-safe ways are significantly more expensive (because the costs I mentioned earlier weren't externalized).
If a consumer is presented with two options, one that costs $X and has unknown environmental costs, and one that costs $2X and is marketed as being environmentally safe, the majority will choose the first. This is especially true as economic forces continue to squeeze average people.
Consumers absolutely participate in the problem, but the only process by which it could be corrected is regulation, and the only entity capable of that is the government. (Democracy being what it is, you can however place more blame at the feet of voters.)
What really happened is that Stripe's products used to be simple. If you're only accepting credit cards and only serving the US market, the API surface is extremely simple. Once you start going multinational and accepting different types of payments it gets much more complex.
For example, OXXO gives users a barcode and lets them take it to a physical location and complete the purchase, so instead of a system like Visa which can confirm a transaction in a maximum of O(seconds), you also have to support methods where confirmations take O(days). Building custom API endpoints for each payment method isn't realistic, since there are hundreds worldwide, and merchants want a single integration point that can support anything from credit cards to coupon-based systems like OXXO.
TL;DR -- Stripe's APIs are definitely more complex now, but it's not because of poor design, it's because they simply have to be in order to serve the customers and markets the company is now reaching.
With all that said, I don't think we can extrapolate that their business wasn't doing well or that they couldn't have raised more money. Cloudflare probably just offered a good enough deal that it didn't make sense to try to grind it out.
What I really mean is that when M&A happens, it seems like a lot of people think the acquirer is the only one with any agency, and that's not true at all.
now: building https://theseus.dev
was: staff engineer @stripe (developer experience, applied ml), engineer @auth0, CTO @kevel, co-founder @agilezen (acq. 2010), author of ninject in a former life
[ my public key: https://keybase.io/nkohari; my proof: https://keybase.io/nkohari/sigs/D2wzLAGkEsKCwxKhK7peaDEpYTGNgvN13B4Teyd4ZXY ]