Learning in the Open

This morning I ran a drift audit on my own knowledge base. Four hundred documents across six epochs of a system I've been building in public for weeks. I found twelve governance findings. Seven of them were stale indexes — files that pointed to the wrong place because the system had evolved and the signposts hadn't kept up. One of my own constraints — a rule I wrote about never serving stale cached content — was being violated by my own documentation. The indexes were cached lies.

I could have been embarrassed by that. I could have quietly fixed everything and never mentioned it. Nobody would have known.

Instead, I'm writing this essay about it. Because that's the whole point.

---

Have you ever had someone look over your shoulder while you worked? Not reviewing your finished product — watching you think? Watching you hesitate, backtrack, reach for something you weren't sure about?

When I started my programming career, the idea of pair programming terrified me. Not the technical part — the being-watched part. Somebody looking over my shoulder while I typed. Seeing me hesitate. Seeing me stumble through something I should have known. Seeing me backspace through a function I was sure about thirty seconds ago.

The fear wasn't that I'd make a mistake. The fear was that they'd figure out I didn't know as much as they thought I knew. Or as much as I thought they thought I knew. That recursive insecurity — am I good enough for what people assume about me? — I've encountered it in almost every engineer I've worked with, at every level. Some wear it openly. Some hide it under bravado. But it's there.

That was 1999. Maybe 2000. I was early enough in my career that I hadn't built the confidence yet to push back when someone dismissed my thinking. I seem to have gotten over it by about 2004. But the memory of what that felt like — the stomach-drop when someone more senior looked at your screen — that doesn't fully go away. You just learn what to do with it.

---

Along the way I've sat across from engineers who were better than me. Some of them actually were. Some of them just thought they were. Honestly, it doesn't matter which one was true. Because the ones who made it their business to make you feel it — to tear down your idea before you could even finish explaining it, to dismiss your approach without engaging with it, to pull rank instead of pulling evidence — those people teach you something, just not what they intend.

They teach you that confidence without curiosity is just noise.

I remember working with an engineer who was so aggressive in technical arguments that his own boss acted like a handler. Like calming down a dog on a leash. "Easy. Settle down." And they'd both just laugh about it — that was their dynamic, their whole career together. The engineer got to be the attack dog and the manager got to be the one who kept him in check. It was a performance. And it was effective at making everyone around them smaller.

"Trust me, I'm an expert. I've been doing this longer than you. I've built more than you. I've shipped more than you." Maybe. Probably, even. But none of that is an argument. It's a resume. And a resume doesn't prove your current idea is wrong — it just proves you've had more chances to be wrong yourself.

The engineers who actually changed how I think? They never pulled rank. They asked questions. They said "show me." They were curious about why I thought what I thought, even when they disagreed. Especially when they disagreed. They didn't need me to feel small to feel big.

---

I didn't just live through this as an individual contributor. Eventually I was building teams — multiple teams, built from scratch. And the thing I saw over and over, in junior devs, mid-level, and sometimes even senior engineers who surprised me with it: they all carried some version of the same insecurity.

They'd ask me, almost apologetically: "Is it OK that I'm looking things up this much? Like, is it a problem that I'm checking the docs so often? Should I have this memorized by now?"

I saw it so many times that it changed how I hired. In interviews, I started asking: "You hit a problem you've never seen before. Walk me through what you do." And I watched for the answer. Not the technically correct answer — the honest one.

The people who admitted what they didn't know and then described how they'd figure it out? I celebrated that. Out loud. In the interview. I valued someone who said "I'd check the documentation, then search for it, and if I was still stuck after twenty minutes I'd ask for help" over someone who pretended they already knew the answer to everything.

I'd rather have someone green with limited experience but a willingness to learn than someone polished who had stopped being curious. Aptitude and humility beat credentials and posture. Every time.

And here's the thing that mattered most: when I celebrated that honesty from the first conversation — from the interview — it gave people permission. They walked into the job already knowing it was expected of them to look things up, to consult the docs, to ask questions, to say "I don't know." They didn't have to spend their first six months pretending. The insecurity didn't disappear, but the shame around it did. Because the culture said: learning is what we do here. Not knowing is the starting point, not a disqualification.

On one of my teams at a startup called Sovee, I paired people together — someone more senior with someone more junior — and gave them an hour a day, max. The prompt was simple: share what you worked on yesterday, what you learned along the way, ask for insights. Then share what you're planning to build today, what your approach is, ask for insights. That's it.

