I recently shared a blog post entitled “The Most Successful Developers Share More Than They Take” with the comment:

I try to practice “public by default” though, because of my work, it’s often “on the internal wiki” rather than fully open.

Unfortunately the article spends a lot of time talking about blogging and podcasting which, perhaps, undermined the point I was trying to make. If you want to write blogs, speak on podcasts, and present at conferences, good luck to you¹. Not everyone will want to do those things, and that’s fine. I’m not advocating for that. I think most people can do what I meant.

Here’s the key point: make your “content” as widely available as practicable. Allow people to pull when it’s convenient for them rather than you push the information you assume they’d be interested in.

In this context, “public” doesn’t have to mean on the internet or even visible to your entire company. Nor does it mean pushing it to everyone. Updates do not need to land in everyone’s inbox.

Here are a few examples.

I work on multiple projects with a number of different clients. When I make notes, or update the status, or write meeting minutes, I put them on the company wiki rather than keep them on my local machine. My manager might be interested in how often I’m meeting with a specific client. The product team might be interested to learn which clients are using Kubernetes. I wouldn’t share most of this outside the company, but internally it’s not confidental.

If I build a small demo for a client or play with some software, I push my toy project to GitHub. Depending on what it is, it might be limited only to my team, more widely to any of my colleagues or it might be public, but I’ll be as open with it as I can.

If I’m researching something, a new technology or how to implement a particular use case, I’ll put my notes on the wiki.

If I ask a question, I will typically ask it in a public Slack channel rather than as a direct message.

An important aspect of all of these things is that I was already typing the information. The only difference is that instead of keeping it on my local machine or sharing with individuals, it’s “public.”

It means that other people can see the current state of my projects without asking for it. This immediately benefits me because I’m lazy. But in a distributed environment, where timezones are significant, it can save everyone time.

Asking questions in public can get answers from unexpected sources. That new guy might have experience you didn’t know about. Someone in a nearby timezone might get you an answer hours earlier than you were expecting. The person you would have asked might not know or be on vacation.

There are downsides, of course. If you ask a stupid question in public, then everyone will see how dumb you are. Your notes might document a terrible, old technology that you shouldn’t be using at all, or your solution might fail horribly.

But here’s the thing: you’re not stupid. I bet other people have a similar misunderstanding. And the journey itself can be interesting. As Kepler noted:

“What matters to me is not merely to impart to the reader what I have to say, but above all to convey to him the reasons, subterfuges, and lucky hazards which led me to my discoveries.”

Those “lucky hazards” might help other avoid the same mistakes. Can we fix the documentation? Include it in the company induction? Is there a blog or a conference talk in it?² These steps may require a little extra work but they have benefits for everyone, from future you, to your colleagues and your customers.

The other thing is that it’s a good strategy for getting the right answer. People can be too busy to respond, right up to the point where they find that Someone On The Internet Was Wrong. People are more likely to offer to fix your work more readily than they will be to come up with a working solution from scratch.

What if no one looks up your status updates? What happens when your notes go unread? Well… nothing. You were already writing the notes and no one except you read them. Worst case, you’re exactly where you were.

In short, this is a terrible process if you want to be seen as being right all the time. However, if you value getting to the right answer and acknowledge that you’re a fallible human, if your ego can handle it, then I find it works well.

And, best of all, there is no need to speak on a podcast or to have a website.