You might be interested in this perspective from the Not Just Bikes YouTube channel that Amsterdam being designed for pedestrians and bikers makes this problem of worrying about your kids being hit by a car mostly go away.

The other thing about filterPromotedPosts is that it kind of sounds like the input is promoted posts and the output is some unspecified subset of them. filterPostsForPromoted avoids that but starts to feel unwieldy to me. (But maybe I should just be more okay with unwieldy names.)

I have the exact same feelings here. It's funny how hard this is to name! Although these issues go away if you think about the name as only one part of the boxes label, and the signature + docstring as the others. Sorta. I think it'd still be nice if the name did as much of the job as possible by itself without having to consult the signature or docstring.

Even in an impure language I think filter sounds to me like it would return a new list rather than editing in place.

In my experience the ideas of functional programming are things that a lot of people just aren't aware of at all. I know that for me it was about seven years into my journey as a programmer before I started learning about them. Thinking about the people I have and do work with, I could very well see them using filterPromotedPosts to mutate a list of posts. So in that environment, it seems like it'd be nice to make it extra clear that "this function isn't actually mutating anything". (Then again, I could also see them mutating stuff in getPromotedPosts too.)

But in a different environment where the convention of "filter" being pure is strong enough, I agree with you. And I think that it'd often make sense to aspire towards this sort of environment. It's interesting how much the right name depends on this sort of context.

This doesn't quite sound like what you want to do, though, and instead want to insert more nuanced words to make it clearer what work "think" is doing.

Yeah. And also a big part of what I'm trying to propose is some sort of new standard. I just realized I didn't express this in my OP, but I'll express it now. I agree with the problems you're saying, and I think that if we all sort of agreed on this new standard, eg. when you say "I suspect" it means X, then these problems seem like they'd go away.

The other day Improve your Vocabulary: Stop saying VERY! popped up in my YouTube video feed. I was annoyed.

This idea that you shouldn't use the word "very" has always seemed pretentious to me. What value does it add if you say "extremely" or "incredibly" instead? I guess those words have more emphasis and a different connotation, and can be better fits. I think they're probably a good idea sometimes. But other times people just want to use different words in order to sound smart.

I remember there was a time in elementary school when I was working on a paper with a friend. My job was to write it, and his job was to "fix it up and making it sound good". I remember him going in and changing words like "very", that I had used appropriately, to overly dramatic words like "stupendously". And I remember feeling annoyed at the end result of the paper because it sounded pretentious.

Here I want to argue for something similar to "stop saying very" though. I want to argue for "stop saying think".

Consider the following: "I think the restaurant is still open past 8pm". What does that mean? Are you 20% sure? 60%? 90%? Wouldn't it be useful this ambiguity disappeared?

I'm not saying that "I think" is always ambiguous and bad. Sometimes it's relatively clear from the context that you mean 20% sure, not 90%. Eg. "I thhhhhinkkk it's open past 8pm?" But you're not always so lucky. I find myself in situations where I'm not so lucky often enough. And so it seems like a good idea in general to move away from "I think" and closer to something more precise.

I want to follow up with some good guidelines for what words/phrases you can say in various situations to express different degrees of confidence, as well as some other relevant things, but I am struggling to come up with such guidelines. Because of this, I'm writing this as a shortform rather than a regular post. I'd love to see someone else run with this idea and/or propose such guidelines.

Kudos to you for a) thinking about other people and b) having the courage and wisdom to ask this question.

Yup, for sure! I actually really wanted this post to be more general and make these points, but I wasn't able to explain it well or come up with good examples outside of coding. If you or anyone else wants to piggyback off of my post and write a post about the more general point, I'd love to see it!

That's awesome to hear, thank you!

Reminds me of rubber duck debugging!

Thanks for this! It's helpful to hear things framed from a different person's perspective. In particular, the way you explained "complex systems have to be broken into parts, and parts have to be understandable without opening the box".

But there's more on the box than the function's name, and you should make use of all of it, for exactly the reasoning in this post!

Great point! I have to admit, I didn't know that docstrings existed until now. Kinda funny that I wrote this post without knowing what docstrings are. I'm really excited to use them in my next project now.

and their boundary is their (i) name, (ii) doc string, and (iii) type signature.