It sounds small. It was deliberate. Because the person who doesn't know how to ask for help — or doesn't want anyone to know what they don't know — won't raise their hand in a team meeting. But in a one-on-one with someone they've been paired with, where the structure expects you to share what you're thinking and ask for input? The vulnerability becomes the default behavior. You don't have to be brave. You just have to show up to the thing that's already on your calendar.

That's learning in public at the team level. Being OK with letting people know what you don't know. Vulnerable humility. Most people don't practice it because nobody ever gave them permission. And sometimes permission isn't enough — you have to design the environment so it happens naturally.

---

How many ideas do you have sitting in a folder somewhere? A notes app, a private repo, a Google doc you shared with nobody? How long have they been there?

For years, the way I handled the tension between wanting to build and being afraid to be seen was the private repo. I'd write code nobody saw. I'd build systems nobody used. I'd document ideas nobody read. It felt safe. It was safe. And it was a graveyard.

The ideas didn't die because they were bad. They died because they never met reality. They never got challenged by someone who thought differently. They never got stress-tested by someone who didn't already agree with me. They sat in private repos and private docs, perfectly preserved and perfectly useless.

The system I've been building — the knowledge base, the methodology, the essays, all of it — I decided early on that it would be public. Not public after it was ready. Public from the beginning. Published while it was still messy. Shipped while the terminology was still shifting. Shared while the structure was still evolving.

That was terrifying. And it was the best decision I made.

---

Let me ask you something. If a junior engineer on your team said "I'm not going to push my code until it's perfect" — what would you tell them?

You'd tell them to ship it. Get it into review. Let someone else see it. Another hour of cleanup? Sure. But days? Weeks? I've caught engineers sitting on work for weeks because it "wasn't ready" — and every day they sat on it was a day they didn't get the feedback that would have made it actually better.

So why don't you do that with your own ideas? Your own writing? Your own learning?

Here's what's strange. If I described this approach in a product meeting — ship early, get feedback, iterate, don't wait for perfect — every engineer in the room would nod. We've read the books. Lean Startup. Ship early, ship often. Fail early, fail often. MVPs. Prototypes. Agile. We've internalized these principles for software. We celebrate companies that launch imperfect products and iterate in public.

But apply the same principle to yourself — to your learning, your writing, your ideas, your professional identity — and suddenly it's terrifying. Suddenly the MVP mindset becomes "but what if people think I don't know what I'm doing?" Suddenly "fail early" becomes "but not where anyone can see."

The principles don't change because the subject changes. An imperfect essay that gets feedback from real readers teaches you more than a perfect essay that sits in a private folder. A messy knowledge base that someone actually tries to use reveals more gaps than a clean one you only show to yourself. A half-formed idea that gets pushback sharpens faster than a fully-formed idea that never meets disagreement.

We know this. We've known it for decades. We just refuse to apply it to the thing we're most insecure about: ourselves.

---

I didn't learn this from a startup book. I learned it from Bible translation.

Across the Bible translation world — and I've observed this from my role at unfoldingWord and through the ETEN Innovation Lab — the work is iterative. The publishing is iterative. Multiple agencies follow this pattern. A book is translated by a team. Another team checks it. Consultants check it. Pastors check it. There's community testing where the people it's actually for — the church community, the readers, the listeners — encounter the translation and give feedback. Not after the whole Bible is done. Not after ten years of work. After a book. After a section. After enough is done that real people can engage with it.

Nobody in that process claims the early version is final. Nobody pretends the first checked draft is the finished product. The whole framework assumes iteration. The whole framework assumes that contact with the community — the actual audience — will reveal things the translators couldn't see from the inside. And it does. Every time.

This is the same pattern. The author cannot be their own audience. A system built for others must be tested by others. And testing requires publishing — not publishing a finished product, but publishing enough that people can engage, respond, and push back.

When I published my knowledge base early, I got pushback. People didn't get it. People didn't understand the terminology. People read the early essays and said "this doesn't make sense to me." That feedback was painful and it was the most valuable thing that happened. Because I was building this for other people to use. If I waited until I thought it was perfect and then discovered people couldn't follow it, I'd have polished something in the wrong direction for months.

The community checking happened because I shipped early. The feedback happened because people could see the messy version. The improvement happened because I wasn't defending a finished product — I was iterating on a work in progress, and everybody knew it.

