Less Wrong is a community blog devoted to refining the art of human rationality. Please visit our About page for more information.

Idea for LessWrong: Video Tutoring

10 adamzerner 23 June 2017 09:40PM

Idea: we coordinate to teach each other things via video chat.

  • We (mostly) all like learning. Whether it be for fun, curiosity, a stepping stone towards our goals.
  • My intuition is that there's a lot of us who also enjoy teaching. I do, personally.
  • Enjoyment aside, teaching is a good way of solidifying ones knowledge.
  • Perhaps there would be positive unintended consequences. Eg. socially.
  • Why video? a) I assume that medium is better for education than simply text. b) Social and motivational benefits, maybe. A downside to video is that some may find it intimidating.
  • It may be nice to evolve this into a group project where we iteratively figure out how to do a really good job teaching certain topics.
  • I see the main value in personalization, as opposed to passive lectures/seminars. Those already exist, and are plentiful for most topics. What isn't easily accessible is personalization. With that said, I figure it'd make sense to have about 5 learners per teacher.

So, this seems like something that would be mutually beneficial. To get started, we'd need:

  1. A place to do this. No problem: there's Hangouts, Skype, https://talky.io/, etc.
  2. To coordinate topics and times.

Personally, I'm not sure how much I can offer as far as doing the teaching. I worked as a web developer for 1.5 years and have been teaching myself computer science. I could be helpful to those unfamiliar with those fields, but probably not too much help for those already in the field and looking to grow. But I'm interested in learning about lots of things!

Perhaps a good place to start would be to record in some spreadsheet, a) people who want to teach, b) what topics, and c) who is interested in being a Learner. Getting more specific about who wants to learn what may be overkill, as we all seem to have roughly similar interests. Or maybe it isn't.

If you're interested in being a Learner or a Teacher, please add yourself to this spreadsheet.

Comment author: Lumifer 10 June 2017 07:33:13PM *  2 points [-]

Counterpoint: do you understand the magnitude of how bad it would be if there was a fire and you ended up getting seriously injured or dying?

You continue to live in the apartment building which already had two fires and which has a malfunctioning alarm system.

Comment author: adamzerner 11 June 2017 04:59:12PM 0 points [-]

I don't. I'm not scope sensitive. The alarm system is working fine, it's just that it's sensitive to people who are cooking (I think). I'm eager to move out ASAP though.

In response to Scope Insensitivity
Comment author: adamzerner 10 June 2017 12:14:33AM *  0 points [-]

Real world example: the fire alarm goes off in my apartment building at night about once every two weeks. Many people decide to stay in their room, as opposed to evacuating the building. They aren't understanding the magnitude of how bad it would be if there was a fire and they ended up getting seriously injured or dying. (There have been two real fires so far; the chance of a real fire is not trivial)

Comment author: John_Maxwell_IV 30 May 2017 04:20:10AM *  0 points [-]

My first thought was, "what if that project got lots of traction, and you didn't have the technical skills to continue iterating fast enough?

How many startups do you know of that failed this way?

Twitter and reddit both survived despite major performance issues. And social media has quite low profit per HTTP request served relative to other web businesses. So I'd expect scaling to be much less of an issue if your startup is almost any other area. I also suspect that this kind of scaling failure is becoming rarer and rarer as the skills, resources, and technology to scale up a website get commoditized.

it may be worth it for that person to take some time building up a reasonable foundation of networking, databases, operating systems, algorithms and whatnot before taking the "learn by doing" approach

Apparently that kind of "foundational" knowledge gets forgotten after people graduate from college because it doesn't really get used: http://blog.triplebyte.com/bootcamps-vs-college I think a lot of this stuff functions partially as a way to signal intelligence. Although I'll grant that CS degrees are not as bad in this regard as most degrees are.

A compromise approach: If you are running in to a tricky issue with your database, give yourself time to study enough about databases so you have a decent mental model of what's going on under the hood so you can fix the problem. ("Just-in-time learning")

If you're worried about not knowing that a particular CS subfield is relevant to a problem your startup is facing, you could try Steve Yegge's breadth-first learning philosophy: http://steve-yegge.blogspot.in/2006/03/math-for-programmers.html Not all CS subfields are worth learning for this reason though. I think this justification doesn't really work for networking, databases, or operating systems. It might work for algorithms or artificial intelligence. However, I think it's a pretty weak justification overall. I still think diving in is a superior path.

If you have an inherent desire to learn more CS for some reason, you could deliberately pick a project that will require you to pick up some CS knowledge along the way. This will also look better on your resume (since it signals intelligence). It also creates a bit of a barrier to entry for competitors.