Actually, one of my crazy ideas is to extend this boundary even further with visuals. (Well, in that post I wasn't necessarily talking about it as part of the "hover over a line of code in a text editor interface", but it could fit there.)

How can you tell if it "does one thing"? Write the module's docs, which should include a high-level overview of the whole module, plus shorter docs for each function in the module.

Ah that makes sense. Sounds like a good forcing function.

I'm sorry you don't have a good naming buddy! Everyone should have a naming buddy; it's so hard to come up with good names on your own.

Yeah. In a perfect world I'd actually do something along the lines of low-fi usability testing with people. But instead of testing whether they understand a UI, testing whether they understand my code.

Hahaha that's perfect!

To piggyback off of gjm's comment, it isn't necessarily true that every function is a get. For example, in JavaScript you could have a function that doesn't return anything and only has a side effect. But even in functional languages, you still need to have side effects at some point if you want your code to do something interesting. I've been following a guy named Eric Normand recently who likes to talk about this, and emphasizes that functional languages are about separating side effects from pure code, not avoiding them. See Why side-effecting is not all bad.

1. The idea that all code inside a function should be written at one level of abstraction lower than its name. This would ensure that every function contains a set of boxes of approximately the same "size", which build up the bigger box of the container function in a way that makes sense. (How do molecules add up to this brick? How do bricks add up to this wall?)

That's a great point with an even more awesome example! Thanks! I'm gonna remember that example.

The lesson I personally got out of this post is that we should be careful in naming concept handles for this same reason.

Yeah. I really wanted to talk more about everyday life and make the post less about code. I just wasn't able to make it work.

Thanks for the explanation here. I didn't know the phrase "command-query separation". It's also helpful to be aware that "pop" is the standard example.

In the present case, to me "getPromotedPosts" feels ambiguous between (1) "tell me which posts are promoted" and (2) "retrieve the promoted posts from somewhere".

I might be in the minority here, but something like promotedPosts feels too much like a variable. It feels awkward to me when the name of a function isn't a verb.

I agree about the ambiguity you point out, and for that reason I don't feel good about the name getPromotedPosts. (Although you could establish a convention where the term "retrieve" or "fetch" is used for database access and "get" is used for situations like this.) I'm just not sure what would be better. I considered filterPromotedPosts, but that kinda sounds like it's impure and is mutating the argument that's passed in. Maybe filterPromotedPosts would be a good name if you're working in a functional language though. It's impossible to do such a mutation in a functional language, so the ambiguity goes away. I think that's an interesting and often overlooked benefit of functional languages.

Ah, this makes a lot of sense. Good examples. In looking at those examples, it does seem clear to me that my original impression about what it means in the context of everyday life was correct.

I see. Thanks for clarifying.

It means "return to(ward)", with the implication that the observed difference from the mean is (partially) transient, so you're returning to a past state.

Do you mean this in the context of statistics, or everyday life? My impression is that in the context of everyday life, it means to move down, but I could be mistaken.

The state of flow seems like a promising one. Lots of good things follow from it.

I assume he meant it as a heuristic. It's hard to weigh hundreds of variables at once, but when you optimize for speed, good things follow from that.

Glad to hear I'm not alone :)

Interesting, thanks for sharing. I really like the way you explained what a paradigm shift is. And the point you make in the It's Not Your Fault section:

On the day you’re implementing the User.numUnreadRooms field, you’ll rack your brain for all the places in your code that will need to update it, and I don’t blame you for overlooking the onDeleteRoom event handler.

On the day you’re implementing the onDeleteRoom event handler, you’ll rack your brain for all the denormalized fields that it might need to update, and I don’t blame you for overlooking the User.numUnreadRooms field.

I don’t blame you, the application developer, for any bug in your denormalization logic. I blame the paradigm of tightly coupling denormalization logic with application code.

I think that it is related to my Don't Feel Bad About Not Knowing Basic Things post. If the "basic thing" you don't understand is also something that plenty of other people don't understand, then maybe it's because it is unnecessarily complicated. (There are other possibilities too of course.)

NodeJS is mostly cool because you can use the same language and the same development tools across your whole stack.

Oh ok that's good to hear. That's always been what felt most appealing about it to me.

When it launched I think another selling point was that it’s reasonably good at handling multiple requests in parallel.

What is it about Node that causes this to be true? I have a feeling it has to do with Node being single-threaded, but that never made sense to me. Being single-threaded seems like it'd be strictly worse than being multi-threaded. Anything you can do on a single-threaded system, you can also do on a multi-threaded system, right? Just don't create a second thread.

I wonder if it has to do with the Christian roots that cousin_it is pointing to below. Other cultures have different attitudes. I recall reading about Viking rituals called Bragas. After a battle, the clan would gather around a table, feast, drink and each warrior would brag mightily about their heroic deeds. If they couldn’t brag well (claim credit), they would be laughed at.

Interesting.

And thank you for your thoughts - after writing this, I came across your post on how “The best frequently don't rise to the top.” It struck me as quite related to this. I’d say that in your own words, you were writing about the delta between merit and credit. Or that’s how I read it.

Yup that's a gret way to put it.

Thanks for bringing this up. I hadn't thought of it but it makes sense.

It's funny, today in my standup meeting, as an icebreaker we were all asked whether we would prefer credit to be given to us in a private chat, or publicly in a big meeting. I was going to make a joke about it being a silly question because it provides no signal: even if you do want the fanfare, you're not going to admit to it. Then a few people did speak up they'd appreciate it being public. And it was in such a way where it didn't sound pretentious or anything.

Anyway, I'm glad you bring this up. I never thought much about it, but after reading your post it's sounding like a topic that is pretty important. People respond to incentives after all, so if we figure out how to attribute more good, we can probably extract a lot more good.

Haha nope, never used it. Doesn't LessWrong currently do this by highlighting new posts and comments with a green sidebar?

Regardless, my feeling is that ease of discovering of new posts/replies isn't the issue.

Makes sense.

To contribute my data point, it's something that I could definitely see myself doing, but not at this stage of my life because I have other time commitments. Hm, maybe this is worth exploring more. I suspect a lot of people would give this response. But why not just devote eg. two hours/week to it? I guess because it feels like that'd be too "diluted", and because I worry about my ability to do time management well. I already struggle to get to all the things I want to get to, so I probably wouldn't be able to get to a new thing. Maybe I would if there was some sort of time management hack though, like precommitment or something.

The proposed rules seem reasonable. However, it seems like the sort of thing where it's hard to get them right upfront and thus would be good to have an attitude of "this is a starting point but we'll iterate".

Yeah I agree with this idea of response posts now as well (I started off not agreeing with it). And that makes sense about it not making the cut as a feature. The current functionality seems to already support it pretty well.

Gotcha, I agree.

I see, that makes sense. That 10-50% range does seem huge to me also, but I think it's cool :)

I think the first question that needs to be explored here is why they are not already doing something like this already.

Ah, great point. Seems obvious in retrospect, but it's always good to talk to users. I agree that that would make sense as the first step.

Yeah those frames all make sense. And I like the idea of a follow up post summarizing the takeaways from the comment section, as well as giving the process a name.

Gotcha. Maybe it'd be a good idea to display how many people are currently subscribed to a post.

Maybe there’s a way to briefly acknowledge that the comment has been seen and considered, however.

Emoji replies come to mind. Although 1) I feel like there's something refreshing about them not being a thing on LessWrong and 2) I think it can be assumed that comments have been seen and considered.

