Hi, my name is David and these are just some of my words.

by David


I do this terrible thing where all of the screenshots I take on my computer just go straight to my desktop. As consequence, it constantly looks like a small tornado recently swept through my all my files. (Fun fact: the first—and as far as I remember, only—time I’ve been heckled during a presentation was when somebody caught a glimpse of my desktop and shouted: “You need more screenshots there, bro?”)

As I was cleaning my desktop this morning, it occurred to me how funny of a thing this collection of screenshots is. It’s like a mini time capsule dating back to when I got this computer, and I took the moment to relive some memories. Like the time my bot in an AI competition was about to go in for the kill only to shoot itself in the foot (I was o, playing x). Or how I noticed Facebook taking Graph Search visuals through a silly amount of iterations.

I’ve traveled through time, been abandoned by all friends, was immature once in a while. I miss Piki, and apparently I also missed trivia and whatever thing these tickets were for. I helped plan our trip through Europe and then got gouged on another trip. More recently, I tried my hand looking for MH370, took a nice vacation, and had a hard time trying to find my office in San Francisco.

Screenshots are not a sole endeavor; screenshots always have an audience of at least two. I took these all at some point to share with somebody or bodies, but hopefully widening the audience on here has been entertaining to you as well, taking a glimpse into my recent past.

Somebody should build a Timehop for screenshots.

06 July 2014

Disrupt NY 2013 Wrap-Up

No, that picture doesn’t do TechCrunch Disrupt’s hackathon this weekend justice. With presentations and awards lasting nearly 4 hours, an incredible 183 projects submitted to HackerLeague, and over 500 people packed into a grand ballroom in Manhattan huddled over laptops, it’s by far the biggest hackathon I’ve ever been to. So many props and thanks need to be given to Leslie at TechCrunch for organizing and emceeing such an event. A few notes and highlights of my favorite hacks below.

Foursquare Reppin’

Since I started as Foursquare’s Developer Advocate a few months ago, I’ve attended a decent handful of events giving API presentations and support, but this weekend was my biggest event yet. Still gotta work on my live coding skills, but if you want to see the little hack I threw together (do you need a haircut? the Foursquare API can tell you!), it’s up on GitHub.

Working through the night with some teams on API issues was surprisingly fun and was engaging enough to keep me awake (fine, the free pizza+beer they started serving didn’t hurt) (even though it was Coors). I thought I had been in touch with most teams there by the time I left around 3am (after tacos!), but I was amazed to find out that in a sea of sponsors that offered prizes (we didn’t) still a total of 17 apps used our API.

Blue Balls

While we didn’t sponsor a prize, we did offer up some balls to the lucky 60 hackers or so that nabbed them up. You can say they were a hit (skip to 4:17 for the good stuff) (and the pun).

What do you think we should give away at future events? More balls? Or back to shirts?


Below are some of my favorite projects for various reasons, either for using the Foursquare API or just being a badass hack. Kudos to all the teams that went and presented though. At first I was skeptical that just having a hack and presenting on stage got you two free Disrupt conference tickets… but I now see they’re totally deserved.


Obviously gotta give props to the first-place winning team. Rambler visualizes your credit card transactions over time on a map and incorporates the Foursquare API. Built by the fine folks at Plaid. Best of luck on the big stage, gents!

Learn to Drive

The amazing thing about this hack wasn’t its do-good mentality, utilization of text-to-speech, or its fancy statistical logging, but the fact that it was built by a team of high school students. This is the second hackathon I’ve been to now where high school students have showed up and done a really fine job. I think it’s such a good thing that we’re in a community that is inclusive and encouraging their attendance—I only wish I was part of such a community when I was still in high school. The kids (yes I can say that) behind Learn to Drive definitely deserved their win of overall runner-up and nabbing one of the GM cash prizes.

Out of Bounds

This was one of my personal favorites that used the Foursquare API. Out of Bounds is essentially a system that allows venue managers on Foursquare to place a physical light (which was 3D printed!) in the window of their shop that lights up whenever there’s a Foursquare special going on. The obligatory Vine demo:


Built by Isabel! Tracks your gas usage in your GM car, and finds nearby gas stations on Foursquare when it knows you’re gonna be low. The second winner of GM’s cash prizes, she pretty much needed a bodyguard walking in Manhattan with her purse.


