755 karma · joined October 9, 2014
I think the very point of GP is that there are many people who do, in fact, develop friendships with their coworkers.
It really depends on the work you're doing. And even for a single employee, it can change from one month to the next. But highly collaborative work can benefit from spontaneous interactions, more ambiguous work can benefit from live whiteboarding sessions, and more generally, teams can develop greater cohesion and stronger relationships through shared experience. Not every person needs this, and certainly not all the time, but to suggest that it's unimaginable that anyone could ever derive greater value (or that a collective organization could ever derive greater value) from in-person work is disappointing.
Remote work has its place. In-person work has its place. Neither is the solution 100% of the time.
Fast forward 3 years with this company and if they build their unified notification inbox product, with the benefit of hindsight you could say "Superpowered started selling productivity software, and its still selling productivity software"
I have no idea if this company will pan out or not. But I do know it's very easy to craft historical narratives that seem so clear after the fact. I have watched many founders do it.
It's nothing about Clerk specifically, it's just a problem with these kinds of products. I just worry that as your customers grow and scale, they naturally need to leave your platform (or downgrade to an auth-only solution). I'll definitely be curious to see how the product grows, though!
- Presumably, engineers building customer-facing applications
- Google G Suite can be a fine SSO solution for internal apps, but isn't the thing you're going to use for your customers
- I'm not sure how to answer this one. Surely it's quite obvious how a beautiful user experience is valuable? Your customers aren't comparing your experience against your competitors, they're comparing you to the best experience they have seen to date in any space. Companies who don't invest in their experience (and by extension, their visual design) will fall behind.
- At a surface level this may appear true, but in practice people often significantly underestimate the time involved in building a high quality and secure authentication system. If all you do is throw an email address and password in a table, then sure. But you're going to have sign up, log in, forgot password workflows (and emails) at the very least. Then, if you're actually trying to protect something, you're going to have password complexity requirements, brute force protection, 2FA (authenticator, sms, etc), security notifications, browser fingerprinting, etc - to name a few.
I'm still not sure how I feel on the outsourced authentication concept, but certainly not because building your own auth is free or cheap. Just because it's such a critical part of data that it might be worth eating the cost for (but I'm not sold necessarily).
Can customers extend your UI components? Do they store that data with you? One of the nice parts about authentication only is that it's relatively well-defined and not a place where customers frequently have variable needs (outside of just data sources to auth against).
Cool idea either way though, and I like seeing more innovation in the space.
In other words: the mass public is unlikely to become Bitcoin-first until they can gain confidence in the stability of Bitcoin. This is notwithstanding the fact that stable governments likely will not accept BTC as a national currency, meaning citizens will still need USD/EUR/GBP/their local currency for paying taxes and transacting with the government.
It feels as though your post just handwaved away all of the practical issues with actually making the world BTC-first and then asked why I cared about them. Because, in order for the world you're proposing to exist, we almost certainly have had to solve them.
My point is not to say that the problem can't be solved on a technical level. It's that it still requires trust. That problem doesn't get eliminated, it simply moves.
Currency fundamentally requires trust - at the very least it requires trust that the asset you are receiving is roughly equivalent in worth to the asset you're giving as part of the transaction. In the case of centralized banks, you have to trust the bank to help ensure the value of the currency. In the case of bitcoin, you have to trust the network, its participants, the exchanges, etc. Knowing that your transaction itself is secure is only a part of the actual, practical issue. You also have to be confident you can then use that asset to purchase an item of equivalent worth in the near term future. Trust doesn't stop, it simply moves. Centralized banks have made mistakes most certainly. They have also been around for hundreds of years. Bitcoin has perhaps fewer disappointments (although certainly not zero). It has also been around for a tiny fraction of that. How much of the extra confidence in Bitcoin is purely attributed to its otherwise relatively limited history as a store or exchange of value?
I won't opine on which one is "better" (if such a description even makes sense). However, it does seem at times that people rail against central banks while turning a convenient blind eye to the challenges of decentralized banks. Is it the case that only decentralized banking problems can be solved, and centralized banking problems cannot?
This would be without even touching any “wife-beater,” rapist or murderer.
There are a lot of people unnecessarily locked up for absurd sentences compared to the crime who absolutely deserve another chance at society. We should actively want that. It’s a net good for society and it happens to be a lot less expensive, too.
I don’t believe you will be choosing which hospital you go to if you’re unconscious, or facing a serious acute medical concern placing you in desperation. Coincidentally, those tend to be the times when costs also skyrocket.
—
The issue with treating healthcare like a free market is that some people just won’t get healthcare. Free markets aren’t going to build a hospital in a small enough town because the cost can’t be justified.
Your point that the US outranks most other countries is perhaps true for some things, but completely false for baseline measures such as infant mortality, life expectancy, cost per capita, etc. As a country the US can sometimes pull ahead on specialized care in part because of a prevalence of supporting technology compared to other countries, and I’ll grant that. But our system is hardly “better” than other developed nations on almost any objective measure.
My honest feedback:
There are already a host of services that do authentication, and a host of services that do payment and subscription management, and the leaders in each of those spaces are actually quite good. Loginland currently sits in the middle - it's not the best authentication system, nor is it the best payment system. It's just a little bit of both.
So, how do you combine the individual value of those services into something that is distinctly valuable? An interesting example in this space is fast.co. I have no idea if they will ultimately be successful or not. However, they verticalized specifically to e-commerce and combined login + checkout to a single step that is significantly easier/faster for the customer than a conventional checkout process. The pitch to the seller is: higher conversion rate, meaning more revenue (and we can potentially reduce fraud in the process). Among other things, they do this by opting for a fixed-time instant cancellation window after the order, rather than putting up a confirmation page beforehand. They use the strength of the identity system to streamline the checkout process, which is a unique merging of those two things that provides real value. There's also not much downside, as the traditional e-commerce customer doesn't associate much value with customer identities in the same way that a SaaS platform might. As it currently sits, I don't see that value unlock for loginland, so it feels like a mushy middle position.
Another direction here is thinking through how media is monetized. Right now, most major news publication (NYTimes, Washington Post, BBC, etc) have login and identity management mostly for managing subscriptions to news content (the identity itself isn't a ton of value to these companies). I believe there is probably a business that can be built around offloading identity and payment for these companies (customer has a relationship with loginland, loginland can get me into Washington Post content in a single click). Helping news companies shift more of their revenue from ads-based to consumption based or recurring would be huge. This business may already exists in several forms (I personally know a founder that started one which ultimately did not work out), but is another example of a vertical play.
In short, as you navigate next steps for this product, I'd advise you to keep an eye on where your customers will really get value from you. Streamlining identity management or checkout might not have as much of a conversion lift for SaaS as it would for other industries where purchase intent is lower. Look first for those, and see how you can best help them. Don't get discouraged by the comments here, though. Often times tiny tweaks make all the difference between success and failure.
In the years I have been doing take-home exercises for candidates, I have yet to see a single instance of a great take home leading to a terrible on-site or hire in terms of technical skill. There have definitely been great take-homes for candidates that we later chose not to hire, but usually due to challenges interacting with the product team, or in some cases too much fixation on technical perfection with no focus on business realities, etc. If there are a large number of candidates paying others to do their take homes for them, they should be asking for refunds.
Second, even if this is a problem, there's a very simple solution. For candidates that do well on the take home, either on a call or on the on-site, do a live code review with the candidate and ask them to explain a bit more about why they wrote the code the way that they did. Ask them questions about other approaches, or what they'd do if they have more time. Candidates will be significantly more comfortable talking about their own code they wrote. It'll be quite clear if the candidate didn't write it themselves.
It's hard to imagine how the precedent established by not forcing change here would be desired by anyone. We're not far from a world where basically all of the software you can consume, how you can consume it, and even the price of it, is effectively determined (or at least heavily influenced) by one of 3 companies. We're not talking about just the services those companies offer, we're talking about all of the software services that any company wants to offer.
The cost of building a new operating system in the modern age is incredibly prohibitive, such that we're unlikely to see any meaningful competition in the form of alternatives here. Even if such a project were to happen, they'd have to overcome the incredible inertia secured from walled garden that the major players have built for their own ecosystems.
I'm not sure why an order of magnitude should be the effect we're chasing. Doubling would be phenomenal, even a 10% lift could be massive depending on your current size. The only threshold you need to hit is that the value gained from building the apps exceeds the cost to build them. Certainly that can happen at much less than 10x growth.
With that said, the problem is that this is an infeasible proposition for businesses. Ignoring any specific tasks that are actually just better when run native, many users of high-touch apps (used at least once per week, for example) get real value from having a native experience. If your competitors have it and you don't, you'll likely lose users because of it. Asking Facebook to drop the Instagram app because we want to stick it to Apple is only going to help Snap.
In theory, there is potentially some future hope for WebAssembly and PWAs, but if/when they get to the point where they can truly replicate a native experience, I see no reason why Apple wouldn't restrict them the same way that they do native apps. That is, unless a court rules against it or legislation changes.
* Agreed with the problem, although I've found io-ts to be great. For incoming client requests: GraphQL is helpful if you're using that, but it's also relatively trivial to create an io-ts middleware for express that will get you similar guarantees. For database interaction, assuming you're talking about relational data stores, this is a challenge. Personally, I'm using Mikro ORM and it has been great so far. The one blessing here is that you're probably not dealing with unknown data types when talking to a data store, so it hasn't felt like as much of a concerning surface area for me personally. HTTP is valid, but I actually like io-ts as an approach here possibly more than using Jackson with static types due to its failure model - but again I acknowledge this is a personal choice.
* I guess it depends on your needs here, but base express can be great for simple apps, and NestJS is fantastic for more complex ones. You're 100% on point with ORMs, though, where I've been incredibly dissatisfied generally. As mentioned above, I've recently stumbled on Mikro ORM which takes a unit of work pattern similar to Hibernate, without the painful startup time. You can tell it's not perfect, and certainly not as feature rich as Hibernate, but also feels safe enough. I imagine if you tried to do everything through the ORM it could get painful, but most of my apps are structured as multiple modules where each module only controls the entities within that module. It keeps the reach of the ORM limited and abstracted behind "services" (in the modular monolith sense, not remote services).
* Yeah I see both ends of this one. Historically been a JVM user and have a ton of appreciation for it, but also like TS's approach more than Kotlin in several ways. You're right about collections though, ES6 is a joke there.
Whether it’s good that they have become a news source or not is a valid question. But right now, they are, and I think preserving the president’s tweets seems like a pretty easily defensible decision. Even if it is also (or primarily) motivated by their own business interests.
That said, perhaps “unsubstantiated” is a better description.
Because whoever does achieve the next unlock - should it happen - will receive an unimaginably large windfall. This is the classic intent of venture capital. In fact, I'd suggest that AI is actually one industry where VC is doing what it does best: taking extremely risky bets with a large potential upside.
> Could this be part of "AI"'s appeal? A dream of absolving businesses and individuals from accountability.
Presently, this seems to be one of its large detractors. If I have an employee do something stupid, I can say that an employee did something stupid. People might wonder why they were allowed to do that stupid thing, and what we're going to do to prevent it from happening again, but the explanation of the source is satisfactory. We're fallible, and we understand the fallibility of others (generally speaking).
AI is not that at all. If my automation does something stupid, I still have all the blame, and yet I have nowhere else to pass it off to. "We don't understand why our AI did this really stupid thing" is, frankly, not a satisfying response (nor should it be). Businesses employing AI certainly are not absolved of any form of accountability, and are arguably exposed to more of it (since they're not able to pass the blame on to another fallible human, and have to take direct accountability of a system they built but don't fully understand).
And even if the inputs are great, it's hard to understand what we can do with a 99% confidence prediction. The next great unlock that society is waiting for in the AI realm applies to industries where failure is not an easily acceptable outcome.
Take self-driving cars for example. Even if we can objectively prove that current AI models can drive on current roads in current conditions with a lower fatality rate than humans (this is debatable anyway, but let's assume) - what do we do when it knows it's not confident? If we assume the driver hasn't been paying attention during the ride so far, and a scenario comes up that the AI is uncertain about...the human now has likely mere seconds (at most) to capture their surroundings, analyze the risk, and take corrective action. If we assume the driver has been paying attention during the ride, then what was the point of the AI? Moreover: what if it thought it was confident, but it was still wrong. Who do we blame? How do we mitigate future instances of it? What were once societal problems we could blame on a fallible humans are now obscure technology problems we can't introspect. That's a scary place for a lot of people to be.
Basically, we've reached the level of AI where it can be used as a backup to humans and protect us from royally fucking something up. But the next big unlock will come when it can be the primary actor. It's hard to imagine how we'll get there without the AI actually understanding what it's processing in some real way.
Edit: rephrased the 3rd paragraph.
Rather, it's the programming models put in place by the initial framework choices and architectural decisions that will make the biggest difference. Prototyping a web app in Python isn't fast because Python as a language makes it fast. It's fast when you use Django to effectively wire a database model directly to a set of CRUD endpoints in less than a dozen lines of code, complete with validation. The same can be said about Ruby + Rails.
Node could, in theory, provide a similar capability, but the platform was popularized after large sections of the developer community seemed to demonize frameworks like Django and Rails. So, whether for this reason or another, Node doesn't really have anything quite like Django or Rails, and thus would likely not match the dev speed of those frameworks, all else being equal. Python is _fast enough_, and early stage companies rightfully tend to not worry about CPU usage or hosting costs, because they don't have the scale for it to matter.
------
With all that being said: pick an early tech stack that helps you optimize for iteration speed, not necessarily raw dev speed (although they often overlap). Importantly, you typically want to build a system that minimizes the cost of being wrong in a reasonable time frame. If that's Python? Awesome. If that's Node? Also awesome. If that's Java? Awesome. Pick what you/your team know best and can architect in a sane way to help you find the balance between time to market and ability to experiment.
You don't need to just "build your own alternative to it." You need to get all the content (this is actually not as easy as you make it seem - stolen or not), then integrate that into Instagram, WhatsApp, Slack, and hundreds of other platforms across the world as the supported way of sharing gifs. Then you'll have to build a brand around the product that people remember, and whose website they actually visit when they want images and aren't using one of the hundreds of platforms that already natively integrates giphy.
And in order to do all that, you'll have to somehow manage to convince everyone out there that your gif search system is better than their gif search system that they already know, are comfortable with, and generally happy with. Your pitch will probably be that theirs is owned by Facebook, and is therefore a violation of their privacy. But you know who else is owned by Facebook? Facebook. And yet Facebook is pushing close to 2 billion daily active users.
Convenience trumps privacy in modern society most of the time. I'm sure there will be a changing of the winds - there always is - but there likely will not be significant competition for Facebook/Twitter/Instagram/Giphy/Google/(put any other company in here) until that comes. The network effects are too strong, and the convenience is too great.
There are so many posts about "(Twitter/Facebook/Giphy) clone in a (day/weekend/week/month)" and yet there's a distinct lack of commercial successes in these spaces.
Edit: a word.
This reminds me of the phrase “don’t sell past the close.” Once you have the user, focus on keeping them not selling them further. Many services have a way of saying “I’ve used this before” to skip the tutorial, for example.
reCAPTCHA changed to its current model to try to significantly reduce friction in the "hopefully normal" case (down to just a check box if all goes well) because every ounce of friction you add to critical inflection points in your product translates to meaningful lost opportunity.
Even if this wasn't a problem, and it were trivial to create something that's easy for humans and hard for computers, it's just not worth most companies' time. Would they rather spend a few days properly implementing and testing a captcha solution, then whatever unknown time on future bug fixes and support, or setup reCAPTCHA in 30 minutes and move on to things that produce value for their customers?
- We started out with self generated and self hosted captcha. It was too easy to beat. Complexity of the image generation turned up until eventually it was easier to just outsource it to someone else. Going to throw out a guess here that reCAPTCHA is far from simple, and likely exceeds what most teams would want to run internally.
- Google has an uptime that's significantly higher than most companies. I'm not defending any of Google's habits or business practices, but I personally wouldn't bet that most companies can run software more reliably than Google.
- As someone else mentioned, fail open is an option in situations like these (depending on the threats you're trying to protect against). For something with a high probability of failure, this could make sense, but I would have a hard time imagining a team allocating time to deal with the case "when Google is down" unless it's truly life or death software (think: surgical robots, autopilots, etc)
- Slack used to (they still might I just haven't created a new workspace in a while) have Slackbot message you to setup your profile so that you're literally using the software as part of onboarding.
- Aircall has you get a phone number and place a call directly from your browser, then use your phone to call that number back and have it ring in your browser.
Focus on the the path to that magic moment first, ensuring that users who do sign up have an incredible onboarding experience and understand the value.
Otherwise, you're just pouring water into a leaky funnel, and you might end up even worse off. You'll spend the same amount of time and money on support for your leads, but few of them will ever convert to dollars.
Art is a broad concept - it doesn't suggest any specific form or delivery. Software is fairly concrete - it has to be run on a computer.
A more appropriate comparison would be art versus scientific research, or art versus engineering. I think that's a more interesting question, to which I would say: perhaps we could survive without either, but I can't imagine we'd thrive without both.
And yet, plenty of controls to protect people don't turn into permanent revocations of human rights. Why, when this argument comes up, do we conveniently forget about those? Do you really think that the plan of governments around the world is to cripple their GDP output and keep everyone locked inside as some sort of mass population control exercise? And a pandemic that would benefit from these types of actions was just a great time to pull the trigger without anyone noticing?
I honestly don't understand this argument. On one end of the spectrum you have complete freedom with no laws, police & fire departments, public education, militaries, government welfare programs, airport security, etc. On the other hand, you have whatever world you fear we'll end up in when all of our rights are stripped. It would seem to me that most first world countries sit somewhere between those two, because we've generally decided there are many freedoms we're happy to give up (some temporarily, some permanently) for the betterment of society overall. Particularly those where one person's freedom would directly impact another person's right to life.
You can certainly say that you think we should open the country back up and that these restrictions are unnecessary, and provide your supporting data for that argument. But suggesting that this is some fundamental violation of human rights feels like quite a reach.