Several years ago I decided to start collecting jokes.

I was inspired by this 2009 New York Times article quoting Robert Provine, a professor of psychology at the University of Maryland, explaining that “[w]hat makes a joke successful are the same properties that can make it difficult to remember.” Jokes are hard to remember because memory relies heavily on pattern-matching, and humor often arises directly out of breaks in our usual patterns.

So I made a conscious decision to remember jokes, much in the same way I made the decision to actively remember people’s names after reading Dale Carnegie. They’re both great party tricks.

Most of my close friends know my favorite jokes by heart; I habitually recite them in awkward conversational pauses, at parties, in bed. This one has been in my repertoire for years:

Did you hear about the two TV antennas that got married? The ceremony was boring, but the reception was great.

I still think it’s funny, even if my girlfriend doesn’t.

When my friends couldn’t supply me with enough new jokes to annoy other friends with at parties, I turned to my Internet pal Google for a little assistance.

Google can answer almost any question that comes up in conversation—who invented the zero, for example (long story, but big ups to al-Khwārizmī[1]), or when Paul Simon’s album Songs from the Capeman was released (1997, not that you asked)[2]. A search for “good jokes”, in contrast, turns upFuNNy JoKeS make life gOoD and HuMoRouS in the top spot, which gives us this gem:

We had grandma for Christmas dinner ?
Really, we had turkey !

This might be the most brilliant anti-joke ever written. Or maybe something was lost in translation.

Okay, the first result isn’t always the best. Let’s move on to #2, danggoodjokes.com. Each joke linked from its nearly illegible homepage contains one or more jokes along with some (usually conservative) commentary on just how gosh-darn crazy our world has become, complete with rainbow WordArt headlines:

[Image would go here]

Even when they are readable, none of the jokes are funny.

The third Google result, smileJoke, brings some modern “social web” flavor into the mix. smileJoke allows users to submit ratings for each joke, and apparently, all the jokes have a rating of 1. This is not surprising given the material:

My wife had gained a few pounds. It was most noticeable when she squeezed into a pair of her old blue slacks. Wondering if the added weight was noticeable to everyone else, she asked me, “Honey, do these slacks make me look like the side of the house?” “No, dear, not at all,” I replied. “Our house isn’t blue.”

Friends, these are the top 3 sources for “good jokes” on Google. I guess Google’s ranking algorithm doesn’t have a sense of humor. But the next time your girlfriend asks you whether her jeans make her look like “the side of the house,” you now know how to get the laughs.

The best source I’ve found is, surprisingly, the Jokes subreddit. It suffers from the usual Reddit demons—trolls, memes and misogyny abound—but some of the jokes are funny, which puts it in the top 0.001%. Recently, Reddit ranked this gem as the top joke of the day (revised for clarity):

Q: What do free healthcare and good jokes have in common?
A: Americans don’t get them.

Not bad. Still, the Internet disappoints when it comes to humor.

Why is it so hard to find good jokes? Humor is subjective, of course, but is it more subjective than, say, music? Google and others have used machine learning to solve problems that once seemed insoluble, to find patterns and meaning in vast troves of data.

How come no one has applied this technology to finding jokes that are actually funny?

Notes

1. Source: Wikipedia
2. Source: Allmusic

Paul Graham summarized a core tenet of internet entrepreneurship simply: “You make what you measure.” [1]

There’s something magical about putting a number somewhere you can see it every day, whether that number represents daily profit, new customers, or something else. Suddenly one wants to improve, especially when the metric is paired with a pretty graph showing one’s improvement over time. It becomes a game, and everyone loves a good game.

I’ve employed this tactic at nearly every company I’ve started or worked at, measuring as much as I can—then choosing key metrics to create a company-wide dashboard that I could look at every day. It’s remarkably simple and effective.