Yeah, this sounds like a book club, except where the participants are also the authors.

I like that analogy.

This is part of why I've been posting a lot of questions lately - my stab at catalyzing conversation that people feel open to participating in.

Yeah I like that idea.

The fact is that we see a lot more idea posts than metaconversation posts on LW. By contrast, in my closest relationships, a huge proportion of the conversation is metaconversational. It's about exploring the nuances of relationships and conversation challenges. Those conversations genuinely lead to baseline improvements and real progress. So it might be that we're just straight-up neglecting something tractable that's critical for generative conversation on LW to thrive.

Huh, interesting. Drawing that connection to your social life makes it feel intuitive to me that we should be doing a lot more of it on LessWrong. Seems like a good topic for a follow up post.

By contrast, in my closest relationships, a huge proportion of the conversation is metaconversational.

Just curious, but if you don't mind sharing, to what extent is this an exaggeration?

This makes perfect sense now, thanks!

One way is trust/personal connection. If you're having a conversation with a friend, you can usually expect they'll respond when you bring up a new topic.

I actually don't get a strong sense that this is true. The handful of people on LessWrong who I'm friends with, I expected that they're slightly more likely to respond to my posts, but not by too much. I expect it to be mostly about whether they are interested in the post and have something to say.

When the amount of effort to engage in an intellectual conversation reaches a certain level, it's worth creating a new post in LessWrong and have a pingback.

Yeah, after some discussion in the comments section I now agree with this.

Writing a comment the day after a post is posted gets significantly more reponses then a week afterwards even when the post is still on the frontpage.

Good point, I agree. I actually did have this in mind but found it easier to just talk about "frontpage". In retrospect, maybe that was a bad idea.

Instead of using the frontpage I think it would be better to use notifactions more. Currently, "subscribe to comments" is hidden behind a hamburger menu and thus seldomly used. If more people would use "subscribe to comments" we likely would get more long-running discussions in the comments.

Huh, I always imagined that being subscribed is the default and that most people are subscribed. Regardless, I think that what AllAmericanBreakfast is saying here is important, and with what you propose with notifications, Alice wouldn't realize that Bob is subscribed to comments.

Thanks for contributing these examples!

For sure!

Yeah, good point. gjm made that point too and I agree. It's a practical thing that I think would actually be a big barrier.

When I look at the curated posts, I don't have the sense of "this post will stay here for a very long time and continue to receive comments". I think to myself, "this very well might be removed tomorrow and replaced with something else". So what I envision with the Ongoing Discussions section is to make it clear that it will stay there for a long time and that the intent is to have long running discussions. However, after discussion here, I think it would be important for a cultural shift to happen before launching such a feature. (Well, it might still be worth launching as an experiment, because the bar for experiments is low.)

