1. It's scary because although there's all that blood flow restriction, sitting doesn't feel harmful. There seems to be a pretty big difference between perceived harm and real harm (you don't perceive any harm here, but there is harm). The body is usually pretty good at detecting harm though, so I sort of suspect that the reduction in blood flow isn't as big a deal as it seems, but this is just a hunch.

2. Interruptions are a big deal because they interrupt flow. Having to take a 5 minute walk every hour doesn't seem that bad, and short breaks help focus anyway, but I just thought I'd note this

I've sometimes been in the habit of talking into my phone, which conveniently removes the social stigma as long as no one is close enough to hear what you're saying. Taking walks helps. You can either record yourself or not—I find that talking into an inert phone feels awkward while recording myself makes me feel a little self-conscious. I never did find a method I was completely comfortable with, which might be why I don't do it anymore.

Anyway, I'm generally a fan of self-talk / private speech. I think it's a good way to put your thoughts through a BS detector, or at least so goes my theory: since you're hearing the words aloud you interpret the message as if someone else were saying it and so you hold it to a higher standard.

The hows and whys of refactoring and DRY. How and why to achieve proper separation of concerns (I still have lots to learn there).

Social protocols, especially around initiating and maintaining friendships and other levels of relationships. Being empathetic.

While it's probably justified to correct for the sampling bias in prevalence statistics, it's worth pointing out that sexual partners are not sampled uniformly: the prevalence of a given STD will potentially be higher in the population of likely partners than in the general population.

This sort of optimization is a pretty foundational concept for software engineers. These are things that have helped my career as a software engineer and made me more effective in my job (not exactly the same thing, but related!):

Basics

• Touch typing. This should go without saying, but I've worked with people who hunt and peck and it's painful to watch. But you don't have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.

More Advanced Mechanics

• Gain fluency in a powerful shell, a good text editor, and an expressive "scripting" language
• Learn a modern version control system such as git
• Set up an environment that works for you and keep improving it – this is very much along the lines of Nick5a1's systems mindset. Keep your dotfiles in version control.
• Don't repeat yourself. Learn to refactor code to remove unnecessary duplication.
• Keep configuration decisions out of code
• Understand dependencies among different pieces of code and know a few strategies for simplifying them (the pub/sub or event bus pattern, dependency injection, etc.)
• Know how to deal with asynchronous operations using both callbacks and promises – NodeSchool has a great tutorial for server-side JavaScript.

Soft Skills

• Keep a todo list (I keep my own, or you can get really good with your issue tracker)
• Keep a log of things you've done (bonus if you can generate the log automatically from your todo list)
• Keep notes on how you solved tricky problems
• Understand your role (you're not a designer or product manager, but you need to know what they care about to work with them effectively)
• prioritize the product, then others' goals, then your own (this is usually the most effective way of furthering your goals)
• insist on regular one-on-one meetings with your manager
• before answering a question find out why the question was asked

Touch typing. This should go without saying, but I've worked with people who hunt and peck and it's painful to watch. But you don't have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.

I don't touch type, and my typing speed is about 65 wpm. Do you think learning how to touch type will result in a significant increase in speed, enough to be worth the effort?

I'm an academic, so typing speed is probably not as important for me as it is for a software designer, but I do a lot of writing, so it is a potentially significant productivity boost.

This sort of optimization is a pretty foundational concept for software engineers. These are things that have helped my career as a software engineer and made me more effective in my job (not exactly the same thing, but related!):

Basics

• Touch typing. This should go without saying, but I've worked with people who hunt and peck and it's painful to watch. But you don't have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.

More Advanced Mechanics

• Gain fluency in a powerful shell, a good text editor, and an expressive "scripting" language
• Learn a modern version control system such as git
• Set up an environment that works for you and keep improving it – this is very much along the lines of Nick5a1's systems mindset. Keep your dotfiles in version control.
• Don't repeat yourself. Learn to refactor code to remove unnecessary duplication.
• Keep configuration decisions out of code
• Understand dependencies among different pieces of code and know a few strategies for simplifying them (the pub/sub or event bus pattern, dependency injection, etc.)
• Know how to deal with asynchronous operations using both callbacks and promises – NodeSchool has a great tutorial for server-side JavaScript.

Soft Skills

• Keep a todo list (I keep my own, or you can get really good with your issue tracker)
• Keep a log of things you've done (bonus if you can generate the log automatically from your todo list)
• Keep notes on how you solved tricky problems
• Understand your role (you're not a designer or product manager, but you need to know what they care about to work with them effectively)
• prioritize the product, then others' goals, then your own (this is usually the most effective way of furthering your goals)
• insist on regular one-on-one meetings with your manager
• before answering a question find out why the question was asked

Proportional giving was designed for people who didn't even necessarily want to be intrinsically motivated to give money (e.g. paying taxes or perhaps tithing to a church). If you want to raise money from such people, proportional donation aligns the incentives much better than threshold.

That said, there are a couple reasons why it's still useful for effective altruists:

• The thing you mentioned about near mode.

• As you get older, you gain more ability to buy utility at good prices: for instance, kids become increasingly expensive as they age.

• It sets a norm that's easier for people to follow. For instance, fewer people would join Giving What We Can if the pledge were "give everything above $X" instead of "give 10% of your income".

• It's more inclusive. Not everyone can give away everything above (e.g.) US$36k. A lot more people can give away 10% of income.

Nevertheless, many effective altruists (e.g. Toby Ord) do practice the fixed-income approach.

Regarding your thought about subtle personality tests: I find the attachment styles model a fairly powerful predictor of personality, and particularly suitable for dating. It seems to me that people fall into one of the four attachment styles quite reliably, it is fairly easy to know which one and the correlates of each style are easy to remember.

The conversation is actually about something completely different: whether you're willing and able to emphasize the positive over the negative aspects of something for her sake, which is an essential skill in any relationship.

That is something the people do have actual conversations about, something that is, indeed, important to consider and a good reason to adopt the practice of emphasising positive things. However, it is not the kind of conversation that SaidAchmiz was talking about unless you read it extremely uncharitably.

There is a rather distinct and obvious difference between emphasizing the positive aspects of something and emphasizing something that does not exist. In fact, choosing to emphasize something to exists entails outright failing to emphasize a positive aspect of the the thing in question. Sometimes that is necessary to do, but doing so does not constitute a converstation of the type you describe.

Your reply has distinct "straw man" tendencies.