Comment author: adamzerner 31 May 2017 12:40:30AM 0 points [-]

As for your points on learning by doing, I'm not sure what to think, but I appreciate and value them. I'm someone who tends towards textbooks and classes, but I've been slowly turning towards learning by doing. Both in theory, and in practice (ie. my life). At some point I plan on thinking about this question more thoroughly, and posting on LW about it. As for the question posed in this post, it's on the condition that learning by doing is not the most effective method (which may or may not be a correct premise, at least in my eyes).

Comment author: John_Maxwell_IV 30 May 2017 04:20:10AM *  0 points [-]

My first thought was, "what if that project got lots of traction, and you didn't have the technical skills to continue iterating fast enough?

How many startups do you know of that failed this way?

Twitter and reddit both survived despite major performance issues. And social media has quite low profit per HTTP request served relative to other web businesses. So I'd expect scaling to be much less of an issue if your startup is almost any other area. I also suspect that this kind of scaling failure is becoming rarer and rarer as the skills, resources, and technology to scale up a website get commoditized.

it may be worth it for that person to take some time building up a reasonable foundation of networking, databases, operating systems, algorithms and whatnot before taking the "learn by doing" approach

Apparently that kind of "foundational" knowledge gets forgotten after people graduate from college because it doesn't really get used: http://blog.triplebyte.com/bootcamps-vs-college I think a lot of this stuff functions partially as a way to signal intelligence. Although I'll grant that CS degrees are not as bad in this regard as most degrees are.

A compromise approach: If you are running in to a tricky issue with your database, give yourself time to study enough about databases so you have a decent mental model of what's going on under the hood so you can fix the problem. ("Just-in-time learning")

If you're worried about not knowing that a particular CS subfield is relevant to a problem your startup is facing, you could try Steve Yegge's breadth-first learning philosophy: http://steve-yegge.blogspot.in/2006/03/math-for-programmers.html Not all CS subfields are worth learning for this reason though. I think this justification doesn't really work for networking, databases, or operating systems. It might work for algorithms or artificial intelligence. However, I think it's a pretty weak justification overall. I still think diving in is a superior path.

If you have an inherent desire to learn more CS for some reason, you could deliberately pick a project that will require you to pick up some CS knowledge along the way. This will also look better on your resume (since it signals intelligence). It also creates a bit of a barrier to entry for competitors.

Comment author: adamzerner 30 May 2017 07:46:23PM *  0 points [-]

How many startups do you know of that failed this way?

I don't necessarily mean scaling, I mean iterating on product as well, because even with lots of traction, you still need to iterate on product, I assume. I base this on hearing advice from YC and the likes on the importance of continuously talking to customers and iterating, although I personally am not aware of enough data on startups to draw the conclusion strongly myself. The advice of YC may be wrong. And I may be misinterpreting it. What do you think?

Comment author: John_Maxwell_IV 27 May 2017 06:51:25AM 5 points [-]

How about choosing a project that's too small & inconsequential to be called a "startup" (Paul Graham has indicated that he thinks these can be some of the best startup ideas anyway) and use it as a test case to improve your programming skills? (The advantage of choosing something small & inconsequential is that you can get a quick, small win in order to build a success spiral for later attempts at big startup projects. Bonus points if your quick, small win could lead to a series of slower, bigger wins, e.g. in the case where your small & inconsequential project gets you some sort of audience or gives you some firsthand knowledge of how a particular industry works.)

Comment author: adamzerner 29 May 2017 08:19:09PM *  0 points [-]

My first thought was, "what if that project got lots of traction, and you didn't have the technical skills to continue iterating fast enough?". But I suppose that's a pretty good problem to have - you may find that you in fact can iterate fast enough, you may find it worthwhile to find and work with someone who could help you, and you'll probably learn a lot about users/startups/projects.

The downside I see is that working on a project may not be the best way to develop technical skills. For example, consider a front-end developer with almost no CS background - it may be worth it for that person to take some time building up a reasonable foundation of networking, databases, operating systems, algorithms and whatnot before taking the "learn by doing" approach. In the scenario where "learn by doing" is in fact the most effective way to develop technical skills, then it does seem to be a win-win situation. But in the scenario where it isn't, I think the downside of slower learning needs to be balanced against the upsides of a) potential success, b) learning about startups/users, and c) potential confidence stemming from a success spiral in the case where the smaller project is successful. I'm not sure what to think about this balance.

Develop skills, or "dive in" and start a startup?

1 adamzerner 26 May 2017 06:07PM

Technical skills

