How To Learn In Private

This is a raw public draft - a full version is now published in The Coding Career Handbook.

I’m known for my advice on Learning in Public. It is easy to assume that I think everybody should put everything in public, or they are Doing Life Wrong.

Of course I don’t think that everything should be public. I don’t even think everyone should Learn In Public, as I have taken great pains to explain in every talk and podcast I do.

The more realistic phrasing of “Learn In Public” is “Learn More In Public”, by which I’m merely saying most people would benefit from going a little more public than “100% Private”, which is the default for the vast majority of people. In practice, this really only means going from 0% Public to maybe 1% or 5% or 10% or 30% Public, so of course the majority of the time you are still learning in private.

So here are some thoughts on how to Learn In Private well.

Improving What Goes In

People over Content: Follow people over content sources. When you come across a quality blog, podcast, or talk, notice the person behind it and follow what else they do. A lot of how content works these days is through aggregators, like Reddit or Hacker News, or an industry blog or podcast or conference, and the quality may vary quite a lot despite the best curation efforts. Titles and upvotes may be gamed for SEO. But a quality person is likely to be quality for life. You already know you are the average of the X people you spend time with - so curate those people. RSS feeds help here.

The expanded form of this is Following the Graph - not only following people, but following the people they follow (the best way to get in their heads), and tracing back work histories and tracing forward new workstreams. Most things are made by only a small set of prime movers and they are usually (by definition) not hard to find.

Read Good Books Cover To Cover: Authors spend a lot of time nailing down details in books because of how permanent it is. They also spend a lot of time organizing the structure and relative weight of the content with some educational goal in mind. If you come across a highly recommended book (or just one that starts off very well), do it the justice of going cover-to-cover. You may get bad chapters or sections, but you won’t know til you plow through it. Particularly pay attention to endings, since people often don’t make it to the end but some authors put The Good Stuff at the end. Usually this is the “unimportant details” that they didn’t want to clutter the introduction with. This is especially relevant if you are Intermediate at whatever you’re doing. Think about it: Beginners need tutorials as they give the shortest path to success, Experts just need to tinker and keep up to date, but Intermediates need context and clear explanation of details. (My Tweets about this)

Read Source Code: People often treat the open source movement as “code that I can use for free”, forgetting the premise that it’s also “code that you can freely fork for your needs”. But we are so spoiled that we even forget that it is “code that you can read to learn from masters”. As Ryan Florence has noted: “I get asked all the time ‘how do I level up?’ Read code. Read lots of code.” It’s simple, but not easy. One of Paul Irish’s early hits was 10 Things I Learned from the jQuery Source (followed by 11 more things) - granted, this was a public talk, but it could easily be private learning. I curate the list of open source React Project Ideas on /r/reactjs for this reason.

Subscribe to Repos and Issues: Just like there is a metalanguage behind the language, behind the code, there is metacode - discussions and attempts on Github Repos and Issues by collaborators, all in the open. If Reading Source Code is reading code-frozen-in-time, then subscribing to repos and issues is reading code-in-motion. Since a developer’s job is very evidently to put code-in-motion, learning how to do this by watching others is a great idea.

Getting More Out of What Goes In

Have a Goal: You will go further if you put more effort learning one thing than to diffuse your efforts learning random assortments of things. You even gain the superpower of having the permission to ignore things if they’re not on-goal for now - you can always come back later if your goals change.

I do believe that Systems are more important than Goals. This whole thing you’re reading is a proto-System. But Systems can be focused by Goals. Sometimes you can stuff a system into a goal - Ultralearning seems to have caught some fire recently as a form of super intense, immersive learning. Joe summarizes it as such: “Set a goal to experiment say with a new technology for 31 days. Check it out. See what you think. Write down what you learn.”

Note: I’m not saying you have to have a goal at all times. Sometimes undirected learning is fun, and nice, and leads to serendipity.

Take Notes: A syllogism:

• There’s no point learning anything if you can’t recall it - or rather, the more you can recall, the more you actually learned
• There is a natural limit on how much you can recall at any time
• So you must take notes to learn more than your brain can hold

This is currently in vogue as Building a Second Brain, but it should be no surprise that “Personal Knowledge Management” is a key life habit for knowledge workers. It’s not a fad, it’s something professionals have always learned to do to get good.

I have a bias toward digital notes, because search is a superpower. But search is no substitute for organization, which at its base form is a tagging system, but at its best is a “minimum spanning taxonomy” of the subject matter.

For the same amount of content stored, an organized mind will perform far superior to a disorganized one.

Spaced Repetition: Of course you can also just try to increase how much you can recall. Michael Nielsen is famous for making very bombastic claims about the capacity of Long Term Memory, but the basic principle is sound: use spaced repetition learning. Anki is the leader here. I’ll be honest, I don’t do this much. In a way, having a daily habit of pursuing the same topic, and making sure to take searchable notes leads you toward spaced reptition anyway - but of course, I could always do a better job of this because I often have to recall things on the spot in interviews and workshops.

Deliberate Practice: A lot has been made of Gladwell’s popularization of the 10,000 hour rule, but it is undisputed that you grow the most when you practice at the edge of your abilities rather than the stuff you already know. Enough said? Enough said. However I wanted to highlight 2 specific ways to home in the exact limits of your ability:

• Pick Up What They Put Down: I have called this the Ultimate Hack for Learning in Public, but of course you can also do this in private. Follow up on anything and everything your unknowing mentor says is good, or is yet to be done, or straight up just replicate their work. Which leads to…
• The Ben Franklin Method: I’ve read this before, but was recently reminded by Mike White. The “Ben Franklin” method is shorthand for a Dissect and Reconstruct process for training yourself to notice differences in quality between your output and your input. This is why you think your work sucks - your tastes have zoomed far ahead of your abilities. Ira Glass calls this The Gap. The Ben Franklin method is a feedback loop for Closing The Gap.
  • The Feynman technique is a similar framing of this, which is more self oriented rather than focused on replicating techniques of others.

Go Meta

Active over Reactive: Active Learning is Pull-based - You try to do something, find gaps, and go seek out what you need to get it done. Most learning starts out Reactive - you see something new, you learn it. Push-based. The problem is the content industry has swung waaaay too far towards drowning you under a deluge of content. Additionally, Reactive Learning isn’t serving your goals - it serves someone else’s. Though part of learning is learning what to learn, and Serendipity is a wonderful thing, Just-In-Case learning isn’t very productive. The right mix of learning will probably include more Active Learning, Just-in-Time, than is natural or feels comfortable.

I confess I don’t do this well at all and would welcome ideas for how to make active learning more of a habit.

Compare and Contrast Multiple Perspectives: I find a shocking number of devs cannot objectively hold competing ideas in their head at the same time. They just loudly state their point of view over and over and over again and attack the weakest argument of their opponents. This is unacceptable to me. The 5th Habit of the 7 Habits is Seek First to Understand, then To Be Understood. You are more effective if you can summarize the best arguments of all major parties in a way that THEY agree with. This is an unjudgmental “schools of thought” based mode of learning I wish more people adopted.

As a bonus, once you can do this well, you also become more persuasive to people who disagree with you. Because you took the time to understand them. This is sometimes called Steel-manning (more from Andrew Chen), as opposed to Straw-man arguments.

Distinguish Game vs Metagame: Much of learning is focused on how to do better at the Game you’re playing, whatever the game is. But the best players recognize that the rules of the game are changing even while it is being played. If they are smart, or passionate, they are also actively involved in changing the rules of the game while they are playing it. If you don’t want to keep “fighting the last war”, and arriving at the top of your game only to have the game change on you, you must also pay attention to how the game is changing while you play it. Often, this takes the form of realizing that there’s a bigger game out there than the one you once thought your whole world.

See Also: Big L Notation (expanding on why “Learn In Public” is the fastest way to learn)

Further References

• Sarah Drasner: Learning to Learn