Hm, I'm finding it difficult to think in the abstract about the question of "extended discussion in the comments section vs having a follow up post". I feel like it's the sort of thing where it's easier to think about a concrete example. Fortunately, I just came across one!

At this point in my conversation with bendini, I agreed with their point about a shift in cultural norms needing to come before any UI changes. I feel like this would be a good time to continue via a follow up post. However, before reaching this point, I think the back and forth discussion in the comments section worked well. I sense that in practice, using your judgement for this question of comment section vs follow up post would work out well.

But more to the point, I think my original idea of having these crazy month long discussions via the comments section is probably wrong. It'd probably make sense to continue via a follow up post before the discussion gets that long. Maybe not 100% of the time, but most of the time.

Writing top-level posts can be intimidating, and can be a lot of work. (They can be intimidating because they're a lot of work -- one feels daunted at the prospect. They can be a lot of work because they're intimidating -- fear of writing something unsatisfactory motivates research and polishing. This parenthesis is really just for fun.) Perhaps there's space for something intermediate between a comment and a post, somehow, for exactly this situation? But I'm not sure what it would be, how it would work, or whether it would actually end up feeling like something intermediate.

This is a great point. I agree that this is an important barrier. I think the LW team has tried to address this with the concepts of personal blog posts having a low bar, and then also with shortform posts. And in some sense, with the concept of asking a question too. However, piggybacking off of bendini, I think that the real crux of the problem is social/cultural shifts, not UI shifts.

But it seems to me that quickfire back-and-forth of the sort that's better staying in comments is seldom productive when extended beyond (say) a week, both because purely mechanically it becomes difficult and unpleasant to follow in a nested comment-thread setup

Agreed. This is an important practical consideration that I overlooked. Thanks for bringing it up.

and also because quick back-and-forth comments are mostly about what you might call "easy" responses:

I think I am more bullish than you about back-and-forth comments being useful/productive, but I don't see it as an important point to discuss further, because big picture I agree that after however many days, it'll usually make sense to continue the discussion by writing up a new post.

For things to actually change, I predict that we'd first need a widespread perception that this behaviour is a problem, then have various UI nudges put in place. The only way you'd get the desired behaviour change without that consensus is if the UI went beyond nudging and aggressively pushed it as the default.

My apologies if I was being dense or if I was misunderstanding you before, but in reading this now, I agree and think it makes a lot of sense. So then, I think the question becomes much more social than technical. It's not about how to design the UI, it's about evolving cultural norms.

I suppose a good starting point there would be to have a post talk in more detail about why this would be a good thing (I didn't really do that in this post). From there, maybe the next step would be if you started to see post authors do things like making pledges or holding office hours.

Good points, I agree with them all.

And speaking of switching between modes, before writing this comment I took a break to watch Frank Caliendo impersonate Charles Barkley on YouTube. That's low class enough where we might need a new category beneath Average Joe.

Interesting. I wouldn't expect ordering by the latest reply to have such a strong effect.

My wild guess is that, yes, "instant gratification" is important to engage people better.

Thanks for the data point. (Not sarcastic, I really do appreciate these sorts of data point comments.)

There was a recent discussion on how to do that, but it fizzled.

Oh the irony :)

Hm, very good point. Now that you mention it, I feel like in the real world, long running conversations are usually oral, not written. If true, that probably points pretty strongly away from my idea of encouraging them to happen via writing. Personally I really like having them via writing because I find it easier to keep things organized, but my personal preference isn't relevant here, it's the aggregate preference of the community that matters.

I wonder what it'd look like for LessWrong to encourage/support such continued oral conversations. Maybe something similar to my pledging idea, where people can express interest in an extended oral conversation. Maybe "office hours" where you can hang out in a Discord channel or something (for a predetermined duration of time?).

That makes sense. I don't really have any experience in this area so take this with a grain of salt, but here are some things that come to my mind.

• Cruxes. The participants continue to identify cruxes and work towards addressing them. On the other hand, I guess you can refer to the opposite of that as "talking past each other". That is a red flag.
• Expected value and sunk costs. If the conversation is no longer the most productive one to be having, it probably makes sense to move on. (Caveat is that impulsiveness might make people want to move on too early.)
• Not updating fast enough. Ie. what Eliezer talks about in Science and Rationality. Scientists update too slowly, and this could lead to a should-have-stopped-already situation.

I'm not sure what this would mean in terms of designing LessWrong to encourage more long running conversations. Perhaps it could automatically prompt the participants with these sorts of questions. "You two have been going at this for a while. Have you been successfully identifying cruxes?" This reminds me of linters that automatically do code review comments in the world of software.

Yeah I agree that they happen sometimes. I guess my point is moreso that the frequency is very low.