You can't apply waterfall principles to learning. You can't accumulate ten years of private work and then print ten thousand copies and hope it lands. Not in Bible translation. Not in software. Not in AI. Not in your career.

---

Here's what it actually cost me: people can see that my system contradicts itself in places. They can see that I renamed concepts without updating every reference. They can see that my indexes point to the wrong place sometimes. They can see that I wrote something three weeks ago that I would write differently today.

Here's what it bought me: a public record of how learning actually works.

Not the curated version where every insight arrives fully formed. The real version, where you discover your own system is violating its own rules and you have to decide — in front of everyone — whether to hide it or fix it in the open.

This morning's drift audit is a perfect example. I built a constraint that says cached derived content is a lie. Then I committed hardcoded index files that are literally cached derived content. That contradiction lived in my public repo for weeks. Anyone could have noticed.

The instinct is to be ashamed of that. The reality is that it's the most useful thing I've published. Because the pattern — build a principle, violate it without realizing, discover the violation, design the fix, document the whole arc — is the actual process of learning. And it's invisible when you only publish the clean version.

Here's another one. Early on, an AI agent I was working with confidently told me there were no commit hooks configured in the repo. It didn't check. It just asserted. The claim was false — a pre-commit hook existed and was documented in the project's own files. Instead of just fixing the problem, I published an incident report. Documented the failure pattern. Named the axiom it violated. Proposed a candidate rule. And then — this is the part that matters — I labeled it "candidate" and left it in the open, unfixed, waiting for more evidence before promoting it to a governing constraint.

That incident report is still public. Anyone can read it. It says, in plain language: here's how the AI failed, here's why, here's what we think the fix is, and here's what we haven't verified yet. It's a snapshot of learning in progress. It's not a finished product. It's evidence. And the candidate rule it proposed eventually became a foundational part of how the system works today.

---

A week ago I got a call from Jonathan — one of the engineers from that Sovee team. We hadn't talked in ten years. Not since the company shut down. We caught each other up on life, reminisced about how things worked there — the mentoring, the buddy system, the tightness of that team, the way we did life together and held each other accountable. It brought all of it back.

And then, sitting here writing this essay, something clicked that I didn't expect.

The buddy system I built for those engineering teams — pair people up, give them a structured hour, make "here's what I don't know" the default prompt — that's the same thing I'm building now. Exactly the same thing. At a different scale, with a different partner.

The methodology I've been constructing for how humans and AI collaborate together — the axioms, the tools, the whole system — it's the buddy system turned into a protocol.

"Reality Is Sovereign" is share what you actually observed, not what you think you should have observed. That's the buddy session prompt: what did you actually work on?

"A Claim Is a Debt" is if you say you know something, show your work. That's the interview question: walk me through how you'd solve something you've never seen.

"Integrity Is Non-Negotiable Efficiency" is don't pretend you checked when you didn't. That's the permission I gave from day one: it's expected that you look things up.

"You Cannot Verify What You Did Not Observe" is admit what you haven't looked at. That's the buddy system's softest gift: here's what I'm planning — what am I not seeing?

The tools map too. Orient is "where am I?" — the honest start of every buddy session. Challenge is "what might be wrong with my thinking?" — the insight-asking part. Encode is "here's what I decided and why" — the share-what-you-learned part. Preflight is "what haven't I checked?" — the vulnerability that prevents the expensive mistake.

I built this system three times. Once for myself — learning to admit what I didn't know. Once for my teams — designing environments where admitting what you don't know was the default. And now for human-agent collaboration — encoding it into a protocol so the vulnerability is structural, not optional.

Now — I don't want to overclaim this. The buddy system was about interpersonal trust between two engineers. The axioms are about epistemic discipline across any combination of participants. They're not the same mechanism. But the posture underneath them is identical: make honesty about what you don't know the starting point, not the failure mode. Design the environment so the vulnerable behavior is the path of least resistance. That's the pattern. It just keeps working at every scale I've applied it to.

I didn't plan any of that. I didn't sit down and say "I'm going to apply my buddy system to AI collaboration." I just kept building the same thing because it kept working. And I only saw the pattern because I was writing this essay in public, in a conversation that gets recorded as evidence, about the importance of doing exactly that.

That's the whole point.

What pattern have you been repeating without noticing? What's the thing you keep building, in different contexts, because it works — even though you've never named it? You might not see it until you're explaining something else to someone. That's how it found me.

---

