Get Your Program out There

Launching your project to the public can teach you more about programming than the actual coding itself. Therefore when you build something in your journey of learning programming, it is important to release it into the wild.

Nothing motivates us more than the fact that some other human beings are actually using your program. When they do, we get a rewarding feeling and an urge to continue with our journey of becoming better engineers. I mean our software is probably not To Kill a Mockingbird or anything, but it can interact with people to solve real problems, and in the process can have an actual impact on the world around it.

We do not have to invent a groundbreaking program to reap such a reward. Rather, we can do it any time as long as we are willing, even as beginners. For instance, I made the first commit to a Ruby library has_friendship four years ago when I first seriously started teaching myself to program. To my surprise, it has attracted thousands of users and was forked by many individuals and organizations, probably helping them ship their own software.

No Room for Ego

Despite the looming prospect of having a positive impact on the world, time and again I refrained from actually publishing my programs. The reason was that I was nervous. I was nervous about having my bad code judged by strangers, or my buggy program causing frustrations in someone else’s life. In retrospect, I had an unhealthy habit of attributing too much of my ego to the programs I wrote.

We must put our ego aside and share our programs with the world freely because the scrutiny of the public eyes is the best teacher you will get. Bugs will be found and the designs will be questioned. Sometimes the feedback will not be in the nicest form possible. For instance, I received a lot of flak from publishing stuff like k_means_ruby years ago. Some comments were hurtful because I was not really used to taking criticisms for my code. But the criticisms were legitimate in that my program was implemented wrongly and was over-engineered.

Fear of being judged should not stop us from publishing our work. In fact, we should look forward to getting judged because feedback from a stranger is as real as they get. They are different from those of friends or instructors in that they come from real users and can be brutally honest. Surely we can take them or leave them, but while processing those feedback we can learn real lessons.

Another reason to put our ego aside is that, most of the time, no one actually cares about your program. Often, the problem will not be that you are getting smashed by opinions of strangers, but that no one bothers to judge your work. Everyone is busy with their own stuff and usually, no one really has time to devote their attention to your little programs. In this light, having your work criticized is a luxury that you should enjoy, not something you should be afraid of.

Ways to Get It Out There

How can we share our work effectively with the world? The following worked well for me and gave me a lot of opportunities to learn.

Open Source and Collaborate

The most effective way to get feedback for your program is to open source it. That way, other people can see the inner working of your program clearly and comment on it. Moreover, you can collaborate with well-meaning strangers if you are lucky enough. In either case, you will be able to get someone else’s perspectives on your program and expand your view.

For instance, I learned a lot from open sourcing mantra-cli and collaborating with dozens of strangers around the world. At first, I made the program to scratch my own itch by automating some tedious tasks. After a while, a thought entered my mind that this program could be useful for others with the same problem, and I put the entire source code on GitHub.

Indeed I was kind of self-conscious about the code quality because I had written the entire thing solely for myself and made little attempt to make it presentable. At any rate, it ended up helping quite a lot of people in the community and I transferred the repository to an official organization for the community it was helping.

Maintaining your open source projects with other people gives you a chance to be mentored as well as to mentor. Time and again mistakes will be corrected by pull requests, and decisions will be questioned by many people. But when you are keeping your program to yourself to your chest, none of those will happen.

Give Talks

Presenting your software to a group of people teaches you how to communicate your technical ideas clearly. We often overlook communication skills and focus solely on coding skills. However, we must strive to develop abilities to explain our technical ideas because a huge aspect of software engineering is communication.

Sung giving a talk
Me at the Graph Day conference in SF

In real life, we build software together with other developers by grooming requirements and finding solutions. It is far more helpful to be able to communicate solutions succinctly and professionally than to be able to use some frameworks or recite data structures. And explaining your technical thinking correctly in person is more challenging than it sounds and needs practice.

What helped me develop my communication skills was talking about my programs in front of strangers at technology events. As you can see from the collection of some of my talks and videos, there is no shortage of opportunities to give presentations because technology communities are everywhere. I have been able to present my software in Sydney, Hong Kong, Singapore and San Francisco, sometimes in a small room or sometimes in a huge conference.

A good way to get started is to seek opportunities in your local technology meetups. Get in contact with local organizers and propose a talk. Most local communities are constantly looking for talks and organizers will more than appreciate your proposal. When you are traveling you can also find communities near you to present and exchange ideas with local developers. These endeavors will help you hone your technical communication skills that can be useful in collaboration and also in interviews.

Find Your Community

Become a part of a community that your work is related to. That way, you can talk about your software to relevant audiences who are inclined to listen to you. Because you share interests with everyone else, people are going to be much more willing to help you out by giving feedback. Also, they will be happy to use your software because it is likely that you are solving similar problems that people in the community are experiencing.

Meteor global hackathon
Doing a hackathon with fellow Meteor users in Sydney, Australia

In my case, the Meteor.js community helped me learn JavaScript in more details. As a beginner, I found the framework interesting and became very active in its community for some time. The reason that the community was helpful was that I was able to collaborate with like-minded people to make a lot of shitty stuff that worked, one of which even won the official global hackaton.

There is bound to be a community with which you share some technical inclinations. Maybe you are interested in some programming languages or frameworks. Find others who share your interests and get your software out to them.

Your Program Yearns to Speak

We forgo potential learning opportunities every time we closely keep our programs to ourselves for fear of being judged. But those missed opportunities are deplorable because those programs that never see the light could have added a unique voice to the world. Therefore I think we need to spend just as much energy on launching our programs as writing them. If we only go so far as to write a program, we will never learn what it could teach us more.

Programming is more than writing code. Getting your software out there is a first step to learn about other aspects of programming. Your program yearns to speak and educate. You need to listen to what it has to say, and the only way is through the opinions of those that use it. It would be tragic if we end up suppressing its voice in the name of our ego or a singular focus on the writing of code.

So get your software out there. Let it fly. Or let it crash and burn. At least it will have traversed the sky leaving its own mark on the world. Either way, it will talk to you, in its most idiosyncratic voice possible, about things that you did not know. Whether that voice is heard is up to you.

Dnote newsletter

Get intersting stories about privacy and note-taking, written by real people. Follow Dnote's journey.

No spam. Just stories. Unsubscribe anytime.

Sung Won Cho

I am making Dnote to protect our privacy.

Sydney, Australia https://sung.io