Practical Ways to 'Learn in Public' Now

I’ve been a practitioner of Shawn Wang’s ‘Learn in Public’ for years. In this post, I’ll share a list of ways I’ve found to learn in public.

I think that learning in public can start with you, then your team, then the world. And so, these are ordered from small and private to big and public.

Talk through a tough problem out loud. Instead of holding a difficult problem in your head, try building a solution out loud from a series of facts. “We’re seeing a bug on staging. It affects this page…”. Talk to a duck if nobody is around.

Use a whiteboard for a tough problem. A drawing is easier many some people to understand than trying to explain a database schema. Some of the most interesting work I’ve been a part of started with a hasty whiteboard drawing.

Asking ‘what’s wrong with this idea?’ People don’t like to criticize. I’ve found this question, paraphrased from Paul Arden’s It’s Not How Good You Are, It’s How Good You Want To Be, to be irreplaceable. If you want to get real feedback, give it a try.

Saying “I don’t know” to a question, then finding out the answer and sharing it. “I don’t know, but I’ll find out” are empowering words. They show that you know what you don’t know, and following up shows that that you’re eager to learn and that you follow up on things.

When you look something up, share the resource that helped you understand it. If possible, share the specific line via an anchor tag. It shows how you think and creates a public record of you solving problems and making your team better.

Volunteer to take taking meeting notes in a shared online document. Share the link beforehand and after so people can contribute and watch you type, edit, and refine a stream of ideas into a coherent artifact.

Commenting on your own pull requests about things that are noteworthy, things that you’re unsure about, things that could be better. I do this often. Pull requests can contain mountains of information; help those who are reviewing your work by pointing out the important things.

Proactively tagging coworkers to review your code. If your team does code reviews, and your pull request migrates the database, tag the SQL expert. Seeking feedback proactively is going to lead to a better product, and you’ll learn, too.

Demo a feature to your team. And do it live! My team demos a lot. I like to create a loose script but allow a good question to take things off the rails. What if something goes wrong? Embrace it! You might find an interesting bug, or demonstrate that software is an imperfect, evolving thing.

Pair program. Hey, it’s not for everyone! I pair even when I don’t have to. Pairing is the most high-volume way to improve and teach that I’ve encountered.

Write a TIL. Hashrocket’s TIL came from a simple idea: short technical posts by working engineers. Limited word count, minimal friction, no deleting (!), editing allowed but not a big part of the process. Check out Josh Branchaud’s TIL (13K stars currently) to see how far this practice can take you.

Create a Gist. I love Gists! I have three or four links to Gists that I’ve shared dozens of times. Share a function, a dotfile, or a command-line command that helped you.

Write a cheatsheet. I have a printed copy of the ‘React Testing Library’ cheatsheet on my desk. It’s one my most valuable resources, because it helps me clear the hurdle of writing that first test.

Open-source your dotfiles. I’ve posted my dotfiles in a few online communities over the years, and the responses are always… informative! When you look at my dotfiles over the years, you can see how my preferences have evolved.

Answer a question in a public forum. Try to answer a question on a site like Stack Overflow. I used to do this frequently. It was hard at first, but I got better at it. I wrote about my strategy.

Live-code at a Meetup or live-stream your coding. Few things test us as programmers more than typing in front of a crowd. But it’s also such a rich way to communicate and learn. The key is to approach it with a sense of humor. It’s not going to be perfect. That’s okay.

Speaking at Meetups. Can you talk for five to ten minutes about programming? If so, sign up for a lightning talk at your local user group.

Start a blog or newsletter. You should blog! Blogging changed my career. I still mostly do it for myself, but I’ve gotten a surprising number of benefits from this website.

Speaking at a conference. This is the big time! Doing this right takes tons of time and energy. You have to write the proposal, get selected (~1 in 10 chance), prepare the talk, and then deliver it. At a minimum, you get a nice professional video to share. The few times I’ve done it have each been incredibly memorable.

A Challenge!

If you’re interested in learning in public more, I have a challenge: pick one of these ideas and start doing it now. Write a TIL about the last thing you learned and post it in a Gist or Twitter. Open-source your dotfiles and post them in a Reddit forum. Answer a question on Stack Overflow. If it’s something you can link to, share it in the comments!

• Ideas