Exploring the Mythical Weekend Coding Project
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Recently, I decided to give up one of my weekends and see if I could build an entire working product from scratch. If you're like me, you have a lot of ideas rattling around in your head and far too little time to realize any of them. Some seem like world-beaters; others are interesting asides that would probably delight a niche audience. Regardless, I can't shake the feeling that the world—and certainly I—would be better off with these ideas material in reality (and, perhaps more importantly, out of my head).
I'll give away the ending: I succeeded. It took me roughly 16 hours to plan, build, and launch my idea to the world. And then, there was the anticlimax.
But before we get into that, let me retrace my steps over a grueling, frustrating, and wholly satisfying two days.
The Idea
The easiest part of the whole process was the idea. Not only do I have far too many of those available, but at any given time I'm also sitting on a pile of partially built prototypes. They currently number in the twenties and were variously built at airports, hotel lobbies, conference venues, and at any other time that I imagine the rest of the population spends at the beach and on other healthy activities.
If you hack on open source or your own startup ideas, you know exactly what I mean. Many of these projects will never see the light of day, but there is a primal, irrepressible need at the cellular level to try.
I picked the one that I've been thinking about most recently, and I opened my code editor. As a lark, I decided to put this up on Twitter:
Attempting "weekend coding project" Goal: working app in 2 days. Will I succeed? Will I fail miserably? Watch this spot for hourly updates! @dhanji
The Journey
There was quite a spirited response, plenty of encouragement, curiosity, and some snark for good measure:
@dhanji It'll kinda work but then you'll never finish it really is what usually happens. @dosinga @dhanji hashtag please @j03w @dhanji Wats the app? Wat technologies u using? @AalasiAadmi
I hadn't planned to put anything on Twitter, and I certainly hadn't planned on anyone following me through two days of blathering on about obscure compile bugs, PEBKAC errors, and mostly simple RTFM whining.
This was an unexpected boost to my productivity and cheer. It turned into a game: If I ran into something frustrating, I cursed and swore on Twitter while my friends cheered me up or brought me back down to earth.
Feeling a lot slower than I normally do with this setup. Waiting for that boulder to cross the crest of the hill #weekendproject @dhanji @dhanji perhaps it's all the tweeting slowing you down :D --private--
If I achieved something, I could immediately shout it from the rooftops and be greeted by a wash of enthusiastic replies. This fact kept me engaged and determined to see the project through. As easy as it sounds, keeping your focus for two straight days is extremely difficult and tiring. If you don't believe me, keep a count of the number of times you're distracted during a normal workday. At an office, people come around for coffee, chat about their weekend plans, talk about paperwork they need done, and so on. At home, there are plenty of other distractions: roommates, children, chores, and what-have-you. Even when left completely alone, we're relentlessly distracted by all those blogs to follow, YouTube clips to watch, and Facebook and Twitter updates to read.
Setting all this distraction aside and concentrating on a single task for even a day is an incredibly intense activity. I think that the brain is better suited to processing a variety of inputs over time and periodically being given the freedom to wander. Processing on one task exclusively is thus brutally exhausting.
Taking microscopic breaks to tweet my progress and receive reciprocal cheerleading was invaluable. Engineers from Heroku and MongoLab even discovered what I was doing and chimed in to offer their support:
@dhanji Glad you'll be checking us out. Definitely email us at support@mongolab.com if anything comes up. @mongolab @dhanji DM me if you need a hand with anything Heroku-related. @obfuscurity
This encouragement took hardly any effort on their part, but when I was sometimes frustrated and ready to discard Heroku for Amazon Elastic Compute Cloud (EC2) or Mongo for PostgreSQL, I thought twice—and I'm sure I would have been less willing to stick it out without their encouragement.
Testing
When you're under the gun, the first thing to get tossed out is testing. In a small, inconsequential project like this, it isn't really a problem. In fact, skipping tests really reduces your drag coefficient when you're trying to fly through a set of tasks, as I was. (This makes for a rather dangerous drug, though; many engineers take it to mean that the tests themselves are either unnecessary or unimportant enough to write during the proverbial "crunch time.")
I did stumble once or twice, however; and here tests were very useful. Not in their traditional role of protecting well-honed code against regressions from newer, rawer additions—rather, in the form of test-driven development (TDD).
TDD is actually a wonderful tool for probing the behavior of an API or library. You get to script very specific "what if" scenarios that would otherwise remain in the realm of idle speculation. Specifically, I wasn't very familiar with the details of MongoDB's Java Driver, and I was able to validate my (apparently faulty) assumptions trivially with a few simple tests.
After struggling with puzzling behavior late on Saturday night, I gave up, frustration at full tilt. Coming back the next morning, however, a methodical, reasoned approach, tight along the rails of TDD, worked beautifully. I solved in minutes what had thwarted me for hours just the night before.
By no means am I advocating TDD as a religious practice. I wrote a grand total of four tests, and I stopped writing them as soon as I had decent visibility into my component of interest.
Lessons
So here's Pasteboard, in all its glory. It's a pasteboard—drag pictures onto it from the desktop and share the pasteboard via URL. A fairly simple concept, but it was a lot harder to realize than you might think. Of course, I wasn't expecting Google or Facebook to beat down my door on Monday morning, stock certificates in hand, but I wasn't sure what I was expecting, either. People seemed genuinely to enjoy using it. I was pretty much done with it—after 16 hours, I didn't want to see the code again, or think about the program's future.
So what could I take away from this experience? On reflecting a bit, I realized I could take away a great many things. They fell broadly into two categories:
- Things I would have done differently
- Techniques I would repeat because they worked so well
In the latter camp were things like Heroku, mongoDB, and my approach to testing. In the former camp, however, I classified the following:
- No login restriction (and no Twitter sign-in).
- Allow anyone to paste pictures on any board.
- Get rid of commenting—it was hardly used.
- Focus more on picture resizing and rotation.
Do you notice what's interesting about this list? All the items are product features—if I had a do-over, they're things I would have changed about the product in the first place. Whereas my assumptions had been validated nicely in technical matters—choice of platform, storage solution, and so on. In hindsight, this pattern is fairly obvious: My expertise is in engineering, so I'm much more likely to make good decisions about engineering matters. However, I had no prior experience building a pasteboard, so many of my product assumptions were wrong.
This was the single most important take-away from my project. Your expertise is almost never in the product that you're building (even if that's an engineering tool), and you gain that expertise only through a real-world test of your assumptions. Just 50 people on Twitter giving me feedback was more valuable than all the deep meditation and prototyping I've done about this idea over the past several months.
Conclusions
My weekend project will never go beyond this little experiment. Nor do I need more—I've seen it out in front of real users, learned some valuable lessons, and (more importantly) gotten it out of my system. I had ups and downs and found a good process for working through problems both technical and motivational. In a sense, this was a micro-startup experience, fast-forwarded and compressed into a single weekend. It validated several of my assumptions about the product, and it exploded many more. I am thus armed with far better tools for future projects.
I encourage you to try this experiment, too—your ideas always look and sound better in your own mind than in material reality. One's own reality distortion field is stronger than anything else. Once an idea takes form in the real world, however, your perspective will be very different. Often you'll find that an idea isn't really as impressive—or particularly distinctive—as you had hoped. But in the process you may discover things that truly are both impressive and distinctive.
Read Dhanji Prasanna at http://rethrick.com/about or find him on Twitter at http://twitter.com/dhanji.