I remember my first substantial programming project like I started it yesterday. As a 16 year old newbie hacker, I had only dabbled with programming: most of my coding had been little toys, like an implementation of Zeller’s congruence, or a few bouncing balls, or other simple math equations or physics simulations. But one day I saw a friend of mine write a web app with PHP and MySQL, and I was hooked. It looked so hardcore, I immediately wanted to play.
Programming Play?
Programming play is what incipient hackers do to learn programming. Like children roughhousing to learn where the boundaries are, like dogs playing to show dominance, new hackers play with code to get more comfortable with concepts, to learn new things, and to show off their newfound skills to their friends. Programming play (some wiser than I am call it deliberative practice) is crucial to the development of the programmer.
Engaging in programming play – even once your skills are on the path from imminence to eminence – is the mark of the truly enlightened hacker. When a developer interviewer asks you about your side projects, what he or she really wants to know is does this hacker play? When other hackers ask for your github handle, what they really want to know is how does this hacker play? To know these things is to understand the hacker.
Hacking Like It’s 1999
Back to my story. My first project was an online editing system for Radicals, my high school math magazine. I picked up a PHP/MySQL book from the local library and wandered through it, picking out the useful parts (how to make a login system, how to set up a database table) and ignoring the useless parts (UML diagrams, seriously?) Before long, I’d surreptitiously set up a server in my school’s computer lab running my system. Success!
Playing with web apps seemed to be common amongst my hacker peers. Older hackers had cut their teeth on games like Breakout clones, or writing MUDs. Among those my age, writing a bonafide web app that actually ran on a server somewhere was a mark of distinction. I would play with web apps to various similar ends several times over the following few years.
In college, I began playing outside the world of Web 1.0. Frustrated by the unconscionably execrable iPhoto 1.0, I decided to write my own image browser. Armed with rudimentary knowledge of Objective-C from playing with the developer releases of Mac OS X, I jumped into drawing, caching, and pre-rendering thumbnails. A few weekends later, again, success. Graphics-related projects and games were and are still perennial subjects of hacker play.
Later on, my play became more specialized. In 2006, a friend and I wrote the Pajama Programming Environment, a now-defunct app that let programmers write simple flash sketches using a Processing-like language. It included a real-time network channel to allow communication between sketches. That network channel would become the basis for EtherPad‘s real-time communication stream. Without play, it wouldn’t have happened.
The Facebook platform & iPhone apps
The year 2007 saw two new highly attractive targets of programming play. In May, Facebook launched their app platform, and all those kids who were playing with web apps started writing Facebook apps. And why not? Being able to customize your app to your user’s identity is powerful.
Then, in October, Apple announced that it would be offering an SDK for iPhone apps. And with that release, the iPhone became another target for hackers – or at least, those hackers with Macs.
iPhone apps and the Facebook platform represent logical extensions of desktop apps and web apps, respectively – though superficially they may seem like new phenomena. At the technical level, the Facebook platform provides web apps an identity interface, and the iPhone is effectively a small computer with a touch interface.
But the major innovation here, and the main appeal, is not technical: it’s the platform for distribution that Facebook and Apple’s App Store provide. Facebook and the App Store make it even easier to show off the results of your play to a wide audience, by attaching your work to something your non-technical peers had actually heard of before.
From Libraries to Services
Since 2007, we’ve seen an explosion of new APIs and web services that allow programs to interact with the real world. Companies like Foursquare, Yelp, and Google provide listings of local businesses. Twilio lets programs make phone calls and send and receive text messages. Amazon’s EC2 rents out servers by the hour, and its S3 service rents out data storage. Google’s App Engine lets programmers worry less about scaling their applications to large user bases. New frameworks like Node.js, libraries like socket.io, and platforms like Heroku make it even easier to deploy highly interactive web applications.
And now, the always-online nature of smartphones means that iPhone and Android apps – the new “desktop apps” – also take advantage of these APIs and services.
All these APIs and services make it easier for play to have a real impact. Prototypes of apps like followupthen.com can be created as programming play in short periods of time. That means it’s easier than ever to try things out – and easier than ever to see what works and what doesn’t work, making startup methodologies like Lean Startup easier to implement.
The Value of Play
Play is often a programmer scratching a personal itch, but real projects and companies come out of play more often than not. Programmers are expected to play with APIs and services because those services are increasingly allowing better apps – both web and mobile; most companies (and especially startups) want to hire programmers who play with the latest technologies. And platforms like Facebook and the iPhone and Android app stores enable the results of play to get the kind of distribution they’d have killed for in the ‘90s.
Programming play helps programmers make new connections and generate new ideas. Apple’s Steve Jobs frequently cites a calligraphy class he dropped in on at Reed as the reason the Mac has real typography. George Bernard Shaw says it best “We don’t stop playing because we grow old; we grow old because we stop playing.” The lesson here is never stop playing.
It can be difficult to balance programming play with “productive” work, especially at a start-up or on a high-pressure team. But I, for one, am very much looking forward to playing again!
This post was inspired by a recent conversation with my friend and fellow MIT/Google alum Akshay Patil.
Comments? I’m on twitter.