How I hated code and decided to spend an hour writing it every day for a year

How to hack yourself to enjoy learning to code

How I hated code and decided to spend an hour writing it every day for a year

If you asked us, we were practically done. We had drawings, wires, one-pagers, a little movie that spelled out our idea in an entertaining way. We had everything, except code. But the guy with the money and headcount was right. We had nothing. I used to say that “the best argument is code,” but walking out of that meeting room, it felt more like “the only argument is code”.

Just one problem. Like a real estate agent who hates bricks, I was a product person who hated code.

And then it happened again. That’s when I decided to like code, and move from copying and pasting Javascript to writing native apps.

Hacking myself first

Knowing I might be able sell my ideas was not enough, I had to sell the idea of coding — to myself. Simple old-fashioned brainwashing.

“Wow, someone came up with all this!”

Man, I’m glad it wasn’t me. But also, man, they really put thought into this. How could human beings even come up with this? Every programming language, mobile app framework, even the editor, is 30 years of compressed computer history. Typing modern code is like walking through a computer history museum, only in this one you get real software when you exit through the gift store.

“I hope I get stuck soon.”

I would usually just walk away. This time, I dragged myself back behind the keyboard, yelling that “if you get past this, you never have to get stuck here again. Keep going, and you’ll probably never be stuck again.”

“I can’t wait to see what code I will write tonight!”

It became a habit. Most of the days between 10 and 11pm. But if I was working on the right project, this was automatic. Almost like following a tv show where you have to see what happens next.

Smashing neurons

The idea is to expose yourself to the same information, but from different sources. When you encounter something you already know, it feels easy. When it feels easy, you want to go further. I watched specific Simon Allardice videos on Lynda and looked stuff up on Stack overflow. Searched Safari Books and listened to Paul Hegarty’s Stanford iPhone course on the BART flying through the tunnels under Market St. Flipped through Nerd Ranch books and clicked through the free course from Nick, Roman and James. It didn't feel like studying as much as a friendly reunion with facts.

Structured distraction

Getting stuck didn’t seem so bad if I listened to a podcast at the same time. Being stuck involves a lot of boring googling around, trying small details. I found that if I listened to podcasts, I could keep trying to get unstuck and not be tempted to give up.

With the brainwashing in place it was time to write some code. And ship it too.

Shipping from day zero

My first project was a disposable voice recorder. It’s really just an aptly licensed GitHub project by a complete stranger. When I miraculously had made it do what I wanted it to do, I submitted it to the AppStore from a hotel room in Cambridge, MA. I had no idea what I was doing. A year later, I still use it to rehearse presentations and finding out if what I write makes any sense. I didn’t understand 80% of the code in the app I just shipped, but I made something useful, at least for me.

And then I started shipping more apps.

Tiny goals

I spent a few minutes of my daily coding hour thinking about a tiny goal. Make this button do that. Fix that bug. Polish the UI to look like this. I was surprised to see how quickly all those small details began adding up to something I could use right away. Daily goals became weekly releases.

But how do you decide on a tiny goal? Maybe by asking, “does this bring my app closer to a version that I myself could actually begin using?” It's easy to spend hours sweating the wrong details. But for me, making it usable as fast as I could was a tremendous motivator. Even more so when I could pass it along to friends and coworkers, or send them a quick video recording of a demo.

Here’s a list of some of the apps I made last year:

Mobile screenshots

Every time I took a screenshot on my smartphone I got gradually more frustrated. So I made it a one-click operation, from the Mac. Ironically, tutorials for my app began appearing.

Animated GIFs

Share the beats

Music, however, is never annoying when your own friends are winding up the tunes. So Jacob and I made Twinjack, an app that listens to your Spotify, and pipes it straight to the web. It got nominated for The Webby Awards. They still exist.

An effective way to think about something is to just hammer away on the keyboard without ever stopping. It’s a classic writing exercise called free writing. I wondered if I could turn that into some kind of game where if you stop writing, the sentence crashes to the bottom, and you lose points.

Coding is like having a conversation with your idea

It seems that writing code is really just another way of thinking about software. You can draw diagrams, make wireframes and mockups, and write product requirement definitions. But writing code is like chatting with your idea. You can spend hours and hours pondering and discussing and researching if this is a good idea or not. Or you could just let the software tell you.

Have you ever noticed that when you sit down to write something, half the ideas that end up in it are ones you thought of while writing it? The same thing happens with software. Working to implement one idea gives you more ideas. So shelving an idea costs you not only that delay in implementing it, but also all the ideas that implementing it would have led to. In fact, shelving an idea probably even inhibits new ideas: as you start to think of some new feature, you catch sight of the shelf and think “but I already have a lot of new things I want to do for the next release.” — Paul Graham