I'm sharing this chatlog because if you feel like you're suppressing/repressing to avoid overreaching, something is going wrong. Don't accept that; there's a problem there. (This is from the Fallible Ideas Discord which you can join.)
Freeze: Does overreaching get in the way of you doing what you want to do, or do your wants mostly follow your understanding of overreaching?
Freeze: One thing I've been thinking about is... If someone learns rationality and reason, does that mean they would rarely if ever desire things that would be overreaching?
Freeze: Is the general regret or disappointment I feel at not being able to discuss interesting topics a symptom of irrational ideas I've learnt?
Freeze: In the sense that if I had learnt rationality better, I would find the simple stuff interesting because I'd know that it's required for the more complex stuff
Freeze: So if I find the grammar boring, it might be a sign that I'm not reasoning well
curi: overreaching isn't about goals but methods. you can work towards SENS/immortality, for example, without overreaching, by taking low error rate steps to work on the project.
Freeze: Right.
Freeze: And as part of a well reasoned process to progress SENS, doing something like analyzing sentences wouldn't feel offtopic. It would feel like part of the topic, if one is rational
curi: managing your error rate is your best chance to succeed at a big, hard project. it doesn't take anything away from you. there isn't a downside.
Freeze: So if I'm feeling bad about it, something's going wrong in my reasoning where it seems like a downside even if I logically know it isn't
curi: sentences are really important and useful and people who don't have enough mastery of that tool ought to work on it, ya
Freeze: Right
Freeze: So I need to learn to convince myself so that I'm wholeheartedly doing things like grammar in a way that it's interesting
curi: dealing with questions is another big tool. i posted to FI about it today
JustinCEO: for me grammar stuff was pretty clearly on topic for various things
JustinCEO: first of all i actually have inherent interest in grammar
JustinCEO: i think it's fun, on its own, without needing to justify it somehow
JustinCEO: but also, i like to write stuff, and am a lawyer, heh
Freeze: When I find discussing epistemology more fun than something like grammar, it seems like I'm operating on bad ideas rather than good ones. I don't know how exactly to go about changing those ideas so that grammar becomes more fun first
curi: yeah i developed some interest in grammar too cuz i've written a lot
curi:
Is the general regret or disappointment I feel at not being able to discuss interesting topics a symptom of irrational ideas I've learnt?
what can't you discuss?
Freeze: I find a lot of things inherently interesting, and I tend to get dragged along by whatever is happening in the moment
Freeze: like pasta discussions or cheese
Freeze: Well some discussions would be overreaching
JustinCEO: i don't think you've gotten crit re: food discussions
curi: i don't think the pasta was a reply to me
Freeze: Although I liked the post someone wrote on FI that said something like, This system is designed so that you should never have to discuss less than you usually do and it involved stuff like labelling overreaching
Freeze: and labelling confident statements
JustinCEO: btw i found food an especially easy topic to learn something about
Freeze: well what I meant by that J is that I don't seem well in control of what I find interesting
curi: yeah cooking with recipes is very learnable field. lots of tutorials and shit.
JustinCEO: one thing that helps is that there are tons of people making detailed instructions which include videos and pictures
Freeze: And it's weird that I can find pasta/cheese inherently interesting sometimes, but not grammar
curi: did you read my essay?
Freeze: Maybe because the grammar becomes this obstacle rather than an inherently interesting topic
curi: ppl have preconceptoins about what grammar is like
Freeze: Only some of it curi, like the first half
JustinCEO: grammar has skool connotation
curi: and my essay is pretty atpyical
JustinCEO: skool is cancer for interests
Freeze: I'll read through it tonight. It seems like when I put something up as a barrier to doing something else, it becomes less interesting
JustinCEO: well if u think of stuff as a barrier
Freeze: like I love vegetables today, but as a kid I disliked them, maybe because they were compulsory or a barrier to eating better tasting food
JustinCEO: that means u are not convinced it is necessary
JustinCEO: to do X well
Freeze: Right, or maybe it means I want to do X poorly
Freeze: for some reason
JustinCEO: so you have some disagreement with ppl saying u should do the thing
JustinCEO: or yeah
JustinCEO: right
JustinCEO: u could want to
JustinCEO: e.g.
Freeze: like maybe I think doing X poorly would be more fun than doing grammar well
JustinCEO: social chit chat
JustinCEO: about
JustinCEO: X
JustinCEO: instead of actually do something meaningful with it, learn about it seriously
JustinCEO: i have that issue
Freeze: It's weird but I seem to find failing at CR discussion more fun than succeeding at grammar discussion. But maybe I should try more grammar discussion since I haven't really had much aside from that one comma splice exchange
Freeze: social chit chat is fun, and feels like learning sometimes
Freeze: like when you talk about food
Freeze: or legal stuff
Freeze: I remember something DD wrote about conversation being one of the best learning methods
Freeze:
One cannot make many such investments in one's life. I should say, of course, that the most educational thing in the world is conversation. That does have the property that it is complex, interactive, and ought to have a low cost, although often between children and adults it has a high cost and high risk for the children, but it should not and need not.
Apart from conversation, all the complex interactive things require a huge initial investment, except video games, and I think video games are a breakthrough in human culture for that reason.
Freeze: https://www.takingchildrenseriously.com/video_games_a_unique_educational_environment
JustinCEO: I think it's important to separate the issue of conversation being a good learning method (it is) from the issue of valuing not-particularly-serious conversation over other ways to spend your time that would actually be more productive/helpful for learning and life
Freeze: I have been excited to read The Goal every night, which was interesting to note and observe in myself
Freeze: The story was cool
JustinCEO: i liked The Goal
Freeze: Reading books sometimes seems like a conversation with the author
JustinCEO: well it's not interactive so that's a difference
JustinCEO: you either have to do a bunch of self-discussion or talk about the book with other knowledgable ppl
Freeze: Right, although I find myself asking a lot of questions of the book, to myself
Freeze: Which is self-discussion I guess
JustinCEO: peikoff knew much more of Rand than is in her books
JustinCEO: and Rand knew more of Rand than is in Peikoff but she dead, and Peikoff dead soon :frowning:
curi: @Freeze re overreaching, whatever you're interested in but don't think you should work on, i suggest you make a project planning tree where you clearly lay out the interest, the things you think it'd take to succeed at it, the prerequisites or components of those and so on down the hierarchy a ways. you will then see specifically 1) what skills, tools, resources, etc. you think you're missing before you do X 2) how those things relate to X, what the chain of connections is. and then you can critically consider it, share it, etc., to maybe find out about errors, alternative learning paths, etc.
curi: if you don't care about something np, but if you have regret or negative feeling, it's worth investigating and getting clear in your mind what you think is in your way and why.
Freeze: ty curi
curi: this works somewhat as an example: https://my.mindnode.com/p3ZX6Py8iVnutKEbf9NSnyocjDs1MMERUdg8Qozk
that + more nodes + label which nodes are done/not-done = much clearer idea of what's standing in the way of building a skyscaper
Here's the FI post about asking questions. Note: you can join the FI email discussion group to read emails like this.
Here's the skyscraper related project planning tree as a PDF permalink.
Messages (3)
he cycle of 'try, fail, learn' should be as small as possible
The essay “Managing Software Developers” has a section with some connections to managing one's error rate.
> # The cycle of 'try, fail, learn' should be as small as possible
> There is a mini-cycle in software development: try, fail, learn. This cycle should be made as small as possible. That means that making pieces which can be used (preferably by someone representative of the end user population), is by far the most preferable route. It is also the one which most developers will want to shy away from, and therefore which management needs to force them into.
Aside from the idea of management “forc[ing]” developers, shrinking the try→fail→learn cycle is related to managing one's error rate.
> Why do most developers shy away from this? Because it is the point at which they discover that they have, to some degree, failed. User testing, even of a small portion, will almost always turn up something which isn't working right. This means someone gets to feel bad about the work that they did. Programmers are, despite all appearances, humans too, and they will tend to shy away from opportunities to feel bad about their work.
From user testing, developers learn that their code fails at its intended purpose. That constitutes criticism. People in general, not just developers, dislike criticism when they are not managing their error rate effectively.
> The quicker such failures are discovered, however, the less painful they are to fix.
Yeah. Maybe people don't realize that, though. When you're overreaching, errors are hard to fix. So people avoid criticism because they can't fix the problems anyway. Maybe they don't realize that if they didn't overreach, they would make fewer errors *and* their errors wouldn't be so hard to fix. So it would make sense for them to dislike criticism *less* in that situation.
> "Try - fail - learn" is a circle which feeds back to "try" again. The more times you go around that cycle, the faster you learn, and the better the software will be. One of the primary tasks of good software management should be to push for more testing (especially user testing), earlier, than the developers are comfortable with. This will often require structuring the software in a way such that smaller pieces can be made in a modular fashion, in order to be tested by users.
Yeah. It's common to need to restructure what you're doing in order to manage your error rate more effectively.
> This is not only a reasonable cost to pay, it is actually a significant improvement in the software architecture for many reasons.
> It is important to note that a programmer testing their own software is NOT a substitute for this. Not because they would lie (rarely would that happen), but because they will not try to use it in the way that your actual users will. What you need, is for each piece to be tested by someone as similar to possible to your real, eventual end users.
In philosophy, too, it's essential for most people to get feedback from others, and not just try to improve their ideas on their own.
Postmortem: typo in post title
#16408
> he cycle of 'try, fail, learn' should be as small as possible
The title was missing a "T" at the beginning.
I copy/pasted the title for the parent comment from the original article, but after I did that, I couldn't see the beginning of what I pasted, and I didn't scroll back with the keyboard to see the beginning. So I didn't notice that I missed part of the title when copying.
When I make an FI post, I see the entire thing, subject and body, before I send. However, when I'm composing a curi.us comment, and the title is sufficiently long, I can't see the whole title sentence at once.
When commenting here on curi.us, I frequently enlarge the comment body textarea by dragging the lower-right corner. That helps me avoid some formatting errors. However, dragging doesn't work for the title field.
I searched for a browser extension that would let me enlarge the title field in some way. I found one for Chrome called resize-input, but, according to the reviews, it doesn't work any more:
> It was an excellent extension, but unfortunately, it appears it has stopped working. (Version 28.0.1500.95 m) It's quite unfortunate as it was the last working extention of it's kind for any browser. The "element inspector" (chrome or ff) is about the only method left, and it's not nearly as convenient as "Resize Input" was.
I tried it myself and couldn't make it work.
As the review suggests, I can resize the title field by changing the "size" attribute in the inspector/developer tools window. I intend to do that in the future, unless I find an easier way.
My policy should be that I need to see everything that I paste. That seems like a wise/safe policy for me to follow in general, not just when commenting on curi.us.
> shrinking the try→fail→learn cycle is related to managing one's error rate.
In a sense, it's more about managing the amount of time spent making errors, not the rate. It doesn't reduce the errors made per time, it shortens the time making the errors before doing correction. So there are fewer errors at once.
This is, in a broad sense, a way of managing error rate. Having phases where one is doing error correction = having phases where one's error rate is low. You're switching your error rate between high and low, and the point here is to do that more frequently instead of having long periods of high error rate.
>> It is important to note that a programmer testing their own software is NOT a substitute for this. Not because they would lie (rarely would that happen), but because they will not try to use it in the way that your actual users will. What you need, is for each piece to be tested by someone as similar to possible to your real, eventual end users.
You want varied types of testing. You want it tested by QA professionals, software devs, management, unit tests and end users.