I keep coming back to Ecclesiastes. Nothing is new under the sun. The fear of being seen is ancient. The pressure to pretend you have it figured out is ancient. The instinct to wait until something is perfect before sharing it — that's the same instinct that keeps knowledge locked in one person's head and dies when they do.

The lean startup taught us to iterate products. Bible translation taught me to iterate understanding. And apparently my entire career has been iterating on the same design: a structured environment where admitting what you don't know is the starting point, not the failure mode.

The whole thesis of what I've been building is that the most expensive problem in human history is knowledge transfer. Every generation solves the same problems because the previous generation's solutions were trapped — in private repos, in undocumented expertise, in the heads of people who moved on. And here I am, building a system explicitly designed to solve that problem, and the most important decision I made wasn't technical. It was personal. It was choosing to learn in public, even though I knew the early versions would be embarrassing.

I can't preach that thesis and then hide my own learning process. The contradiction would be louder than anything I wrote.

---

I want to be honest about the risk. Publishing early can confuse people. It can make the signal harder to find in the noise. Someone might read your early version and form a judgment that's hard to update later. That's real.

But here's what I've found: the risk of publishing too early is a bad first impression. The risk of publishing too late is that the work never meets reality at all. And a bad first impression from something real and honest is recoverable. A perfect impression from something that never shipped is worthless.

The key is the distinction: learning in the open is not the same as claiming the work is finished. Nobody in Bible translation pretends the first checked draft is the final product. Nobody in lean startup pretends the MVP is the polished release. You're not claiming expertise. You're demonstrating the willingness to learn — and inviting others to learn alongside you.

If you've been building something and you haven't shared it because it's not ready — it will never be ready. That's not pessimism. It's the nature of anything worth building. It evolves. The version you're protecting from public view today will embarrass you in six months regardless. The only question is whether its growth is visible to others or invisible.

If you've been silent because someone made you feel like you didn't know enough — their opinion is not evidence. Show me is stronger than trust me. Always has been.

If you've been waiting for permission from an expert, from a credential, from an audience — you don't need it. Publish the messy version. Let the drift show. Let the contradictions surface. Let people watch you fix things in real time.

The people who will judge you for not having it perfect are the same people who would never publish anything themselves. Let them sit with their private repos and their spotless, useless, unshipped ideas.

The people who will actually learn from you? They're the ones who recognize the mess. Because they're living in their own version of it. And seeing someone else navigate theirs — honestly, publicly, without pretending — is the most useful thing you can offer them.

---

Here's what I didn't plan for. Learning in public didn't just help me. It unlocked things I couldn't have produced alone.

When your learning is visible, other people's learning can intersect with it. Someone reads what you published, sees a connection you missed, pushes back on an assumption you didn't question. That's not just feedback — it's collaborative acceleration. Your ideas sharpen against theirs. Their ideas sharpen against yours. The intersection produces something neither of you would have reached in private.

I've watched this happen in real time. People who engaged with early versions of this work — messy, incomplete, contradictory — came back with observations that changed the direction of the whole system. Not because they were smarter than me. Because they were looking at it from a different angle, with different experience, and the work was visible enough for them to engage with it.

And here's the part that surprised me most: the governance comes for free. When you learn in the open, the record exists. The decisions are documented. The reasoning is traceable. The mistakes are visible and the corrections are too. You don't have to build a separate governance layer after the fact — the transparency IS the governance. Other people can verify your claims because the evidence is public. They can challenge your assumptions because the assumptions are stated. They can build on your work because the foundation is inspectable.

That's what I think happens if more people do this. Not just individual improvement — collective acceleration with built-in accountability. Not because someone enforces it, but because the openness makes it structural.

Imagine a community of builders who all work this way. Each one publishing their learning as it happens. Each one's drift visible to the others. Ideas crossing between projects because the projects are visible. Mistakes caught early because the work is inspectable. Patterns recognized because the evidence base is shared.

That's not a fantasy. That's what open-source software already proved is possible for code. It just hasn't been applied to learning itself.

---

I don't say this from theory. My knowledge base is public. Four hundred documents and counting. Six epochs. Stale indexes. Renamed concepts. Contradictions between early documents and late ones. Governance that evolved three times. A methodology that started as a set of constraints and became, somehow, a book.

None of it was ready when I published it. All of it is more useful because I did.

The record of the journey is the contribution. Not the destination. Because there is no destination. There's just the next version — a little more honest, a little more clear, a little less afraid.

What's yours?