Ever since I started programming and discovered the open source world, I confess I’ve been a little obsessed with the elite developers in our communities. People who lead large open source projects (and often many of them) or direct large teams commercially. What is about them that got them to where they are? The software community has an abundance of advice and support on how to become a better developer, how to progress your career, and develop personally; I like to think programmers are pretty good at self-introspection and closing their own feedback loops. So amid a sea of extremely qualified professionals, what does it take to lead and create successfully?

To answer this question, and because I have a general curiosity around the topic, I set up a podcast, Distinguished Devs. Talking to top developers has been fascinating, and I’ve learned more than I thought was possible when I started the podcast. So I’d like to share some of that knowledge in this article.

What’s the common factor?

After interviewing several developers, a pattern started to become clear: great developers share a lot. This takes different forms for different people, but is very often a blog. “So what?” you might say, you would expect successful people—“thought leaders”—to use their position and platform to share their own ideas and projects. But the interesting thing is that for many top developers, their sharing mindset came before their success, and was the direct cause of it, not the result of it.

Take Jeff Atwood, for example. Jeff co-founded Stack Overflow and Stack Exchange and went on to later found Discourse. The reason this all started is entirely due to his blog, Coding Horror. 

On my podcast, Jeff tells the story of how one day he checked the stats on his blog and realized he had 40,000 subscribers. He’d been sharing his thoughts on software and a little bit of everything else since 2004, and he realized he wanted to do something with the energy and following that he had. After reaching out to Joel Spolsky (who also happened to have a very successful blog, joelonsoftware), they started Stack Overflow.

Without the critical mass of users from their blogs to kickstart Stack Overflow, its fate might have been very different. But more than that—the idea would never have been realized at all if either of them hadn’t blogged.

For yourself, not the audience

One of the questions I always ask successful bloggers is: what motivated you to start?

The answer is always the same: I did it for myself. 

This is an example of survivor bias; those who start a blog with the aim of attracting a following will lose motivation and grow impatient with the short term results. Successful bloggers have the personal confidence and passion for the topic to document and share stuff they think is cool.

Miguel Grinberg, the author of the Flask Mega Tutorial (regarded by many as the top Flask resource) talks on my podcast about how the first installment received a single like and retweet on Twitter. Months of writing new installments brought little more engagement, it took years for it to gain traction. But it didn’t matter to him, because “I was having fun, following my interests, doing it for myself.”

Martijn Pieters, the world’s top contributor to Python on Stackoverflow, discussed on my podcast his motivation for answering the volume of questions with the quality he does. For him, it’s about curiosity and expertise. Quoting Eric Lippert (a core engineer of the Microsoft C# compiler, and also a blogger), he says “How do you become an expert on something? Well, find a pile of questions or a place where people are asking questions about your topic. If you try and answer each one, you’ll become an expert quickly enough.”

That’s not to say there’s no reward or motivation in answering questions to help others, just that the personal benefits of doing so often go underestimated.

The same is true for many successful open source projects, which often start out as personal projects, only to later be adapted for general use. When I interviewed John Leider, the creator of Vuetify, about how the project started, he initially built it just for himself to enable rapid prototyping of sites for his consulting business. “I actually never planned to release it, it was going to be a thing for me. One of my buddies at work was walking by one day and said, that looks really cool. After a bit of talking, he convinced me to release it as an open source project.”

From the outside, the idea of doing something for yourself, not the audience looks like the main benefits of sharing come from the network of people you attract, and the opportunities created by a raised profile, such as new jobs, consulting, project offers and speaking opportunities. While this is true, top software engineers have told me that this long-term benefit was never their goal—the act of sharing creates significant short-term personal benefit.

Public by default

Though it’s important to create things for yourself, this shouldn’t mean you keep them to yourself. Carsten Haitzler (AKA Rasterman), the creator of the Enlightenment window manager, started the project only for himself, simply because he wanted a prettier desktop environment. On a whim, he shared some of the screenshots online, and all of a sudden began receiving emails from people asking for the source code. Fast forward to today, and the Enlightenment libraries are used in millions of phones, desktops, and even Samsung smartwatches and smart TVs.

The key point is that whilst the motivation for any successful project has to come from within yourself, you shouldn’t stop yourself sharing it because it was never meant for an audience. This idea surfaces frequently when I’m talking to podcast guests, because it’s always surprising how people react. Whatever your work, you should embrace the philosophy of “public by default”.

Public-by-default means this: everytime you create something, learn something, or just notice something’s interesting, do it in public. This may seem daunting—writing blog posts, helping the community and transforming ideas from thoughts into words all takes time. But sharing is like a muscle, and by committing to a regular schedule, you become much more efficient. This consistency of volume is also key to reaping the benefits of sharing.

There are a number of reasons why the public-by-default principle accelerates your personal development so rapidly. Firstly, on a technical level, there’s an immediate feedback loop. If you’re answering questions on forums or online communities, considering strategy or contributing to open source, you have such a swift feedback loop that it’s impossible not to improve.

What’s more, the hive-mind of the internet has a habit of taking ideas you might have which are ok and turning them into something worth pursuing, adding value through different angles or directions. Blogs in particular are excellent idea generation platforms. I’ve had personal experience with this—as a freelance writer, some of my best leads for new pieces and learning opportunities come from comments people have left on my posts.

To truly embrace public-by-default, it’s not enough to share your successful projects and knowledge, but additionally to bring the humility to share your learning and failures. In general, it’s hard to argue with the sentiment that you think harder about everything you do if you’re going to share instead of just do it for yourself, no matter how trivial it might be. There’s a lot of value to be had from being public-by-default, and often in ways which we don’t expect.

Sharing makes you stronger

For top software developers, sharing isn’t a byproduct of their success—it’s often the cause of it. The reasons for this are many and varied, but having the confidence to share more, for yourself, can be extremely rewarding.

So the next time you make a weekend project, learn something or discover anything you think is cool, be sure to share it; you’ll be in good company.

The Distinguished Devs podcast is available on iTunes, Spotify, and other podcasting platforms.