Doing Less to Drive Doing More

Over the last few months I’ve experienced a heightened drive to work on side projects and contribute to the open source projects that I rely on, more so than in much of recent memory. I’m not certain why I feel this way, maybe it is because I am entering a phase in my career where I finally feel confident in my ability to take my ideas from concept to completion. Maybe I’m just looking to stay sharp with skills that I don’t have the opportunity to use in my day job, or perhaps there exists some other deeper reason for this drive that I fail to fully grasp now but will reveal itself in time. Whatever the reason I’ve done my best to engage with this creative energy and take advantage of it to the greatest degree I could. I’ve developed and deployed a few new applications as a result (see my projects page for details), and I plan to continue to do so as long as I still feel the same push to create.

As I’ve been doing this work I’ve noticed a striking difference between now and past instances of comparable drive; in the past such productivity has resulted in small artifacts, unfinished work, and lack of fulfillment. I would work hard, excited to take a project from nothing to the 90% completion mark, but then I’d hit a wall of some sort, run across a snag in the process, languish in the frustrating feeling of not completing the project, and eventually abandon what I had done without ever getting it across the finish line. While annoying in the short-term, in the long run this pattern hadn’t bothered me greatly as I always found myself able to accept that each unfinished project was a learning opportunity, and that I had gained or refined skills from the time that I had invested even if I wasn’t able to push a product out to real users. In my current bout of productivity, however, I have been unable to convince myself that it is enough to get almost done: I have been unsettled with unfinished work and have felt a need to put out some kind of complete product, however basic it may be initially. I needed to push through the barriers that would have previously kept me from releasing my work for others to use.

In order to drive through the challenges I faced throughout the development cycle I knew I’d need some momentum. Every developer has felt the energy that comes from starting a new project: implementing quickly, seeing results, and iterating in short cycles. I have recently found that a tremendous amount of momentum comes from completing even the most trivial projects; this is the same sort of energy that drives my strong effort at the beginning of new ventures: the gratification of seeing the fruits of one’s labor drives further development. Deploying my work energizes me to continue to iterate, to improve, and to re-deploy: it’s a self-perpetuating cycle of productivity that I’ve found immensely powerful. I’d like to be more readily able to take advantage of this cycle in the future, so I have begun to reflect on the feeling at a more analytical level in order to begin to identify strategies for entering it more easily.

It has been said that results motivate action which in turn drives further results, thus initiating the cycle that I’m describing and experiencing. To start this cycle, then, one either has to experience results or spark action. In the case of software development it is challenging to get results without first putting in some amount of work (the code won’t write itself!), so starting with the work makes sense. This is the more challenging initiation point, of course, since one must temporarily work without the wind-in-the-sails feeling previously described. To combat this issue I have found the most success in recent times in setting very small initial goals for new projects, marking success with simple milestones that can be easily achieved in less than a single day of work. Completing these goals and being able to check the associated box off my lengthy to-do list yields a response that isn’t nearly as strong as a deployment cycle gives, but is better than nothing and can be just enough to get through the next milestone.

An example of my adopting this philosophy can be seen in the development that I’ve done on a new Google Chrome Extension. I was tempted to start with lofty goals consisting of beautifully styled UIs, deep integration with advanced browser features, perfectly best-practice compliant code, and more bells-and-whistles than you can shake a stick at. I still have these goals in mind for long-term improvement of the project, but had I set them up as “success criteria” for a first version I likely wouldn’t have published anything yet; as a result I wouldn’t have experienced the burst of energy that came with putting out a release. There is a real possibility that I then would have found myself in the familiar position of feeling as though I had a half-finished project, detracting from my overall excitement and depriving myself of the experience of entering this powerful motivation cycle. This is the trap that I’ve fallen in to in the past. In order to prevent this situation I forced myself to limit my to-do list to contain only the bare essentials for my first release, creating something just functional enough that I’d be able to get it past Google’s review system. I refused to allow myself to write down any ideas that didn’t fit into my bare-bones requirements lest I become intimidated by a long list of ideas that would not be necessary for initial publication. After I completed all the tasks on that short list, I promised myself I’d release what I had completed up to that point no matter how half-baked it felt. In the case of this project, my strategy worked. I was able to check every box in my short to-do list before the start-of-project motivation wore off, and as a result I published the extension to the Chrome Web Store.

I found that once I had forced myself to push the publish button I felt simultaneously satisfied with what I’d accomplished and inspired to continue to work towards larger goals. I had successfully entered the motivation cycle, all thanks to limiting myself at the outset of the project. Managing the expectations that I set for myself and keeping my ego in check had led me to a release, and however imperfect that release may be I consider it a vast improvement over being stuck with a 90% complete project that never sees the light of day. I’d thus encourage my future self, and any readers of this post, to examine their current to-do lists, re-evaluate goals, and ponder if you’re in a situation where you may benefit from doing the bare minimum: remember, you can always iterate, and having to put out a fast-follow v2 to fill in the gaps and address glaring issues is far better than never getting to the v1 point in the first place.