Conceived by a few Grouper employees, Bounce is going to be one of those apps that I’ll actually use long past when the hackathon ends. It solves the “paradox of choice,” which in laymen terms means when I’m with a group of people trying to settle on a place to go for dinner, it’ll take 5 seconds, not 45 minutes. (I’m looking at you, Sid. I don’t really care that the service was meh once. I just want to eat.)

Hang Out Later

Don’t have time to hang out now with people who are checked in nearby on Foursquare? Just Hang Out Later. The app gives you a centralized location to meet up later based on where everybody is around you. I’m sure there’s another paradox of choice thing in here somewhere too.


Loved this idea. A dating service that hides your profile pic first and unveils it slowly as you keep chatting with your connected stranger. It unveils your pic section by section now, wish it did something with blurring too.


A winner of the AT&T challenge, Waterlog helps you consume less water. I particularly liked working with this team on tricky Foursquare API challenges (how do you do OAuth within Appery, hmm).


StopBy is Foursquare Explore in your GM car! Explore what’s around you without even pulling out your phone. But probably pull over first at least.

Script Injector

Not what it sounds like. If you have one of those “all you need is one line of JS!” services, Script Injector lets easily put it on any artibrary web page to demo. I can see this being super useful given the prevalence of these types of services lately.


Much thanks to Ak and Anna for showing up to help out over the weekend! Had a great time, Disrupt. See you next time.

28 April 2013

Sleepless in the City

Sample nights from my Sleep Cycle

Suffice it to say, this previous week has been one of my most sleepless. From Monday–Friday, I was taking Steve Blank’s Lean LaunchPad class and immediately after jumped on a bus to my last PennApps. Few notes and thoughts below.

Lean LaunchPad

Essentially a 5-day intensive block course teaching the most important ideas out of Steve’s book, this class aimed to combine students from Columbia Business School and Engineering and throw them head-first into the world of starting a company (“startup” I guess would be the buzzword). It was essentially a practicum in Steve’s customer development methodology, and most of the class didn’t evolve around refining an idea into a business, but rather “getting out of the building,” talking to potential customers, and learning from them. Don’t know the answer to a question? Talk to customers to find it. This makes a lot of sense, but even in just a weeklong course, it was easy to see how personal beliefs and passion can be distracting to this purpose and lead to discussions that weren’t necessarily founded in fact or what the customer wanted.

Products vs. Businesses

As an engineer, being in a class with a bunch of BSchool students was definitely… an experience. When presenting our idea on the first day (essentially listening off a bunch product features), Steve stopped us dead in our tracks and asked, “Who in the team are engineers?” We all raised our hands. It was that easy to tell.

A big realization I had is that as an engineer, I would be totally happy building a product (NB: not necessarily a “business” or “company”) even if there’s no hope of it making money—I don’t necessarily think many of my BSchool peers would necessarily have the same level of satisfaction as me. I’ve been so focused on products and users that it was a useful exercise for me to start thinking of things in terms of businesses and customers. There’s a very fine line here, and the whole topic may very well be just a large grey area with no black and white, but I do think there is a distinction. It boils down to something like this, a variant of which I told Steve was one of the biggest things I learned: Everybody on the planet can love a product, but if no one’s willing to pay for it, it’s not a business.

Breadth vs. Depth

As a team, we struggled a lot with the issue of “breadth vs. depth.” Should we make our product appeal to a large audience or introduce specific features to cater towards a niche market? The answer seems obvious now, but the answer is the latter. Catering to a specific market may destroy your schemes for world domination, but in the end, you’ll serve your customers better. And it’s hard enough as it is to get that right.


A scant hour or two after finishing up our team’s final presentation for LaunchPad, I hopped in a Greyhound to Philly to my last PennApps (I bought tickets too late and couldn’t get a Bolt. Never again.) There was an insane amount of people there: three entire floors were occupied with hackers making everything from a backpack inventory tracker to an app that removes dirty things from your Facebook. Our team hacked together a way to visualize your Snapchat network (obligatory plug to check it out and show your friends). My personal favorite was dead simple but made me giggle for a while: Big Data.


This was my first time really playing around with D3 and I started to get the hang of it after a while. Great resources I consulted: the canonical Three Little Circles, Scott Murray’s excellent tutorials, and a specific one on force graphs by Max De Marzi. I’ve always loved the functional nature of JavaScript and D3 really seems to embody this spirit.


