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.

I guess it's a matter of pros and cons and tradeoffs.

On the one hand a product that solves a narrow and specific problem can focus more on that problem and do a better job of addressing it than a general, all-in-one product can. But then on the other hand it still seems to me that the what I propose about cohesion stands.

Using Anrok as an example, on the one hand the fact that Anrok is narrowly focused on tax and thus is able to do a better job of solving tax-related problems works in Anrok's favor. But on the other hand, there are cohesion-related things that work against Anrok such as having to integrate with other tools and such as customers having to spend more time shopping (with an all-in-one solution they just buy one thing and are done).

I suppose you'd agree that there are in fact tradeoffs at play here and that the real question is what direction the scale tends to lean. And I suppose you are of the opinion that the scale tends to lean in favor of narrower, more targeted solutions than broader, more all-in-one solutions. Is all of that true? If so, would you mind elaborating more on why you are of that belief?

Kudos for writing this post. I know it's promotional/self-interested, but I think that's fine. It's also pro-social. Having the rule/norm to encourage this type of post seems unlikely to be abused in a net-negative sort of way (assuming some reasonable restrictions are in place).

What are your goals? Money? Impact? Meaning? To what extent?

I think it'd also be helpful to elaborate on your skillset. Front end? Back end? Game design? Mobile apps? Design? Product? Data science?

I'll provide a dissenting perspective here. I actually came away from reading this feeling like Metz' position is maybe fine.

Everybody saw it. This is an influential person. That means he's worth writing about. And so once that's the case, then you withhold facts if there is a really good reason to withhold facts. If someone is in a war zone, if someone is really in danger, we take this seriously.

It sounds like he's saying that the Times' policy is that you only withhold facts if there's a "really" good reason to do so. I'm not sure what type of magnitude "really" implies, but I could see the amount of harm at play here falling well below it. If so, then Metz is in a position where his employer has a clear policy and doing his job involves following that policy.

As a separate question, we can ask whether "only withhold facts in warzone-type scenarios" is a good policy. I lean moderately strongly away from thinking it's a good policy. It seems to me that you can apply some judgement and be more selective than that.

However, I have a hard time moving from "moderately strongly" to "very strongly". To make that move, I'd need to know more about the pros and cons at play here, and I just don't have that good an understanding. Maybe it's a "customer support reads off a script" type of situation. Let the employee use their judgement; most of the time it'll probably be fine; once in a while they do something dumb enough to make it not worth letting them use their judgement. Or maybe journalists won't be dumb if they are able to use judgement here, but maybe they'll use that power to do bad things.

I dunno. Just thinking out loud.

Circling back around, suppose hypothetically we assume that the Times does have a "only withhold facts in a warzone-type scenario" policy, that we know that this is a bad and overall pretty harmful policy, and that Metz understands and agrees with all of this. What should Metz do in this hypothetical situation?

I feel unclear here. On the one hand, it's icky to be a part of something unethical and harmful like that, and if it were me I wouldn't want to live my life like that, so I'd want to quit my job and do something else. But on the other hand, there's various personal reasons why quitting your job might be tough. It's also possible that he should take a loss here with the doxing so that he is in position to do some sort of altruistic thing.

Probably not. He's probably in the wrong in this hypothetical situation if he goes along with the bad policy. I'm just not totally sure.

I strongly suspect that spending time building features for rate limited users is not valuable enough to be worthwhile. I suspect this mainly because:

1. There aren't a lot of rate limited users who would benefit from it.
2. The value that the rate limited users receive is marginal.
3. It's unclear whether doing things that benefit users who have been rate limited is a good thing.
4. I don't see any sorts of second order effects that would make it worthwhile, such as non-rate-limited people seeing these features and being more inclined to be involved in the community because of them.
5. There are lots of other very valuable things the team could be working on.