I got sick a few weeks ago and spent too much time in bed, lazily wandering the Internet, where I ran across a compelling video about the benefits of 30 minutes of activity a day. The kicker, if you don’t have a few minutes to watch it: 30 minutes a day of pretty much any exercise—walking included—has been shown to offer dramatic health improvements, in mood, sleep, heart health, and more.

I was convinced, and wanted to take action. A computer programmer’s life is necessarily sedentary, and I wanted to counteract the negative effects of too much inactivity. So I bought something that had been on my wish list for awhile, the Fitbit Ultra.

Fitbit is a small, wearable device that provides dead-simple measurements of your physical activity. It measures the number of steps you’ve taken, floors climbed, distance traveled, and calories burned. Fitbit also functions as a basic sleep tracker—when worn on your wrist at night, it measures general sleep patterns, including the number of times you awoke during the night.

After carrying the Fitbit around in my pocket for two weeks, I can unconditionally recommend it to anyone looking to improve their health. It’s been fascinating to see my physical activity throughout the day—and my patterns of sleep at night.

Counting the flights of stairs I’ve climbed each day has already encouraged me to skip the elevator more often at home. I often find myself taking longer routes while walking, or walking instead of taking the subway.

It really works.

That said, the device isn’t perfect. Right now it must have an optimistic idea of my stride, because its distance measures (and hence calories burned) are off by a fair amount. I’ve been meaning to measure my stride accurately but it’s difficult to do when you live in a tiny apartment.

Also, while the Fitbit can measure exercise like running and elliptical machines easily, it can’t measure activity that won’t trigger its pedometer, like swimming or using a stationary bike. Fortunately, the website lets you log your exercise and can compute calories burned for you.

It’s too early to say whether I’ll be as enamored with the Fitbit in a few months as I am right now, but so far the entrepreneur’s maxim has held true: “You make what you measure.”

If you’re trying to live healthier, try getting a Fitbit.

When I started my last startup, I kept quiet about my work. I didn’t tell anyone what I was working on, didn’t blog or tweet or promote myself or my apps.

I put my career in stealth mode.

At the time, I had several reasons to stay quiet. I wanted the freedom to explore multiple projects without the pressure of committing fully to one of them. I hated startups’ “About Me” pages, full of smiling people bragging about themselves in the third person. And if my startup failed, no one would know—I could quietly move on to the next project.

Five years later, I see this as a huge mistake, maybe the biggest one I’ve made in my career.

Because I have almost no public presence on the Internet, you probably have no idea that I’m a programmer (let alone a good one) unless you know me personally. Yet I spent most of my time from 2007 through 2011 writing thousands of lines of code, powering apps used by millions of people.

Now, most of that code is dead. Thousands of hours of my life, literal years of work—gone.

My cofounder and I wrote some pretty cool libraries, including:

• an iPhone table view markup language we called JSTN (JavaScript Table Notation, or Justin, a play on JSON, the JavaScript Object Notation)
• a simple command language to allow a server to dynamically control iPhone app flow, such as pushing a new ViewController, popping up an alert, etc (called SICC, pronounced sick, for Server Invoked Client Commands)
• many Rails hacks to allow seamless caching, distributed reads and writes, and database sharding

Some of this code lives on in the apps that my cofounder still runs, but nobody knows about it. Like most of my work from the past five years, it’ll probably languish and eventually die. But If we had open-sourced any of these libraries, I’d wager that at least one (and possibly more) of them would still be living today, because they solve real problems.

I recently left my job to start a new startup. One of my goals is to open-source as much work as I can, because I want my code to be used and improved by others. And I’ll write about what I’m doing, so I can share my successes and my failures.

I don’t want to repeat my past mistakes. I’m going to make my work visible, for better or worse. So I’m taking my career out of stealth mode.

After living in New York for a year and a half, I miss San Francisco’s excellent used bookstores. I feel lucky to work just half a block from The Strand, but there’s something about a small bookstore’s curated selection of used books that makes browsing more fun.

I was working in SF last week when I happened into Aardvark Books one night after dinner. Aardvark boasts a great “recent arrivals” section, just a few shelves long but brimming with excellent, inexpensive reads. I randomly picked up a hardcover copy of John McPhee’s Uncommon Carriers, based mostly on its excellent cover art and a vague recollection of having read some of his work in the New Yorker. (It helped that some bookstore employee wrote in pencil on the first page, “Pretty good!”)

It was a lucky find. Uncommon Carriers explores freight transport and the people who work America’s trucks, barges, ships, planes, and trains, day and night. This might sound boring at first glance, but McPhee’s writing is strangely hypnotic and enthralling.

One piece in particular, Out in the Sort, kept me up late last night. The piece begins with a detailed description of a lobster-catching operation in Newfoundland, and uses the lobster company’s transport needs as a segue into a deconstruction of how UPS operates. Describing their worldwide hub in Louisville, Kentucky, McPhee writes:

This labyrinth, which outthinks the people who employ it, is something like the interior of the computers that run it. Like printed circuitry, seven great loops, each a thousand feet around, are superposed at right angles above other loops… Unending sequences of letters and small packages zip around these loops, while the larger packages follow one another on the belts, each package tailgating the one in front of it but electronically forbidden to touch it… Collectively, the loops are like the circuits in the motherboards among the interface cards of a central processing unit wherein whole packages seeking specific airplanes are ones and zeroes moving through the chips.

There’s too much to glean from the piece (and from the book) for a short blog post, but I’ll pick a few tidbits. We learn that UPS employs college students to handle packages that require human intervention—cleverly referred to as “exceptions.” When the company found it difficult to hire enough students, they founded Metropolitan College in partnership with the University of Louisville. As a bonus, they maintain an on-site facility that services Toshiba laptops (and often receive repaired laptops back before the customer would have) and the company maintains the world’s largest supply of parts for Bentley automobiles.

More impressive still is that during the three to five hours when the international and domestic packages are sorted in Louisville each night, each sorter is expected to handle 1,124 packages per hour.

I highly recommend this book if the topic at all sounds interesting to you. Track down a used copy of Uncommon Carriers. I’m certainly going to stock up on McPhee the next time I’m in a used bookstore.

If you can’t get a hold of the book, you can read Out in the Sort via the New Yorker’s archive or Mediafire (while it lasts).

Atul Gawande expanded a great piece in the New Yorker from 2007 into The Checklist Manifesto, a short, compelling read about how a simple tool can help humans tackle complexity.

Most of the book explores reducing human error in medicine (spoiler: good checklists prevent mistakes). But Gawande includes a fascinating chapter on the construction industry where he writes:

For most of modern history… the dominant way people put up buildings was by… hiring Master Builders who designed them, engineered them, and oversaw construction from start to finish, portico to plumbing. Master Builders built Notre Dame, St. Peter’s Basilica, and the United States Capitol building. But by the middle of the twentieth century the Master Builders were dead and gone. The variety and sophistication of advancements in every stage of the construction process had overwhelmed the abilities of any individual to master them.

The solution? A combination of delegation, communication, and checklists.

I see many parallels to the computing industry. Thirty years ago, Steve Wozniak designed and built a complete computer by hand, the now-legendary Apple I. Today, I carry a computer many orders of magnitude more complex than the Apple I in my pocket: the iPhone. There’s no one person who can understand every single component of the iPhone and how they work together, let alone assemble one from scratch.

Our solution in both hardware and software is abstraction. Different specialists and companies handle different components, and agree on interfaces between those components, much like the plumbers and electricians and HVAC specialists collaborate on a skyscraper.

In software, abstractions have evolved at the same speed as the underlying complexity, so that applications like the webserver Nginx and the game Minecraft can still be largely written by one person. The tools just keep improving.

The Apple iPhone SDK is a great example of an exceptional tool: for (almost) no cost, Apple offers developers a complete coding environment, UI components to make beautiful interfaces, a distribution channel, and payment processing. It’s never been easier for a team of one or two people to make great software that reaches a large audience.

Moreover, programmers have created many varieties of automated checklists to fight against increased complexity, from unit tests to full functional tests that click on buttons within an app.

Writing about loss is difficult. Few can successfully describe the emptiness one feels after the sudden death of a parent, child, friend.

And yet we try. When my mother passed away nearly twelve years ago, I started a web journal. Writing helped me process my thoughts and feelings into something concrete and more understandable.

Joan Didion described loss with quietly powerful language in The Year of Magical Thinking and Blue Nights, her memoirs about the death, in shockingly short succession, of her husband and daughter. Despite the painful subject matter, I highly recommend reading them (in order), both to people who have experienced a sudden loss and to those who haven’t. Didion captures the emptiness of life without her husband so well—the immediate elevation of once-unimportant miscellany to artifacts, the new strangeness of once-familiar daily routines.

William Maxwell’s So Long, See You Tomorrow is a short, moving work about memory, family, and loss, set in a small town in Indiana. Like The Sense of an Ending, most of the action occurs in the distant past, as an elderly narrator looks back on his life. And, like Sense, So Long can be read in an evening, though I’d recommend allowing some time for the words to sit in your mind. Maxwell uses deceptively simple language throughout the book; it took me some time to realize how carefully he chooses his words, and their cumulative effect is powerful.

I’m not sure how long a quote is too long, but I found this passage near the beginning of the book exceptional:

My father was all but undone by my mother’s death. In the evening after supper he walked the floor and I walked with him, with my arm around his waist. I was ten years old… Because he didn’t say anything, I didn’t either… His eyes were focused on things not in those rooms, and his face was the color of ashes…

I had to guess what my older brother was thinking. It was not something he cared to share with me… At night we undressed and got into bed and fell asleep without taking advantage of the dark to unburden our hearts to each other. It strikes me as strange now. It didn’t then… What I didn’t say, across the few feet that separated our two beds, was that I couldn’t understand how it had happened to us. It seemed like a mistake… I had to find an explanation other than the real one, which was that we were no more immune to misfortune than anybody else, and the idea that kept recurring to me, perhaps because of that pacing the floor with my father, was that I had inadvertently walked through a door that I shouldn’t have gone through and couldn’t get back to the place I hadn’t meant to leave. Actually, it was the other way round: I hadn’t gone anywhere and nothing was changed, so far as the roof over our heads was concerned, it was just that she was in the cemetery.

It’s not fair to describe So Long, See You Tomorrow as a book strictly about loss; the plot revolves around a murder, the details of which are revealed slowly. But all of the characters feel loss of some form or another—death, betrayal, separation, regret.

It’s a beautiful book. You can probably find it in your local used-book store, and on Amazon.

“The tendency to see patterns in randomness is overwhelming…”

Daniel Kahneman’s Thinking, Fast and Slow made many “best of 2011” lists this year, and deservedly so. Plenty of books on the systematic faults of the human mind have made the rounds, from Ariely’s_Predictably Irrational_ and its followup to Nassim Taleb’s Fooled by Randomness and The Black Swan.

Fooled by Randomness was a great book marred by the pompousness of its author. In fewer words (and with much less ego), Kahneman covers similar territory in more depth and backed by better research:

How many good years should you wait before concluding that an investment adviser is unusually skilled? How many successful acquisitions should be needed for a board of directors to belive that the CEO has extraordinary flair for such deals? The simple answer to these questions is that if you follow your intuition, you will more often than not err by misclassifying a random event as systematic. We are far too willing to reject the belief that much of what we see in life is random.

I will do my best to remember the above quote whenever I jump to conclusions about a startup, an entrepreneur, even an A/B test.

There’s too much in the book that’s applicable to anyone starting a business, or interpreting analytics from your website, or trying to make rational decisions. Instead of quoting from every chapter, why not just check it out for yourself? (No affiliate link, I promise.)

