Learn In Public
The fastest way to learn
Translations welcome! (한국어, 日本語, Español 1, 中文, Español 2, Español 3, 中文, 中文 2, Português 1, Português 2 Português 3, Deutsch, Français, فارسی, हिंदी. Add yours here!)
If there’s a golden rule, it’s this one, so I put it first. All the other rules are more or less elaborations of this rule.
You already know that you will never be done learning. But most people “learn in private”, and lurk. They consume content without creating any themselves. Again, that’s fine, but we’re here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust:
- Write blogs and tutorials and cheatsheets.
- Speak at meetups and conferences.
- Ask and answer things on Stackoverflow or Reddit. Avoid the walled gardens like Slack and Discord, they’re not public.
- Make Youtube videos or Twitch streams.
- Start a newsletter.
- Draw cartoons (people loooove cartoons!).
Whatever your thing is, make the thing you wish you had found when you were learning. Don’t judge your results by “claps” or retweets or stars or upvotes - just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.
Guess what? It’s not about reaching as many people as possible with your content. If you can do that, great, remember me when you’re famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that’s icing.
Oh you think you’re done? Don’t stop there:
- Enjoyed a coding video? Reach out to the speaker/instructor and thank them, and ask questions.
- Make PR’s to libraries you use.
- Make your own libraries no one will ever use.
- Clone stuff you like, from scratch, to see how they work.
- Teach workshops.
- Go to conferences and summarize what you learned.
If you’re tired of creating one-off things, start building a persistent knowledge base that grows over time. Open Source your Knowledge! At every step of the way: Document what you did and the problems you solved.
The subheading under this rule would be: Try your best to be right, but don’t worry when you’re wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You’re pushing yourself. Don’t assume you know everything, but try your best anyway, and let the internet correct you when you are inevitably wrong. Wear your noobyness on your sleeve.
People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. Of course, if they get abusive block them.
Did I mention that teaching is the best way to learn? Talk while you code. It can be stressful and I haven’t done it all that much but my best technical interviews have been where I ended up talking like I teach instead of desperately trying to prove myself. We’re animals, we’re attracted to confidence and can smell desperation.
At some point you’ll get some support behind you. People notice genuine learners. They’ll want to help you. Don’t tell them, but they just became your mentors. This is very important: Pick up what they put down. Think of them as offering up quests for you to complete. When they say “Anyone willing to help with __ __?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.
“With so many junior devs out there, why will they help me?”, you ask.
Because you learn in public. By teaching you, they teach many. You amplify them. You have one thing they don’t: a beginner’s mind. You see how this works?
At some point people will start asking you for help because of all the stuff you put out. 80% of developers are “dark”, they dont write or speak or participate in public tech discourse. But you do. You must be an expert, right? Don’t tell them you aren’t. Answer best as you can, and when you’re stuck or wrong pass it up to your mentors.
Eventually you run out of mentors, and just solve things on your own. You’re still putting out content though. You see how this works?
Learn in public.
p.s. Eventually, they’ll want to pay you for your help too. A lot more than you think.
Author’s Note: I have written an expanded version of this essay and its related canon (below) in The Coding Career Handbook.
Read this next: The Ultimate Hack for Learning In Public (expanding on “Pick Up What They Put Down”)
- Then learn about Learning Gears
- Not everything must be public: How To Learn In Private
- A mathematical intuition for why LIP works: Big L Notation
- Learn how to turn ignorance to power: The Power of Lampshading
This essay was originally drafted in a gist and republished in Letters to a New Developer.
I continue to talk about it on podcasts even in 2022 - see the live updating list here: https://www.swyx.io/ideas/?filter=learn%20in%20public
Related links
-
Patio11: Do not end the week with nothing
-
Chris Coyier: Showing up and Persistence and Working in Public
-
Cory House: Becoming an Outlier and The Art of Learning and Lifestyle Systems and The 7 Pillar Developer
-
Jeff Atwood: How to stop sucking and be awesome instead
-
Rachel Thomas: Why You (yes, you!) Should Blog
-
Kent C Dodds: Intentional Career Building
-
Julia Evans: Blog about what you’ve struggled with
-
Joshua Branchaud: Learning In Public by posting daily TIL’s for 5 years
-
Patrick O’Shaughnessy: Learn, Build, Share, Repeat
Learn in public, fanatically. Find something you can’t stop thinking about and know it better than anyone, and share everything you learn along the way. Once deep enough, start building something too. Make something you have to sell as early as possible. - Patrick in David Perell’s Twitter course
-
LadyBug Podcast: Blogging 101 (esp Ali Spittel’s Blog Post Workflow)
-
GitHub ReadME project: Publishing your work increases your luck (see HN comments)
-
Quincy Larson: Build your Skills, Build your Reputation, Build your Network
-
Ali Spittel on syndicating content on the Arrested DevOps podcast
-
Reid Hoffman: Those Who Teach, Can Do
-
Shu Omi did LIP on YouTube and gained 5k subscribers in 8 months!
-
Kei Watanabe: https://twitter.com/rainar_angelo/status/1519530337285869568
-
Gift Egwuenu on Learning in Public
-
How do Rocket Scientists Learn? (Knowledge Management Lessons learned at Goddard, NASA)
In some places, Knowledge Management is about creating systems that get around people’s knowledge deficiencies. At Goddard, it really seems like it is about empowering people to share and reflect on what they know best. It’s a subtle distinction, but I really like that they put people in the center of this work, and start from a place of abundant knowledge in people rather than a lack of information in systems. Social media has a lot of potential, but you need to think about how to facilitate different kinds of (online and offline) relationships between people so that their thinking is improved, innovation occurs, they can get quick answers to complex problems, in order to enhance and accelerate business outcomes. One of the great benefits of using social media as a KM tool is that you are creating and capturing the knowledge at the same time. However, in order for this to truly work people have to be willing to collaborate in the open throughout the project lifecycle. “Learning in Public” is scary for many reasons – people can find and cling to outdated information and users are exposing their knowledge during a vulnerable time in the project (i.e. when they don’t yet have all the answers). However, during this part of the process is when learning can be most valuable. If you share what you know and what you don’t know in the middle of a project, you give people an opportunity to share specific knowledge that can help you in the moment. If it works, this can help save time and money.
- Nathan Barry in his book Authority:
Back in 2007 Chris Coyier launched a site called css-tricks.com. It was a site dedi- cated to teaching people how to code websites. (CSS is the language that describes how websites should look.) When CSS-Tricks first came out I remember reading a tutorial and arrogantly thinking, “I know that already.” Chris and I were at about the same skill level, so I didn’t learn anything new from him. This continued for a while as he kept putting out new tutorials. But over time, as friends started asking me CSS questions, I found it easier to link to one of Chris’s articles (since they were really well written) than explain everything myself. Years later Chris ran a Kickstarter campaign to redesign his site. Those who con- tributed would get behind-the-scenes access to additional tutorials and content re- lated to the redesign. The goal was set fairly low at $3,500. He quickly blew past the goal and by the end of the campaign had raised $89,697. Incredible. The point is that he did it with relative ease, all because he had built up an audi- ence who loved his work. He and I started at the same point and our skills progressed at about the same rate. The difference was that he taught and shared, whereas I kept what I was learning to myself. That made the difference between being able to make tens of thousands of dollars on a new project versus releasing to no one.
Nathan in general has a lot of riffs on LIP:
