Board

Applying these three areas to my criteria idea: in science, you're successful if you create new knowledge; in invention, you're successful if you create something useful; in business, you're successful if you make money.

I personally would love to be both a successful inventor and a successful founder. But I'm gradually coming to grips with the realization that if I had to pick one or the other, I'd rather be the successful inventor.

But I don't think that makes me any less ambitious. In fact I think the software industry/society would benefit from having more people who funnel their ambition toward public goods!

I don't consider myself to be doing research on programming languages. I'm just designing one, in the same way that someone might design a building or a chair or a new typeface. I'm not trying to discover anything new. I just want to make a language that will be good to program in. In some ways, this assumption makes life a lot easier. The difference between design and research seems to be a question of new versus good. Design doesn't have to be new, but it has to be good. Research doesn't have to be good, but it has to be new. I think these two paths converge at the top: the best design surpasses its predecessors by using new ideas, and the best research solves problems that are not only new, but actually worth solving. So ultimately we're aiming for the same destination, just approaching it from different directions.

For many good ideas, the constraint to become a business can be just as damaging as the constraint to be research.

That seems obvious, yet I never thought about it much until recently. Perhaps that’s because the most commonly cited reason to not start a startup is roughly “it’s really hard and you probably won’t succeed.” If you’re ambitious, “it’s really hard” is a positive signal, in the same way that most people would judge a $80 pair of boots to be better than a $20 pair.

Framing your ideas as businesses can also dampen your morale. The euphoria of quitting my job and being free to work on my own projects lasted for about two months. After that, it was largely replaced by the soul-crushing burden of how-on-earth-will-I-ever-make-a-living-from-this. Psychologically, I sometimes wonder if it’d be easier to build a business if I wasn’t trying to build a business.

My ideas feel like business ideas because I can totally see how they would make lots of money—eventually. But the problem with these grand visions is that they don’t tell you how to get the idea started, and that’s what matters in a startup. I’ve been working on Findka for 10 months and I’m only now getting to something that’s worth using in the short-term (i.e. before we have lots of users and data to make the algorithm great). Anecdotally, it seems to me that most successful startups are not driven by grand visions at first; rather, the long-term vision comes into view after the company starts to grow.

I wouldn’t be surprised if grand visions are on average more of a liability than an asset for early-stage founders. If that’s the case, it’s ironic that startups, with their change-the-world potential, naturally appeal to grand-vision people like me. Perhaps we’d be better off working through things first in a low-pressure, non-startup phase, switching to startup mode when (and only when) an infant grand vision matures into a real business idea.

The networking would also reduce the risk: even if your exploration doesn’t result in anything significant, you’ll have a network of people who know you do good work. That’s incredibly valuable—if this whole system worked well enough, it could be a good alternative to college. Who needs a degree when you have referrals?

One interesting irony here is that the larger the overall economic opportunity for a new technology, the more it makes sense to let other companies capture market share, as long as there's some part of the stack that Microsoft still owns.

Figuring out the right context to use a technology, even a revolutionary one, is a very big deal: when Bell Labs first developed the transistor, the top applications they had in mind were military radios and missile guidance systems; the NYT article announcing the discovery also suggested smaller hearing aids. There turned out to be other use cases, too.

More generally, tools are useless without materials; materials don't have value unless worked on with tools.

An immediate consequence is that if the price of one input falls by a lot — perhaps due to a positive productivity shock — then the price of other is almost certain to rise.

For the last decade plus, the quantity of data in the world has been exploding: its price, therefore, implicitly declining. Software has been the relatively scarce input, and its price has increased: you can see this in everything from the salaries of software engineers to the market cap of top software companies. Software ate the world, with a huge assist from cheap, plentiful data.

React Native Desktop

I’ll finish with something that I think we did well: migrating away from Supabase was easy for Val Town, because it’s just Postgres. This is one of our core principles, “everything is portable” (https://supabase.com/docs/guides/getting-started/architectur...). Portability forces us compete on experience. We aim to be the best Postgres hosting service in the world, and we’ll continue to focus on that goal even if we’re not there yet.

Having worked on a Baas type offering, this is all very familiar. Over the years, I've come to believe the approach of trying define a service layer with these magic abstractions is fundamentally flawed and will always lead to the problems in this article: poor performance, poor local development experience, no transparency in to what is going on under the hood. They are great for fast proof of concepts, but not sustainable, long term product development.

Just in case I'm wrong, let me exchange some of those neurons for electrons.

Priority order for time-saving appliances: microwave, laundry machine, dishwasher, food processor, electric grill. Under no circumstances should you get a food processor before you get a dishwasher. Seriously. And I include laundry machine here because if you have one, you can do your laundry while cooking, which reduces the net time cost of cooking.

Don't write for others a program you wouldn't want written for you.

Using this (admittedly oversimplified) model, for this hypothetical product, shipping two features at a time would deliver 4x as much value, after 1200 days, as shipping 5 features at a time. With the same engineering team and the same features! In short, that's what makes SpaceX efficient and others inefficient. SpaceX might work engineers a little harder, but that's not the real benefit. The real benefit is that SpaceX has a clear idea of what really, really needs to happen next, and they deliver it incrementally. Others, mostly, don't.

Not shown: the benefits of being able to change your direction, based on customer feedback, after launch #1. The assumption that we are building the same features, but in a different order, is not very realistic. In reality, what you learn after launch #1 is so valuable that you end up changing product direction quite a lot, so early time spent working on features for future milestones is largely wasted.

The answer is, from just the context of the article, you don't know. The problem is that the author suffers badly from what's called the selection bias: wanting to believe something, and then examining only the evidence that supports your belief.

Three types of distributed system designers

I don't much like the fact of the Google Vortex. It's very sad to me that there are now two programmer universes: the haves and the have-nots. More than half of the programmers I personally know have already gone to the other side. Once you do, you can suddenly work on more interesting problems, with more powerful tools, with on average smarter people, with few financial constraints... and you don't have to cook for yourself. For the rest of us left behind, the world looks more and more threadbare.

Last November I went to an IETF meeting for the first time. The IETF is an interesting place; it seems to be about 1/3 maintenance grunt work, 1/3 extending existing stuff, and 1/3 blue sky insanity. I attended mostly because I wanted to see how people would react to TCP BBR, which was being presented there for the first time. (Answer: mostly positively, but with suspicion. It kinda seemed too good to be true.)

Requiem for a dream One person at work put it best: "layers are only ever added, never removed."

A few years ago I learned the investor variant of Sturgeon’s Law. Here’s what a VC told me: 90% of new things will fail. Therefore you can just predict every new thing will fail, and 90% of the time you’ll be right. That’s a pretty good way to feel good about yourself, but it’s not very useful. Anybody can do that. Instead, can you pick the 10% that will succeed?

Projects live or die because of the energy people do or do not continue to put into them.