It’s been almost five years since I started my last startup.

I remember clearly the heady blend of optimism and anxiety that came with filing our incorporation papers, followed by the pride and sweat and joy of brainstorming, building and launching our first real product.

I just started a new startup with two great friends, Amit and Drew, and those feelings are back. The five intervening years have brought successes, failures, and hard-learned lessons, yet I couldn’t feel more sanguine about the future.

I should probably be more worried about the months ahead—there’s nothing to anchor me and my cofounders except our own determination and wits. It’s a long, hard road, and startups fail for a lot of reasons.

Yet despite all that, I still feel optimistic.

I’ll do my best to correct my mistakes from my last go-round[1]. Yet even if I fail this time, I feel like I’ve already won. Inertia is one of the strongest forces in the world—there are so many different things acting to prevent one from doing something, from making something. And somehow, we’ve managed to give ourselves the opportunity to really create something awesome.

All we have to do now is make the most of it.

[1]: See my previous post about putting your career in stealth mode for one of the mistakes I made.

I’ll admit it—I love programming, and I have since I was a kid. This makes me a nerd, but at least I’m an honest nerd.

Code is a unique medium. There’s no activity better suited for the achievement of flow, which Wikipedia defines as “the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.”

There’s something really special about hacking away on something and then, after hours or days of struggle—making it actually work. And that joy of completion, of having heroically struggled and then solved the problem, happens again and again. A good programmer working on a hard problem has little dopamine bursts firing in their brain all day.

I’m still not over it. And I think many people would benefit from (and enjoy!) learning how to code.

A computer on every desk, and in every home

Steve Jobs gets most of the credit for being a revolutionary technology leader, but Bill Gates was equally, if not more, visionary. In 1980, Gates defined the mission of Microsoft “A computer on every desk, and in every home.”[1] It’s difficult, now that we we all have incredibly powerful computers in our homes, cars, and pockets, to remember how insane this was at the time.

Microsoft executed that insane vision nearly flawlessly.

Computers became integral to many jobs in the 1980s and especially the 1990s, as the Internet penetrated workplaces and Microsoft’s Office software became ubiquitous. New software dramatically changed the nature of office work.

We’re about to experience another dramatic change. The New York Times recently published The Age of Big Data. You should read it, but let me summarize: As computers become part of more things (phones, cars, toasters), they will generate more and more data, and we’ll need smart analysts to make sense of it all. Office workers will experience a big shift like they did in the 90’s,as the ability to analyze data becomes more integral to every job—from management, to marketing, to design, to front-line information workers.

I believe that simple computer proficiency will no longer suffice as software takes over more aspects of work and life. Not that it’ll be necessary for all office workers to become masterful programmers; but those who can write simple programs to help automate their daily work and make sense of piles of data will have an advantage.

This change means more people will have the opportunity to experience the joy of code. Unfortunately, learning requires hard work, and most people haven’t been educated in the basics of computational thinking.

How will all these people learn how to code?

Learn BASIC now

When I was around eight years old I asked my parents to buy me a book called Learn BASIC Now. (Amazingly enough, Amazon still sells the book for a penny.) I remember sitting down at the computer in our living room and working through the book’s exercises in QuickBASIC, a programming language included with most PCs at the time.

Within a few weeks I was able to make simple video games, and by the time I was in middle school I was asking my parents for related stuff—more books, then an Internet connection, then a domain name (which cost $100 at the time!) and Web hosting service, so I could help others learn.[2]

One of the most popular games I wrote as a kid had primitive graphics that looked like this:

[Image would go here]

This wasn’t state-of-the-art for 1994, but it was playable and maybe even fun. I called the game Lander. The goal was to safely pilot your ship to a landing strip on the moon, avoiding obstacles along the way[3]. I really enjoyed making games and sharing them with friends and on the Web—it was a great motivator for me to improve as a programmer.