There seems to be evidence that programmer productivity varies by at least an order of magnitude. My subjective sense is that I personally can become a lot more productive.

Conventional wisdom says that it's important to build and iterate quickly. Technical skills (amongst other things) are necessary if you want to build and iterate quickly. So then, it seems worthwhile to develop your technical skills before pursuing a startup. To what extent is this true?

Domain expertise

Furthermore, domain expertise seems to be important:

You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally.

I've wondered about that passage since I read it in high school. I'm not sure how useful his advice is for painting specifically, but it fits this situation well. Empirically, the way to have good startup ideas is to become the sort of person who has them.

- http://www.paulgraham.com/startupideas.html

The second counterintuitive point is that it's not that important to know a lot about startups. The way to succeed in a startup is not to be an expert on startups, but to be an expert on your users and the problem you're solving for them.

- http://www.paulgraham.com/before.html

So one guaranteed way to turn your mind into the type that has good startup ideas is to get yourself to the leading edge of some technology—to cause yourself, as Paul Buchheit put it, to "live in the future."

- http://www.paulgraham.com/before.html

So then, if your goal is to start a successful startup, how much time should you spend developing some sort of domain expertise before diving in?

Comment author: RomeoStevens 03 May 2017 06:19:01PM *  12 points [-]

Having spent years thinking about this and having the opportunity to talk with open minded, intelligent, successful people in social groups, extended family etc. I concluded that most explicit discussion of the value of inquiring into values and methods (scope sensitivity and epistemological rigor being two of the major threads of what applied rationality looks like) just works incredibly rarely, and only then if there is strong existing interest.

Taking ideas seriously and trusting your own reasoning methods as a filter is a dangerous, high variance move that most people are correct to shy away from. My impression of the appeal of LW retrospectively is that it (on average) attracted people who were or are under performing relative to g (this applies to myself). When you are losing you increase variance. When you are winning you decrease it.

I eventually realized that what I was really communicating to people's system 1 was something like "Hey, you know those methods of judgment like proxy measures of legitimacy and mimesis that have granted you a life you like and that you want to remain stable? Those are bullshit, throw them away and start using these new methods of judgment advocated by a bunch of people who aren't leading lives resembling the one you are optimizing for."

This has not resulted in many sales. It is unrealistic to expect to convert a significant fraction of the tribe to shamanism.

Comment author: adamzerner 03 May 2017 07:51:53PM 1 point [-]

As for the comment that it's difficult to get people to be interested, that seems very true to me, and it's good to get the data of your vast experience with this.

A separate question is how we can best attempt to get people to be interested. You commented on the failure you experienced with the "throw your techniques away, these ones are better" approach. That seems like a good point. I sense that my message takes that approach too strongly and could be improved.

I'm interested in hearing about anything you've found to be particularly effective.

Comment author: eternal_neophyte 03 May 2017 05:58:54PM 0 points [-]

Hate to have to say this but directly addressing a concern is social confirmation of a form that the concern deserves to be addressed, and thus that it's based in something real. Imagine a Scientologist offering to explain to you why Scientology isn't a cult.

Of the people I know of who are outright hostile to LW, it's mostly because of basilisks and polyamory and other things that make LW both an easy and a fun target for derision. And we can't exactly say that those things don't exist.

Comment author: adamzerner 03 May 2017 06:29:36PM *  0 points [-]

Hate to have to say this but directly addressing a concern is social confirmation of a form that the concern deserves to be addressed, and thus that it's based in something real.

I could see some people responding that way. But I could see others responding with, "oh, ok - that makes sense". Or maybe, "hm, I can't tell whether this is legit - let me look into it further". There are lots of citations and references in the LessWrong writings, so it's hard to argue with the fact that it's heavily based off of existing science.

Still, there is the risk of some people just responding with, "Jeez, this guy is getting defensive already. I'm skeptical. This LessWrong stuff is not for me." I see that directly addressing a concern can signal bad things and cause this reaction, but for whatever reason, my brain is producing a feeling that this sort of reaction will be the minority in this context (in other contexts, I could see the pattern being more harmful). I'm starting to feel less confident in that, though. I have to be careful not to Typical Mind here. I have an issue with Typical Minding too much, and know I need to look out for it.

The good thing is that user research could totally answer this question. Maybe that'd be a good activity for a meet-up group or something. Maybe I'll give it a go.

Comment author: eternal_neophyte 03 May 2017 05:36:29PM 1 point [-]

Thank you for being gracious about accepting the criticism.

Comment author: adamzerner 03 May 2017 05:57:32PM 0 points [-]

:)

View more: Next