Adam Zerner
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:
There aren’t a lot of rate limited users who would benefit from it.
The value that the rate limited users receive is marginal.
It’s unclear whether doing things that benefit users who have been rate limited is a good thing.
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.
There are lots of other very valuable things the team could be working on.
Hm, good points.
I didn’t mean to propose the difficulty frame as the answer to what complexity is really about. Although I’m realizing now that I kinda wrote it in a way that implied that.
I think what I’m going for is that “theorizing about theorizers” seems to be pointing at something more akin to difficulty than truly caring about whether the collection of parts theorizes. But I expect that if you poke at the difficulty frame you’ll come across issues (like you have begun to see).
I actually never really understood More Dakka until listening to the song!
I spent a bit of time reading the first few chapters of Complexity: A Guided Tour. The author (also at the Santa Fe institute) claimed that, basically, everyone has their own definition of what “complexity” is, the definitions aren’t even all that similar, and the field of complexity science struggles because of this.
However, she also noted that it’s nothing to be (too?) ashamed of: other fields have been in similar positions, have come out ok, and that we shouldn’t rush to “pick a definition and move on”.
We have to theorize about theorizers and that makes all the difference.
That doesn’t really seem to me to hit the nail on the head.
I get the idea of how in physics, if billiards balls could think and decide what to do it’d be much tougher to predict what will happen. You’d have to think about what they will think.
On the other hand, if a human does something to another human, that’s exactly the situation we’re in: to predict what the second human will do we need to think about what the second human is thinking. Which can be difficult.
Let’s abstract this out. Instead of billiards balls and humans we have parts. Well, really we have collections of parts. A billiard ball isn’t one part, it consists of many atoms. Many other parts. So the question is of what one collection of parts will do after it is influenced by some other collection of parts.
If the system of parts can think and act, it makes it difficult to predict what it will do, but that’s not the only thing that can make it difficult. It sounds to me like difficulty is the essence here, not necessarily thinking.
For example, in physics suppose you have one fluid that comes into contact with another fluid. It can be difficult to predict whether things like eddies or vortices will form. And this happens despite the fact that there is no “theorizing about theorizers”.
Another example: if is often actually quite easy to predict what a human will do even though that involves theorizing about a theorizer. For example, if Employer stopped paying John Doe his salary, I’d have an easy time predicting that John Doe would quit.
The subtext here seems to be that such references are required. I disagree that it should be.
It is frequently helpful but also often a pain to dig up, so there are tradeoffs at play. For this post, I think it was fine to omit references. I don’t think the references would add much value for most readers and I suspect Romeo wouldn’t have found it worthwhile to post if he had to dig up all of the references before being able to post.
Ah yeah, that makes sense. I guess utility isn’t really the right term to use here.
Yeah, I echo this.
I’ve gone back and forth with myself about this sort of stuff. Are humans altruistic? Good? Evil?
On the one hand, yes, I think lc is right about how in some situations people exhibit just an extraordinary amount of altruism and sympathy. But on the other hand, there are other situations where people do the opposite: they’ll, I dunno, jump into a lake at a risk to their own life to save a drowning stranger. Or risk their lives running into a burning building to save strangers (lots of volunteers did this during 9/11).
I think the explanation is what Dagon is saying about how mutable and context-dependent people are. In some situations people will act extremely altruistically. In others they’ll act extremely selfishly.
The way that I like to think about this is in terms of “moral weight”. How many utilons to John Doe would it take for you to give up one utilon of your own? Like, would you trade 1 utilon of your own so that John Doe can get 100,000 utilons? 1,000? 100? 10? Answering these questions, you can come up with “moral weights” to assign to different types of people. But I think that people don’t really assign a moral weight and then act consistently. In some situations they’ll act as if their answer to my previous question is 100,000, and in other situations they’ll act like it’s 0.00001.
I would be willing to pay someone to help draft a LessWrong post for me about this; I think it’s important but my writing skills are lacking.
I’m not looking to write a post about this, but I’d be happy to go back and forth with you in the comments about it (no payment required). Maybe that back and forth will help you formulate your thoughts.
For starters, I’m not sure if I understand the bias that you are trying to point to. Is it that people assume others are more altruistic than they actually are? Do any examples come to your mind other than this?
Discord threads do have a significant drawback of lowering visibility by a lot, and people don’t like to write things that nobody ever sees.
Meh. If you start a thread under the message “Parent level message” in
#the-channelthe UI will indicate that there are “N Messages” in a thread belonging to “Parent level message”. It’s true that those messages aren’t automatically visible to people scrolling through the main channel, they’d have to click to open the thread, but if your audience isn’t motivated to do that it seems to me like they aren’t worth interacting with in the first place.I do prefer how Slack treats threads though. They’re more light and convenient to use in Slack.
I wish more people used threads on platforms like Slack and Discord. And I think the reason to use threads is very similar to the reason why one should aim for modularity when writing software.
Here’s an example. I posted this question in the
#haskell-beginnersDiscord channel asking whether it’s advisable for someone learning Haskell to use a linter. I got one reply, but it wasn’t as a thread. It was a normal message in#haskell-beginners. Between the time I asked the question and got a response, there were probably a couple dozen other messages. So then, I had to read and scroll through those to get to the response I was interested in, and to see if there were any other responses.Each of the messages were part of a different conversation. I think of it as something like this:
Conversation A; message 1 Conversation A; message 2 Conversation B; message 1 Conversation C; message 1 Conversation A; message 3 Conversation C; message 2 Conversation A; message 4 Conversation B; message 2There is a linear structure for something that more naturally structured as a tree.
Function Programming Discord server #haskell-beginners channel Conversation A Message 1 Message 2 Message 3 Message 4 Conversation B Message 1 Message 2 Conversation C Message 1 Message 2In writing software, imagine that you have three sub-problems that you need to solve. And imagine if you approached this by doing something like this:
// stuff for sub-problem #1 // stuff for sub-problem #1 // stuff for sub-problem #2 // stuff for sub-problem #3 // stuff for sub-problem #1 // stuff for sub-problem #3 // stuff for sub-problem #1 // stuff for sub-problem #2We generally prefer to avoid writing code this way. Instead, we prefer to take a more modular approach and do something like this:
solveSubProblemOne(); solveSubProblemTwo(); solveSubProblemThree(); function solveSubProblemOne() { ... } function solveSubProblemTwo() { ... } function solveSubProblemThree() { ... }By writing the code in a modular fashion, you can easily focus on the code related to sub-problem #1 and not have to sift through code that is unrelated to sub-problem #1. On the other hand, the more imperative non-modular version makes it difficult to tell what code is related to what sub-problem.
Similarly, using threads on platforms like Slack and Discord make it easy to see what messages belong to what conversations.
And like software, the importance of this gets larger as the “codebase” becomes more involved and complex. Imagine a Slack channel with lots and lots of conversations happening simultaneously without threads. That is difficult to manage. But if it’s a small channel with only two or three conversations happening simultaneously, that is more manageable.
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.