Although the nights were sleepless, I can’t complain that much because my waking hours were spent with awesome people. Gotta give so much props to John, Angel, Ken, Mikey (LaunchPad) and Jasdev and Nishant (PennApps) for sticking it through beside me.

Now what am I gonna do with all this free time?

23 January 2013

Speaking About Speaking in Code

This past semester I had the privilege of teaching a class at NYU on basic programming skills and digital literacy, Speaking in Code. The school of Media, Culture, and Communication at NYU partnered with Codecademy to dream up this course and were somehow foolish enough to give me basically complete reign over the class. The experience eventually turned into one of the greatest and most fulfilling in my college career, and I just wanted to put down a few thoughts here both as personal reflection and to document publicly my experiences for anyone foolish enough to care.

Dewy-eyed college kids! Kinda sorta not really

“Digital Literacy”

The goal of the course wasn’t to turn a roomful of dewy-eyed college kids into software developers—its mandate was to improve the “digital literacy” of the students, who were legit enough in their respective fields in the media world, and many of them already with an undergrad degree. I thought this was absolutely the best way to frame the course. Meeting just once a week for an hour for 10 weeks, you can’t reasonably expect people with no prior programming experience to come away as full-fledged developers.

However, there are a few things you can expect them to come away with:

  • A better understanding of how it all fits together. Sometimes it’s difficult to remember just how confusing things can be when it’s not your day job. We explored “big picture” questions such as, “What’s the difference between the back end and front end?”, “What actually happens after you hit enter in your browser’s URL bar?”, “What is that HTTP thing anyway?”
  • Practical & hands-on coding experience. I’m a very strong believer in “the best way to learn is to do.” In each session, I would blabber for about half the time, then students would break out their laptops and go through a Codecademy lesson—where they arguably learned more.
  • An appreciation for new ways of thinking. I was reminded that programming isn’t necessarily just a mechanical skill, but actually an entirely different framework of thinking than what humans do in everyday life. When we write HTML and CSS, we’re defining content structure and style, and when we write JavaScript or Python, we’re giving a computer procedural instructions—these are completely strange modes of thinking for those that haven’t done it before.

How You Know People Learn

I think a great way to know whether your students are learning is to pay attention to their questions. Have they gotten smarter and more specific? As the course went on, I noticed students using more domain-specific terms such as “server-side” or “function” instead of settling for just “that thing.” Not only have the learners remembered these things, but they’ve synthesized them to an extent such that they can speak about the topics intelligibly and specifically.

Analogies & Other Things

Analogies fucking rule. What better way to explain an intimidating new concept (arrays) than to use something familiar? (a box… of cookies). I also stumbled upon something that was apparently funny and/or memorable: transition slides. Preferably punny ones. They’re great for breaking up a presentation, serve as a stopping point for questions, and allow people to take a breather.

Later on in the course, I also devised a way that hopefully students were able to learn better from. When reviewing syntax—a rather boring and cumbersome thing to trudge though—instead of just throwing up some code on the a slide and saying “this is what a function definition looks like,” my slides contained empty text fields where I could type as the students told me what to type. Arguably this is a better reinforcement and review technique than simply putting something on the screen.


As a casual narcissist, I love talking my head off and hearing my own voice just as much as the next guy (and writing long blog posts). However, public speaking isn’t necessarily my strongest skill, but I’ll admit now that the most simple solution that I often scoffed at truly works: practice (yeah yeah Leng, you were right. thanks.) And I don’t mean writing speaker notes or memorizing your slides, I mean literally running through your presentation aloud. Actually talking out loud helped me identify awkward spots in my presentation, helped work out timing, and further solidified the material in my own mind.


And so even though I and everyone else hated our meeting time at 9:30am on Fridays (and I missed a Lerner Pub here or there prepping for class), I’m glad we all stuck through with it. Of course, all this wouldn’t have been possible without Liel from NYU/MCC and Leng, Sasha, and the rest of the gang at Codecademy, so to them I give many thanks.

But I want to give perhaps the biggest thanks to the smart, ever-enthusiastic, and trusting (seriously, me?) students in the class who came ready to learn and braved each Friday morning with me. Congrats on making it through—welcome to the world of digital literacy! (Now don’t forget to submit your projects to me & Liel.)

(But like actually.)

13 December 2012

Next posts →