If we turn the clock back a year, I would be busy packing up the minivan and starting our long slow trip down to southern Alabama through some pretty nasty storms. Later that evening, I’m going to write a small Python word game solver script that ultimately evolved into the code behind this site.
Like many developers, I’d had dreams of building “a product” of my own. I even had a couple of piles of code sitting around from various attempts over the years. Most of these were built around pretty solid concepts – the sort of ideas you could walk into a room and pitch to rational adults. Projects like games, a stock analyzer, and data tools. I’m imagining the “startup weekend” pitch for Hyenas:
“Team, we intend to become a market leader in the scrabble helper, hangman solver, and boggle cheat space. This site will offer illicit services to a large audience of low-revenue visitors and entertain them for hours on end.”
Keep your cell phone handy: the reaction footage from the MBA’s will be comedy gold.
But yet… unlike all those “better” ideas, this project actually got built and was launched. By the end of the weekend, we had a nice collection of command line Python programs. On Monday night when I got back from vacation, I took the hangman solver function and used the bottle.py web framework to turn it into a simple web service. The front end of the site was an HTML page, dressed up with some JQuery. By the end of the night, I had version 0.1 of the hangman solver. Two weeks later we were live on a shared hosting platform. We continued to tweak the site’s visual design and “analysis engine” over the next month before we did our public launch in January, via a Facebook post.
That was the start, not the end of the story, as those of you who have built websites are well aware. Once we were live, we had to set up all the supporting elements: Google Analytics, server monitoring, a WordPress blog, and social media. We launched with almost no awareness of SEO and “Google-friendly” site design: we spent a lot of time during early 2012 trying to figure this out. Our focus started slowly shifting from the easily measured problem of “is this website running” to the much murkier challenge of figuring out how to grow an audience and make our users happy.
Along the way I learned a lot about Python and became a better developer in general. I’d been using Python for statistical analysis and simulation modeling for several years; this project forced me to learn the basics about a much wider site of modules in the Standard Library. I was presented with a series of problems to solve using Python, each of which had a tangible incentive for solving them (eg. less manual work, cool features/insights). Running a site also gives you religion around best practices like version control, commenting, and proper design. You’re forced to live with the messes you create!
Thus far, the project has been a success. We built up an audience of regular visitors, who click on enough ads that the site is self supporting. One nice aspect of the project is that our incremental cost of building new stuff keeps dropping: we now have a paid-for server and some SEO firepower to give new material a push. All of this from a project that would be laughed out of the room at a startup weekend…
In retrospect, I’m not surprised it worked. The secret sauce is that the whole project has always been small and crazy. This let us avoid many factors that kill serious projects.
Drawing from one of Paul Graham’s essays (How Not To Die), most side projects don’t die because they were “beaten in the market”, they die because the founder got busy working on something else. Unless you are wealthy with no family responsibilities, your side project automatically comes second. I’m not advocating any other set of priorities, by the way. If you want to be successful, you need to structure your project to power through these distractions. Here’s how we accomplished this:
- Focus on Utility First, Then Presentation: My goal is to walk away from every coding session on a new project with a tiny useful tool which solves a real need that I can use immediately. Don’t worry about scope, making it look pretty, or commercial potential. Crude scripts work great: most of my stuff starts as a simple 5 – 20 line Python script that automates a manual task. You can knock this out in a hour or two. Now… go use that script!
There are three productivity ninja hacks hiding in this picture. First, you are limiting your work session to an hour or two, boosting the odds you will actually write code: everybody can find an hour if they look hard enough. Next, by limiting the scope of the work to a single usable function point, we increase the odds of completion. Finally, by building something you will use regularly, you are setting up a reminder to finish the app. The latter is pretty serious productivity kung-fu for things like admin interfaces: by making something both seriously useful and painful to use, you maximize your incentive to polish up the visual design and supporting features over time.
This isn’t necessarily the most productive approach to writing code. I’ve found that I do my best work when I have an uninterrupted block of 6 – 12 hours to spend coding. However, this approach seems to work fairly well when you can’t dedicated large blocks of time to spend working on your project due to other obligations!
- Don’t Waste Time “Strategic Planning”: I actually tried to define a “strategy” for our offering in the early days. Our target audience was going be scrabble players, acquired by going viral on social media, and most of them will use mobile phones. What a pack of fatuous BS.
Most of our traffic is for other games, is generated via SEO, and my best commercial audience actually uses desktop browsers. I never knew any of that until we actually launched and watched the public reaction…
- Share Early: I’ve spent too much time working on high risk corporate system stuff, so this was a big learning curve for me. Unless you’re actually accepting money or touching personal data, the consequences of being hacked or a system crash are generally pretty minor for a weekend project. The motivational value of seeing real live people on your site? Priceless…
The acid test of this principle occured in mid-April, where we had a fifteen hour outage when I was out of the country. It began 15 minutes after the start of a day-long business meeting (without cell service) and continued until I got back from watching hockey that evening. Net cost? Zip. The server was rebooted over hotel wi-fi and the monitoring script was fixed that weekend. We were back to our usual traffic levels within a couple of days.
- SCRIPT ALL THE THINGS! Your goal as a developer should be to eliminate your involvement in as many areas of the project as possible and streamline the rest. Most of this site runs on automated scripts: everything from server monitoring to administrative decisions. I can and have walked away from the site for weeks at a time.
Another nice thing about scripts is you can usually recycle them on future projects, permanently increasing your productivity…
StealReuse Code Shamelessly: This one is simple: you have finite resources to get a side project delivered. Don’t waste your energy reinventing the wheel. Remember, anything that prolongs your delivery of a working product increases the risk you won’t complete the work and launch.
There are many wonderful open source projects out there that solve 90% of the problems involved in website development (WordPress, Jquery, Django, bottle.py, others). Unless your goal is to replace WordPress or Django, don’t waste time redesigning them….
- Take Delight in the Absurd: Anyone can go build another content management system, photo sharing site, or social networking service. Unfortunately, that usually means that everyone will take a shot at it, pitting you against a flood of competitors. But for weird stuff like building a worm farm designer? Craft Beer analyzer? Consignment sale manager? Not only is it much more memorable but you’re much more likely to discover a little niche that you can own and enjoy…
I suppose a final tip might be to pick something that you love – either in the content or the process of developing the site – and center your time around that activity. That helps you keep going through the early stages of the work, where you’re plugging a ton of time into a site or feature that only gets a handful of people per day. Because time will suddenly become your friend once you get moving: old sites have more credibility with Google and it is often much easier to version / modify your existing code than build new stuff. Love helps you power through the tough spot.
For our regular readers, thanks for a great first year! We look forward to helping you beat the cheetahs and laugh like a hyena for many years to come!
If you liked this article, share it!