I was envisioning that you can organize a festival incrementally, investing more time and money into it as you receive more and more validation, and that taking this approach would de-risk it to the point where overall, it's "not that risky".

For example, to start off you can email or message a handful of potential attendees. If they aren't excited by the idea you can stop there, but if they are then you can proceed to start looking into things like cost and logistics. I'm not sure how pragmatic this iterative approach actually is though. What do you think?

Also, it seems to me that you wouldn't have to actually risk losing any of your own money. I'd imagine that you'd 1) talk to the hostel, agree on a price, have them "hold the spot" for you, 2) get sign ups, 3) pay using the money you get from attendees.

Although now that I think about it I'm realizing that it probably isn't that simple. For example, the hostel cost ~$5k and maybe the money from the attendees would have covered it all but maybe less attendees signed up than you were expecting and the organizers ended up having to pay out of pocket.

On the other hand, maybe there is funding available for situations like these.

Virtual watercoolers

As I mentioned in some recent Shortform posts, I recently listened to the Bayesian Conspiracy podcast's episode on the LessOnline festival and it got me thinking.

One thing I think is cool is that Ben Pace was saying how the valuable thing about these festivals isn't the presentations, it's the time spent mingling in between the presentations, and so they decided with LessOnline to just ditch the presentations and make it all about mingling. Which got me thinking about mingling.

It seems plausible to me that such mingling can and should happen more online. And I wonder whether an important thing about mingling in the physical world is that, how do I say this, you're just in the same physical space, next to each other, with nothing else you're supposed to be doing, and in fact what you're supposed to be doing is talking to one another.

Well, I guess you're not supposed to be talking to one another. It's also cool if you just want to hang out and sip on a drink or something. It's similar to the office water cooler: it's cool if you're just hanging out drinking some water, but it's also normal to chit chat with your coworkers.

I wonder whether it'd be good to design a virtual watercooler. A digital place that mimicks aspects of the situations I've been describing (festivals, office watercoolers).

1. By being available in the virtual watercooler it's implied that you're pretty available to chit chat with, but it's also cool if you're just hanging out doing something low key like sipping a drink.
2. You shouldn't be doing something more substantial though.
3. The virtual watercooler should be organized around a certain theme. It should attract a certain group of people and filter out people who don't fit in. Just like festivals and office water coolers.

In particular, this feels to me like something that might be worth exploring for LessWrong.

Note: I know that there are various Slack and Discord groups but they don't meet conditions (1) or (2).

More dakka with festivals

In the rationality community people are currently excited about the LessOnline festival. Furthermore, my impression is that similar festivals are generally quite successful: people enjoy them, have stimulating discussions, form new relationships, are exposed to new and interesting ideas, express that they got a lot out of it, etc.

So then, this feels to me like a situation where More Dakka applies. Organize more festivals!

How? Who? I dunno, but these seem like questions worth discussing.

Some initial thoughts:

1. Assurance contracts seem like quite the promising tool.
2. You probably don't need a hero license to go out and organize a festival.
3. Trying to organize a festival probably isn't risky. It doesn't seem like it'd involve too much time or money.

I wish there were more discussion posts on LessWrong.

Right now it feels like it weakly if not moderately violates some sort of cultural norm to publish a discussion post (similar but to a lesser extent on the Shortform). Something low effort of the form "X is a topic I'd like to discuss. A, B and C are a few initial thoughts I have about it. What do you guys think?"

It seems to me like something we should encourage though. Here's how I'm thinking about it. Such "discussion posts" currently happen informally in social circles. Maybe you'll text a friend. Maybe you'll bring it up at a meetup. Maybe you'll post about it in a private Slack group.

But if it's appropriate in those contexts, why shouldn't it be appropriate on LessWrong? Why not benefit from having it be visible to more people? The more eyes you get on it, the better the chance someone has something helpful, insightful, or just generally useful to contribute.

The big downside I see is that it would screw up the post feed. Like when you go to lesswrong.com and see the list of posts, you don't want that list to have a bunch of low quality discussion posts you're not interested in. You don't want to spend time and energy sifting through the noise to find the signal.

But this is easily solved with filters. Authors could mark/categorize/tag their posts as being a low-effort discussion post, and people who don't want to see such posts in their feed can apply a filter to filter these discussion posts out.

Context: I was listening to the Bayesian Conspiracy podcast's episode on LessOnline. Hearing them talk about the sorts of discussions they envision happening there made me think about why that sort of thing doesn't happen more on LessWrong. Like, whatever you'd say to the group of people you're hanging out with at LessOnline, why not publish a quick discussion post about it on LessWrong?

Hm, maybe.

Sometimes it can be a win-win situation. For example, if the call leads to you identifying a problem they're having and solving it in a mutually beneficial way.

But often times that isn't the case. From their perspective, the chances are low enough where, yeah, maybe the cold call just feels spammy and annoying.

