When I was trying to move from Clipper to FoxPro in Brazil, there was almost nothing to read in Portuguese. The local bookstore might have one translated manual. The library had nothing. What I had was a dial-up connection, a Portuguese FoxPro forum with a few dozen active members, and a much larger international FoxPro forum in English that I could barely read.
The pattern started by accident. Someone would ask a question on the local forum that I did not know how to answer. I would copy the Portuguese question, translate it into English, and post it on the international forum. Hours or days later, someone there would answer. I would read the answer, open FoxPro, test it, and then translate the explanation back into Portuguese for the person who asked. After a few months, people in Brazil started treating me like a FoxPro expert. I was only a few steps ahead and willing to share what I had learned five minutes earlier.
That forum taught me more than FoxPro. It taught me how to learn in public.
The loop was simple: translate a question, read the answer, understand just enough, then explain it to someone else. Each pass sharpened my English and my understanding at the same time. I practiced translation, from one language to another and from one problem to a working solution. By the time I had to make the jump from FoxPro to .NET, I was already comfortable learning from strangers on the internet. By the time I moved from Brazil to the United States, I was comfortable asking for help in a language that was not my own. The community answered my questions and gave me the habit of asking out loud.
Every major transition since then has had a community behind it. When I moved from FoxPro to .NET, user groups and online forums kept me from stalling. When I moved from .NET to Ruby on Rails, I was a beginner again in almost every way: new language, new framework, new operating system, new terminal. Another developer in the community spent hours on calls with me, dictating code character by character. This symbol is a hash rocket. This file is the controller. This line belongs in the view. He was patient because he remembered what it felt like not to know.
I wanted to pay that forward. I started writing articles for .NET developers who were migrating to Ruby on Rails. Here is how you set up a route. Here is how a controller works. In ASP.NET MVC the pattern looks like this; in Rails it looks like that. I was a recent beginner mapping one unfamiliar place onto another. That is what made the writing useful. I still had the bruises from the first climb, so I could describe the handholds.
People often misunderstand this about learning in public. They think they need mastery before they share. They wait until they are the guru at the top of the mountain. But the person at the top may have forgotten how steep the first few feet feel. The better guide is often the person five steps ahead, who still remembers what it is like not to know.
My blog has become a twenty-year public notebook. It started as a place to record what I was learning so I would not have to relearn it later. Over time it became something else: proof that you can document the journey while you are still on it. I have written about the discipline of daily blogging in Create Everything – Daily Blogging and the Drive to Share Knowledge and about the compression that happens when you publish thirty days in a row in Thirty Days Thirty Posts What I Learned from Blogging Daily. The habit is the same. Write down what you learned, before you feel ready, and let the public reading refine your understanding. It has paid off more than I expected because the practice made me articulate ideas I would otherwise have left half-formed. Not every post was brilliant.
The same principle shows up at Improving and the user groups and communities that we host, such as the Side Project Society. People show up with a real problem they are trying to solve, or a skill they want to practice, and they match themselves with others who can fill the gap. Some bring domain knowledge but no code. Some bring code but no project. The meeting works like a marketplace: each person explains what they are trying to achieve, what problem they have identified, what know-how they bring, and what they need from someone else. They solve a real problem with real people rather than building another hello world. That is a much better classroom than any tutorial.
Teaching forces you to clarify what you actually understand. Writing for someone else exposes the gaps that private note-taking hides. Answering a question from someone who is five steps behind makes you translate the concept one more time, and that translation is where the learning sticks. You also attract the people you want to learn from.
When I wrote about moving from .NET to Ruby, other people making the same move found me. When I wrote about FoxPro answers, better FoxPro developers corrected me. Both outcomes taught me something.
That, in fact, happened again a few weeks ago, when I gave a talk on building my digital brain app; my first local RAG tool, built to satisfy a specific need I have. Some attendees learned things they can do that they weren’t aware before; other attendees pointed out what my next steps in this journey could be.
The community is the curriculum, open to you before you are an expert. The fastest way to learn the next thing is to teach what you are learning while you are learning it.
The people you learn with also help you choose what is worth learning next. The final post turns that community into a strategy.
Further reading
- Create Everything – Daily Blogging and the Drive to Share Knowledge
- Thirty Days Thirty Posts What I Learned from Blogging Daily
- Preparing a Talk by Thinking Out Loud
- From Voiced Ideas to Published Post in 20 Minutes
Leave a Reply