But what worked for me wouldn’t work today. The everyday systems we use have become more complicated, and it’s harder to create a simple program of acceptable quality.

Most DOS users would be able to find and run GW-BASIC or QuickBASIC, two programming languages that shipped with the operating system—but although current Macs ship with several powerful languages installed, most newcomers wouldn’t know where to find them. If they could, the Terminal would seem scary because the Mac user interface covers up its text-based underpinnings.

Even then, creating a text-based program wouldn’t seem that impressive—the simplest iPhone apps come with beautiful, animated interfaces that react instantly to our touch, courtesy of Apple’s design tools. A text-only number guessing game seems pretty lame by comparison.

Learning to code in 2012

So how does one get started, given the complexity of today’s computers and the high expectations of users? Thankfully, many startups and universities have begun tackling the problem in innovative ways.

Udemy offers a class by Zed Shaw called Learn Python the Hard Way for $29. Zed also offers a free HTML book for the course. Zed’s premise is that the best way to learn is by doing, so you’ll be doing a lot of typing. This seems to me like a Good Thing.

Another startup called Codecademy offers a unique way to learn—simple, step-by-step tutorials that run in your web browser, allowing you to interactively learn how to code without installing any software or buying any books. They’ve recently received a lot of press for a 52-week program called Code Year. When you sign up for Code Year, you receive a weekly code lesson via email which you can complete on their website. There are also Q&A forums where you can get help with each lesson. Hundreds of thousands of people have signed up, including high-profile folks like Mike Bloomberg.

There are a couple of potential downsides to Code Year and Codecademy. Currently, they only teach Javascript, which I wouldn’t recommend as a first language for a beginning programmer. Second, the interactivity of the lessons hides some of the realities of coding. Programming is a unique activity because for the most part it’s a very solitary journey—you’re alone with your work, shuffling logic around your brain. I’m curious if the folks who go through Codecademy tutorials are ready for the kinds of frustrations they’ll face—Learn Python The Hard Way is much more like “actual” programming.

There are tons of other great resources, far too many to list here. The Khan Academy has great video lectures; Google offers excellent Python tutorials; MIT offers their Intro to Computer Science and Programming, and Stanford offers an Intro to Computer Science and Programming Methodology..

Regardless of which method you end up trying, if you want to learn, find something that appeals to you and stick with it. Don’t get discouraged; the rewards will reveal themselves over time.

Conclusion

Learning to code is like learning to play an instrument. Some people will achieve basic easier than others. But for nearly everyone, becoming a good programmer will take many hours of deliberate practice; it’s not something you can achieve in hours or days, no matter how many tutorials you read.

To be a great programmer, you have to really want to learn; it’s not going to happen in a day or a week. Thankfully, you probably don’t need to become a great programmer unless you plan to pursue a career in software engineering. You can learn enough code in a short time to improve and automate some of your daily work.

I hope that the changes ahead as we enter the “Age of Big Data” give more people the opportunity to experience the joy of code.

I’d love to hear from people who want to learn code. If you find a particular resource linked in this post helpful (or terrible), or you think I’ve missed something, please let me know.

Notes

1. The full quote is actually “A computer on every desk and in every home, all running Microsoft software.” Steve Jobs deserves praise for rescuing Apple in the early 2000s and taking leadership of the technology industry, but it was Microsoft who really brought personal computers to the masses.

2. Sure enough, some of my tutorials are still floating around the Web. This taught me an early lesson in how anything you put on the Internet never goes away.

3. The game borrowed from similar “land the ship” games at the time. A bit more explanation on its mechanics: the turquoise strip at the bottom of the screen represents a lunar landscape; the red flaming comet is an obstacle to avoid; and the shaded golf ball-like things are supposed to be planets to dodge. (Don’t ask me why planets are hovering above the moon’s surface; it made sense at the time). The code for this game still floats around the internet—it’s embarrassing.