I think that cold calls can be worthwhile from behind a veil of ignorance though. That's the barometer I like to use. If I were behind a veil of ignorance, would I endorse the cold call? Some cold calls are well targeted and genuine, in which case I would endorse them from behind a veil of ignorance. Others are spammy and thoughtless, in which case I wouldn't endorse them.

I agree with everything you've said. Let me try to clarify where it is that I think we might be disagreeing.

I am of the opinion that some "narrow problems" are "good candidates" to build "narrow solutions" for but that other "narrow problems" are not good candidates to build "narrow solutions" for and instead really call for being solved as part of an all-in-one solution.

I think you would agree with this. I don't think you would make the argument that all "narrow problems" are "good candidates" to build "narrow solutions" for.

Furthermore, as I argue in the post, I think that the level of "cohesion" often plays an important role in how "appropriate" it is to use  a "narrow solution" for a "narrow problem". I think you would agree with this as well.

I suspect that our only real disagreement here is how we would weigh the tradeoffs. I think I lean moderately more in the direction of thinking that cohesiveness is important enough to make various "narrow problems" insufficiently good candidates for a "narrow solution" and you lean moderately more in the direction of thinking that cohesiveness isn't too big a deal and the "narrow problem" still is a good candidate for building a "narrow solution" for.

To be clear, I don't think that any of this means that I should attempt to build all-in-one products. I think it means that in my calculus for what "narrow problem" I should attempt to tackle I should factor in the level of cohesion.

In practice, all-in-one tools always need a significant degree of setup, configuration and customization before they are useful for the customer. Salesforce, for example, requires so much customization, you can make a career out of just doing Salesforce customization.

I can see that being true for all-in-one tools like Salesforce that are intended to be used across industries, but what about all-in-one tools that are more targeted?

For example, Bikedesk is an all-in-one piece of software that is specifically for bike shops and I would guess that the overall amount of setup and configuration for a shop using Bikedesk is lower than that of a bike shop using a handful of more specific tools.

The tradeoff is between a narrowly focused tool that does one job extremely well immediately, with little or no setup

I suppose the "little or no setup" part is sometimes this is the case, but it seems to me that often times it is not the case. Specifically, when the level of cohesiveness is high it seems to me that it is probably not the case.

Using the bike shop as an example, inventory management software that isn't part of an all-in-one solution needs inventory data to be fed to it and thus will require a moderate amount of setup and configuration.

See also Adam Ragusea's podcast episode on the topic.

Hm, gotcha.

It's tough, I think there are a lot of tradeoffs to navigate.

• You could join a big company. You'll 1) get paid, 2) work on something that lots of people use, but 3) you'll be a small cog in a large machine, and it sounds like that's not really what you're looking for. It sounds like you enjoy autonomy and having a meaningful and large degree of ownership.
• You could work on your own project. That addresses 3. But then 1 and 2 become pretty big risks. It's hard to build something that makes good money and lots of people use.
• You could join an open source project that lots of people use and is lacking contributors. But there's often not really a path to getting paid there.
  • Something interesting: https://fresh.deno.dev/. I really like what they're doing. I personally think it's the best web framework out there. And there's only one person working on it. He's an incredible developer. Deno is paying him to work on it. I'm not sure if they'd be open to paying a second contributor. And I am not too optimistic that Fresh will become something that many people use.
• Working on LessWrong is an interesting possibility. After all, you're a longtime user and have the right skillset. However, 1) I'm not sure how good the prospects are for getting paid, 2) it's a relatively small community so you wouldn't be getting that "tons and tons of people use something I built" feeling, and 3) given that it's later stage and there's a handful of other developers working on it, I'm not sure if it'd provide you enough feeling of ownership.
• Joining a small company seems like the most realistic way to get 1, 2 and 3, but the magnitude of each might not be idea: smaller companies tend to pay less, have fewer users, and still have enough employees such that you don't really have that much ownership.

My best guess is that starting your own company would be best. Something closer to an indie hacker-y lifestyle SaaS business than a "swing for the fences" VC-backed business. The latter is probably better if you're earning to give and looking to maximize impact, but since you're leaning more towards designing a good life for yourself, I think the former is better, and I also think most people would agree with that. I've seen a lot of VC's be very open about the fact that the "swing for the fences" approach is frequently not actually in the founder's interest.

I'm looking to do the lifestyle SaaS business thing right now btw. If you're interested in that I'd love to chat: shoot me a DM.

I was thinking that too actually. And at the time I was thinking that for cohesion-related reasons, it's often the case that there just isn't a market for narrow tools like inventory software and instead the market demands an all-in-one tool, in which case there wouldn't be a demand for a tool that solves the problem of many formats of POS system data.

But now I'm not so sure. I'm feeling pretty agnostic. I'm not clear on how often the market demand is largely for all-in-one solutions vs how often there is a market demand for narrow solutions.