Ever shipped a pet project to production?

Lessons learnt from going the full mile.

Pet to Prod — Illustration by yours truly

As someone who loves experimenting with new ideas and tools, I find myself working on side projects quite often. Sometimes for a day or a week, then I quickly loose interest and move on to the next burning desire. The projects don’t really get abandoned, rather, I convince myself that the necessary skills have been learnt…but this is not true!

A few days ago, I was working on this simple Go project that automatically tags a picture using classification engines powered by Clarifai. After successfully setting up the API handlers and user interface, and confirming that everything works on my local machine, the desire to call it done and move on to something else rose again…but not this time, this one was going all the way to production.

How do you hone good skills if you continuously practice bad form?

A simple Go app, a few hundred lines of code, with only one job…how hard could it be? Well, quite hard. There are a myriad of things developers hand-wave with the “you would not do this in production, but this is just an example” excuse. You’ve probably seen a bunch of tutorials where API endpoints and secrets are hardcoded into the program. How do you hone good skills if you continuously practice bad form? So, I was going to do things the right way and take this project the full mile. Ended up learning a couple of lessons.

Lessons Learnt

Tagifai | What's in your photo?

1. Demo or it didn’t happen. Writing an article about what you did is kinda good. Perhaps with videos showing how it works. But what should be the crowning moment of your efforts is actually getting it in the hands of real users! Side projects often solve a user problem, so if your ideal users cannot engage with your side project, you failed. And no, a Github repo is not enough because the regular Jane will rather not clone a repo — even if she is a developer.
2. Clear documentation is not optional, it is mandatory. Assume the whole internet (well, maybe a few friends) will be checking out your work, the least you can do is a detailed README outlining the purpose of the project and how to get it running. Being a small project is not an excuse, that should actually make the documentation easy.
3. It is not deployable code until it is running in production. How do you know your magic port on your local machine will be free in production? You don’t. Environments like Heroku randomly assign ports to your process (by default), is your program written to account for this? Basically, there are multiple factors that can make your perfectly running local application a brick in production, and there’s only one way to find out.
4. You face the karma of platform immaturity. Compared to platforms like Node, Go is still an infant. Node has established tools, documentation, and tutorials on how to do almost anything on platforms like Heroku. I found the lack of updated guides on deploying a dep-based Go app to Heroku quite frustrating. You don’t see this part if you never try to deploy your app.
5. It reveals gaping holes in your knowledge. It is one thing to write code, and another thing to deploy it. There are conventions, best-practices, and tools (heck even git commands), that you might be totally oblivious to until you try to send you program to production. Some organizations have a devOps team (or that one person who knows all about production :), so “mortal” developers are far removed from the realities of deployment like managing SSL certificates.

Action Items

Clearly, going the full mile with a side project is demanding. So, to improve my chances of success, I will be tackling future projects with these guidelines.

1. Only work on projects that have a well-defined user. In other words, they do only one job well.
2. Spend a day scoping the entire project based on your current experience with the required tools. If you can’t ship a Minimum Viable Product (MVP) to production in 2 days, you should probably pick something smaller.
3. Develop code with the awareness that this is a bonafide production application. That means good documentation, proper security measures, and defensive programming.
4. Evaluate the success of side projects by getting a few target users to try it out. This could be your buddies at work or followers on twitter.
5. Keep every side project running and functional. Avoid having a Github repo that “used to work” 2 years ago (guilty of this myself) — if you won’t support it anymore, then it is best to take it down.

And that’s it! If you enjoyed this article, please give me some claps so more people can improve their side projects. Perhaps you have some other lessons to share, do leave a comment. Thanks!

Ever shipped a pet project to production? was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.