10 Ways I Learn in Public  ## Metadata - Author: [[Nicole van der Hoeven]] - Full Title: 10 Ways I Learn in Public - Category: #articles - Document Note: --- tags: - #learninginpublic - #pkm - #community Author: [Not Specified, video narrator] Source: YouTube – 10 ways I learn in public Reference: [10 ways I learn in public (YouTube)](https://www.youtube.com/watch?v=IE94ZZo6IVw) date created: {{2025-08-22}} {{18:45}} --- # Title: Learning in Public: 10 Ways to Show Your Work and Grow Together ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The video outlines **10 methods for learning in public**—from answering questions even when unsure, to sharing notes, running livestreams, writing newsletters, and even writing a book openly. The main message: **authenticity and gradual exposure** build collaboration, feedback loops, and deeper learning. --- ## 📖 Main Content: The talk emphasizes: - Cunningham’s Law as a metaphor for participation: sharing imperfect work accelerates feedback. - The value of **public curation of notes** (via Readwise, Obsidian, publishing highlights). - Short-form sharing (#TodayILearned) as an effective way to distribute knowledge. - Structured methods for feedback loops (change logs, newsletters, canary-style staged sharing). - Using social media, livestreams, and conferences to create **reciprocal learning spaces**. - Ending with the vulnerability of writing a book in public—showing growth through transparency. ### 🗒️ Notes - [00:01](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=1) Post bad answers to get better ones → authenticity drives feedback. - [02:16](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=136) Share curated notes → tools like Readwise + Obsidian Publish show highlights, even unfinished. - [04:31](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=271) TIL snippets (Josh Bren Show) → practical micro-notes become cumulative repositories of value. - [06:57](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=417) Social learning via hashtags (#TodayILearned) + Mastodon PKM server → record of interest & growth. - [09:12](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=552) Feedback through shared drafts, public change logs, and GitHub integration. - [11:26](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=686) Livestream interviews (Grafana Office Hours, Avocados) → conversational, communal learning. - [13:47](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=827) Slides via Obsidian plugins → markdown presentations reinforce public-first workflow. - [16:06](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=966) Beginner talks at conferences → bridge knowledge gaps. Videos help crystallize understanding. - [18:18](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=1098) Newsletters as polished notes (Buttondown + Obsidian integration). - [20:22](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=1222) Canary learning → start small with friends, expand to Patreon, then publish. - [22:26](https://www.youtube.com/watch?v=IE94ZZo6IVw&t=1346) Writing a book in public → shows vulnerability, courage, iterative growth. --- ## 📖 References: - Cunningham’s Law - Readwise, Obsidian Publish - GitHub repos for Today I Learned logs - Buttondown newsletter platform --- ## 🗣️ Paraphrase: 1. *Original*: “The best way to get a good answer is to post a bad one… it’s easier to get feedback when we show our work.” *Paraphrase*: Rather than chasing the perfect question, sharing flawed attempts sparks quicker, richer feedback loops. 2. *Original*: “Publishing unfinished notes still provides value… it establishes what I’m thinking.” *Paraphrase*: Even incomplete notes carry weight—they reflect current thought and invite collaboration, critique, and evolution. --- ## 📰 Newsletter: 🚀 **Learning in Public: 10 Ways to Grow Together** Ever posted a wrong answer online—only to get corrected fast? That’s Cunningham’s Law in action, and it’s the foundation of **learning in public**. From short TIL notes and livestream interviews to Obsidian-powered newsletters, this approach builds community through transparency. Highlights include: - Curating notes with **Readwise + Obsidian Publish** - Daily micro-learnings with **#TodayILearned** - Livestream conversations like **Grafana Office Hours** - Using markdown slides for **conference presentations** - Writing a **book in public** (yes, terrifying—but powerful!) Read more → [Watch the full video](https://www.youtube.com/watch?v=IE94ZZo6IVw). --- ## ✅ Action Items: - Integrate **learning-in-public frameworks** into WordPress contributor onboarding. - Model **authentic mistake-sharing** in open source contribution training. - Advocate for **staged community rollouts** of contributor tools (parallel to canary deployments). - Build **cross-platform PKM communities** to share public notes (Obsidian, GitHub, WP.org). - As an aspiring OSPO director, champion **transparency-first learning** as an organizational best practice. --- ## 🧪 Hypotheses: - Public note-sharing accelerates **collective knowledge building**. - Canary rollouts in knowledge-sharing reduce **fear of exposure** for learners. - Transparency in learning strengthens **trust within open-source communities**. ### 📊 Methodology: - Survey contributors using public vs. private note-taking. - Measure adoption rates of TIL-style micro-posts across platforms. - Track engagement metrics from staged vs. immediate public sharing. ### ❓ Questions: - How does public vulnerability affect long-term community trust? - Can daily micro-shares outperform structured tutorials in engagement? - What barriers stop developers from learning in public? ### 🔮 Future Research: - Comparative study between **closed-team learning** and **public-first learning** outcomes. - Longitudinal analysis of **career growth** for those practicing public learning. ### 💡 Implications: If proven, this could shift **OSPO learning culture** towards radical transparency, accelerating skill transfer and inclusivity. --- ## 🧠 Learning Styles Assessment: - **Visual**: Present → Markdown slides, repo visuals. Could add infographics. - **Aural**: Present → Livestreams, interviews. Could add audio summaries. - **Verbal**: Strong → Explanations, analogies. - **Physical**: Weak → No hands-on exercises. Suggest: guided tasks. - **Logical**: Strong → Structured workflows (e.g., canary rollout). - **Social**: Present → Livestream Q&A, Discord feedback. - **Solitary**: Present → Journaling, unfinished notes. - **Naturalistic**: Absent → Could integrate analogies with ecosystems/sustainability. --- ## 📊 Accessibility Assessment: - **Screen reader compatibility**: Dependent on platform (Obsidian/YouTube). Add transcripts, alt text. - **Keyboard navigation**: Limited for non-code demos. Needs optimization. - **Contrast/readability**: Video text may lack WCAG compliance—suggest review. - **Text resizing**: Markdown adaptable, but ensure responsive themes for shared notes. --- ## 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - **Cultural Relevance**: Limited cultural diversity. Could showcase global learning-in-public practices. - **Inclusive Language**: Neutral, but tech-heavy. Suggest defining jargon. - **Neurodiversity Support**: Strong—short snippets aid ADHD/ASD learners. Could chunk long explanations more. - **Representation**: Primarily individual perspective. Could highlight varied community contributors. - **P - Summary: In this video, the speaker discusses 10 ways they learn in public. They emphasize the importance of showing their work and getting feedback, as well as the value of sharing curated lists of resources. The speaker also talks about the benefits of talking about what they've learned, publishing their notes online, and keeping a public changelog. They mention the use of videos to record the learning process and the value of writing newsletters or blog posts to consolidate and share their knowledge. The speaker encourages authenticity and emphasizes the value of beginner-level content. - URL: https://www.youtube.com/watch?v=IE94ZZo6IVw - "The best way to get a good answer on the Internet is not to ask a good question." Millions of people ask questions all the time. Why should anyone answer yours? No, the best way to get a good answer is to post a bad one. This is Cunningham's Law. Now, this is overly simplistic and even misattributed to someone named Ward Cunningham who denies ever having said it, but I can't help but feel that there's a little kernel of truth to it. And the truth is this. (text whooshing) It's a lot easier to get feedback when we show our work. In this video, I'm gonna talk about 10 different ways that I show my work by learning in public, because that's what all of this note taking is really about, learning. Number one, answer questions even when you're not sure. I think we place too much emphasis on getting it right the first time, when really something that you say, might actually help somebody else get to the right answer. The key is being authentic, not answering questions like you are an expert if you don't feel that you are, or if you don't feel very certain about your answer. Sometimes though, people ask questions to be able to rubber duck it out, to be able to bounce ideas off of each other, and you answering a wrong answer, might actually prompt someone else to say, "No, this is the right answer." And then everybody learns from that experience. So, I am a big proponent of raising pull requests on GitHub, even if I'm sure that there's a better way to accomplish the same thing with, like, less code and maybe more elegant code. I think we should just give each other permission to make mistakes. And most of all, we should allow ourselves to make mistakes too. Number two is read in public. A lot of people think that you can't add value if you're not coming up with anything new, but nothing's really new anyway, and I think it can be useful to have, even a curated list of what to read. I do this by using a service called Readwise. I know I've talked about it so much recently, but I'm just, like, really loving it. Let me show you what I mean. I've talked previously about how I use the Readwise official community plugin for Obsidian to bring my highlights from things that I've read or watched or listened to from Readwise into my notes in Obsidian. And then I actually published them using Obsidian Publish, and this is what that looks like. This is my public vault of notes and this is an example of one of the books that I've read recently called "Quit" by Annie Duke. It's a really good one actually. I publish all of my highlights from this book. I mean, I don't tend to take notes while I'm reading things. I'm really just highlighting, and you can see that I am highlighting chapters, and it can be a little bit long. And I do wonder sometimes if people even get any value from this. But then I have found that people, because they were looking at my notes and my highlights, at least, have said things like, "Oh, I didn't think about highlighting the chapter." And the way that I do this actually is I comment on it while I'm on my Kindle and the comment just has .h1. And Readwise knows to turn that into a heading when I bring it over to Obsidian, which is awesome. Or like people have told me that they look up books before they read them, they look up what I've highlighted, even if I haven't created, like, any formal notes on it. And I think that's just cool, and I totally get it. I would do the same. I love seeing what people find interesting enough to highlight. I also have, for example, the kind of literature review notes on the same book, and this is where I'm starting to kind of piece it together. As you can see, it's not really fully there yet, but still, even though it's unfinished, that doesn't mean that it doesn't provide any value. There's already a little bit of, like, a summary or me trying to understand what the author is saying. Number three, talk about what you've learned. I first came across Josh Brown shows, awesome GitHub repository that's just called TIL, Today I Learned. And what it is, is every day for I don't know, years, I don't know if he's missed one probably, right? But every day for several years, he's been just talking about what he's learned. He just says like a one-liner sometimes, sometimes it's a little bit of code. Sometimes it's like, "Oh, today I learned about this new tool and what it does," that's it. It doesn't have to be like a fully-formed blog post. It's just short little snippets of his life and what he's learned, and this is what it looks like when someone does that over time. Look, so this is his actual GitHub repository, but now look at all the categories that he's got. On many different software development topics, he has an entire collection of it. So, let's say GitHub Actions, like he has different ones, but each one sometimes like it has a little bit of code there. Sometimes they are tutorials, and everything is just really specific to what he needed to learn that day. Something that I really love that I got inspired by, is for example, with Go, he wasn't like, here is the history of Go, here's how to declare variables in Go. It's like, no, he doesn't need to know any of that, obviously. He just needed very specific things, like Build for Go for a specific OS and architecture and it's short, but it's what was specific to his use case which means that all of these are really practical things. So here's what my page and JavaScript looks like. These are the things that I have found personally useful. Things like converting or random numbers, or regular expressions in JavaScript and each one, when you click into it, it's like a one sentence description of what a regular expression is. I don't even have a regular expressions page, right? But it's this idea of like, you don't have to explain everything from zero to be able to provide value. You can just look up what you were gonna look up anyway for whatever it was, and then just record it in your notes. And it is so useful. It's personally useful because I always go to this list whenever I come across the same issues and I'm always grateful to myself that I wrote it this way that I wasn't like, "Here's the history of JavaScript." I think this is a really good use case for social media rather than just the inane statuses of exactly what you're doing at every second of every day. I like to use it for learning. So a few years ago I moved over to Mastodon and you really should do if you're still on X, but I started a PKM server called PKM Social with my friend, Marcus Olson. Now, for his own reasons, he's decided to step back a little bit and so I'm now co-owning it and running it with my other friend, Andy Polaine. But I really think that Mastodon and just social media in general will be a lot better if people talked about the things that they learned. So here's how I do that. On the right here, are things that I have learned and I always do a hashtag #til, Today I Learned. And things like this one is about my last video where I learned about Quartz. I actually recorded that video as I was learning it, so that wasn't like super rehearsed. That was, I did that once and there was one take at least the tutorial part. So I was really learning right along with you all. And then here, it's like, "Today, I learned that you can use plausible with Obsidian Publish," you know, so just short little things. I post notes when I make them, even if they're not completely finished. I played a different tabletop role-playing game system and I posted about that, you know, it doesn't have to be highfalutin or, you know, many of these are quite short. But what this does is it establishes a record of learning and a record of areas of your own interest. This is useful for you for knowing what you say you're interested in or what you decided to build your career on versus what you're actually doing in your spare time for fun? And it's also useful for other people who are interested in the same things that you are. Number four, publish your notes. And I've shown you a little bit of this already and definitely I've talked about it, but I publish maybe 80% of my notes online. And it's not because I think they're particularly brilliant. In fact, I still cringe when I see that I've published a note and it's like empty because I don't know, I made a file on it and decided not to put anything in it. But you know, it still establishes all the things that I'm interested in and I really love that it's an easy way to show people this is currently what I think, where did I go wrong? And I've done just that. In this exchange, for example, I was asking a friend of mine, Daniel Gonzalez Lopes, how he would restructure a page that I had on Kubernetes monitoring and he was able to give me good, concrete feedback. Now, if I had just gone to him and said, "Hey, can you tell me about monitoring Kubernetes?" I doubt that he would've come up with the entire page that I did, but because I had shown this is the work that I've already done. I just need you to kind of steer me in the right direction or give me a few hints. And I think that's a lot more accessible for other people because they can see that you've put in the work to do it. And along the same lines, keep a public Changelog. I actually keep one on my notes down here. There is a Changelog, and this is not something that I manually maintain. This is actually using a plugin called Vault Changelog. Now I've gotten a few questions about this. I use my own forked version of the plugin Obsidian Vault Changelog because that plugin doesn't seem like it's maintained actively anymore. I did a pull request like a year ago and it still hasn't been really responded to or merged. So I kind of just went my own way. And the thing that I really think that the version that's on the Obsidian community plugins list is missing, is it doesn't have a way to exclude folders. So my pull request, my addition to this plugin added excluded folders. So for example, in my Vault Changelog here, there's an excluded paths field here where I just put down all of the folders that I never wanted to look at. If you'd like to use my version two, you can, but you will have to jump through an additional hoop. You will have to install the Obsidian BRAT plugin, which actually lets you add kind of beta versions of plugins. And what you're gonna have to do is click Add Beta plugin here, and then you would put the repository name. And in this case, you would have to put mine, I am going to put this in the description below or in the first pin comment so that you can do it too if you want. Then you can use excluded paths for Vault Changelog two. Number five, do live streams where you get to interview people and ask them questions that you don't know the answer to. I have done this at least once a week for the last few years. I run something called Grafana Office Hours. I work at a company called Grafana and every Friday, just kind of bring somebody on because there's so many things that are going on in this space of observability in tech and I just bring them on and ask them questions about it. And it is really useful for me because I'm getting something out of it. It's useful for them because a lot of times engineers aren't the best at talking about their work. So it's nice to be able to have another engineer there that can ask a little bit more nuanced questions or informed questions to draw them out. And it's also good for third parties who are watching the exchange who might be at different parts of the learning spectrum on the topic. And so I think it's win, win, win. I do a few of these for work. I have Grafana Office Hours. I had previously done 100 episodes of this back before we were acquired and it was called k6 Office Hours. I also have Cafe con Grafana, which is like a Spanish version of that. And then I also have Adobo and Avocados, which is something that I do with one of my coworkers, Marie Cruz. This is actually a Git repository that's stored in GitHub. It is public, and that's why I'm showing you something that's work related because it's already public. And what I do is when we have a guest, I send them the talking points that I would like to cover, but all of this is just marked down, which means that I can open it up in Obsidian. Nobody needs to know any better. Here's an example of something that I did recently for an interview with Ryan Perry, who's a co-founder of a project called Pyroscope. Now, this is really handy because I actually sent Ryan the talking points before we went live, and so it was good for me to get something down, but it's also good to share it with my co-host, Paul and Ryan, the guest. I really like this method because with a live stream, I don't need to edit anything. And also it's almost like it gives me permission to ask all of the basic questions that something that would be basic to one of these guests is not really basic for me, but in an interview format that's kind of expected. And so I feel more able to ask questions, but I also don't have a problem just saying, "Hey, can you just tell me this really basic thing I feel I ought to know, but I don't." Number six, present using your slides. Now, Obsidian makes this really easy because it already comes with a core plugin called Slides. You can use that, but I personally use a community plugin called Advanced Slides. I made a video all about that, so check that out if you wanna know the details but it is a way of using markdown to present. Here's an example of a presentation that I gave at TestCon Europe in Lithuania last year. It's called Emergent load testing, and it still really pretty much looks like notes. This part are the speaker's notes, so they're not actually shown, but it's actually what I started with. And then I just put like these lines, kind of the three dashes there and then these images as well. And this plugin makes it, so that I can just do show slide preview and this is what it looks like and it functions just like you might expect. And it looks a bit cut off here because this is a smaller monitor than what I normally use. The cool thing about this is I can also render this in HTML. It's part of the plugin and then this is on my site now. I can host it here and people can see the full thing and go through the presentation. So I always start my presentations by saying, "Hey, you know, you don't need to take notes on what's on the slides because I'm gonna give you a link to that." And they can even still hit S here. And it loads the speaker view with all of my notes. This is all based on markdown files in Obsidian, which I find amazing. And this is really learning in public in the extreme. I have done things where I have submitted to CFPs or Call For Papers at conferences and I have proposed topics that I didn't know anything about. Again, authenticity is the key here though I never say that I'm an expert and when I do that, I always say like, "From a beginner's point of view or something like that." I think that there is value in showing people the first zero to three levels of a topic. Sometimes in conferences, everything that's being talked about is like so far above everybody else's head that it's not really that useful to most people. Most people need the beginner stuff. You can help give them that. I really love being able to talk about that stuff and also giving myself a little bit of a push to learn in public myself. Number seven, make videos and record the learning process. Now, one of the things that I worry about is that people think I'm some expert in all of the things I talk about. And while I do have a lot of experience in many of the topics I cover, like Obsidian and I never talk about a tool unless I myself have used it or I'm very excited about it, but sometimes I also just learn along with you. I learn when I make the video because it's one thing to have done it before and it's another to actually think about how to communicate this to people. And that process of explanation really helps crystallize that knowledge for me as well. Now, part of this is responding to feedback. I get a lot of comments, I always read my comments. I don't always get a chance to respond, but I do read them and I do try to learn from them and revise some things that I get wrong. So please, if you spot something, I'll always welcome feedback if you're nice about it. (chuckles) Number eight, write a newsletter or a blog post. Now, my way of doing this is I've recently started doing a newsletter called Thinking in Public. You can subscribe to it here. And it is a more polished version of my notes. It's what blog posts used to be. And I kind of look at this as consolidating my notes 'cause my notes can be messy and unfinished, you know? But sometimes there's still value in bringing everything together and a nice little package that's in text. I do that in an Obsidian too. Here's an example of what that first issue of my newsletter looked like. I put everything in here, looks pretty much like how it would normally look in Obsidian, just a little bit more structured and maybe a little bit longer. And then I publish it to my newsletter provider of choice, which is called Buttondown. Now I chose Buttondown to be honest, mainly because it has a cool Obsidian Integration. So there is a Buttondown of Obsidian plugin and it is pretty simple. All it does is, it creates a new Buttondown draft from this note, so whatever was on here, it's just gonna send into Buttondown, but as a draft. So it's never gonna actually send the emails to people. This is just a nice way to get most of the way there. Then you can go into Buttondown. This is what it looks like. This is a preview version here. This is the email version and this is the web version. And on the left here is marked down. So it is very marked down based, which makes it perfect for this workflow. So I'll just like tweak a little bit of things that maybe look a little off and then I send it off. Number nine, do canary deployments. Now in software engineering, before you deploy a big feature that is likely to change a lot of things, or maybe it's something that's a bit contentious for your users. A good practice is to do what's called a Canary deployment. This means that you don't push it out to everybody at once. It's more like a gradual rollout. So you would have a small percentage of your users that would be able to see this new feature and then you can then change that percentage once you get more confidence in that feature being whatever it is, you're worried it won't be stable or useful or functional. You can do this when you're learning in public too. It can be very daunting depending on what it is to go from completely private to completely public. So what I like to do is I have like an inner circle of friends and if I'm nervous about something, I ask them to have a look at it and they give me feedback. It's like a much safer space. And then I branch out a little bit and then I send it maybe to like a friendly public, like my patron, I try to give them early access to things as much as possible. They're much more privy to how what I'm thinking of doing and my little experiments. And then after that, if I still don't get any big push backs, then I release it to the public. This is how it worked with my course Obsidian for Everyone. I definitely needed that three tier kind of rollout phase. And just because you learn in public doesn't mean that you have to go from zero to 100. Now these are the ways that I personally learn in public, but I hope you don't feel that you have to do it the same way, you can try some of these or none of these. I think everybody gets to decide where their comfort level is with sharing these innermost thoughts. But wait, didn't I say 10? Well, number 10, is actually writing a book in public. It's also the one that I'm most nervous about for some reason, because I make videos all the time. And yet when it comes to writing a book, I'm nervous. It's really overwhelming, honestly, but I'm doing it because it is about learning in public. If you would like to see it, it is called Doing It in Public. Yes, the pun is intentional and you can check it out here. If you'd like to look at it, the way that you can give me feedback is by joining my Discord server or raising a GitHub issue whichever you are more familiar or comfortable with, the instructions are in that link anyway, or you can just read it and you know, just send me a post on Mastodon if you would like. The whole point of this is to be able to show people the progress that I'm making while I'm writing the book. Now, I actually said that I was gonna make a book last year. I know that didn't happen and I also changed the topic of it. That was gonna be an Obsidian based book. I'm much more excited about learning in public and I feel like I have a lot more to say that I really can't wait to get down on the screen and I hope you'll join it with me. I would love to get any feedback. I already have the outline and part of the introduction I hope by the time that you see this. So please have a look. I would really love to hear what you think. Thanks for watching. Multumesc., 10 Ways I Learn in Public, Nicole van der Hoeven, 01hnnk0963xp1yn5v1jyvzpwjr.