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

“What were you expecting? Praise?”

We had awesome drawings, we even made a little movie that spelled out our idea in the most efficient way possible. But the guy with the money 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 that hates bricks, I hated code.

And then it all happened again about a year ago. 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. Do this 1,000 time 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 principle behind the knowledge collider is simple. To learn something, you fire two beams of knowledge along two pathways, one going clockwise, the other going counter clockwise. Simon Allardice on Lynda.com and Stack overflow. Safari Books and Paul Hegarty’s Stanford iPhone course. Nerd Ranch books and Nick, Roman and James.

Structured distraction. Getting stuck didn’t seem so bad if I listened to a podcast at the same time. I have no idea how this works in the brain, but typing code and listening to humans talking actually works. I am tuned out some of the time, but when distraction comes knocking, the podcast opens the door, and I can code in peace out in the back.

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, and submitted it to the AppStore 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 writing apps.

Tiny goals

I spent a few minutes of my daily 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 could actually begin using?” It’s easy to spend hours sweating the wrong details, and maybe you find that that’s where you have the most fun. 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.

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

Mobile screenshots

Every time I took a screenshot of an Android phone I got gradually more frustrated. So I made it a one-click operation. 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 onto 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