Learn enough code to build a crappy prototype of your idea in a week.
Two years ago, I became obsessed with startups. I was in school at the time, and constantly had a notebook out sketching my web-app ideas. It was entertaining at first, but soon I realized that in order to make progress I had to build the damn things and put them in front of users. So I did what most people do in that situation - began looking for a technical cofounder. I started trying to meet as many programmers as possible.
I got lucky and met a hacker that liked my idea, so we started working together and he suggested I code the HTML and CSS for the front-end of our rails app (it was to be a publishing platform for authors). I resisted at first but quickly realized that I'd lose all credibility if I was unwilling to dabble in a little simple code. So I went through some tutorials and found that coding actually wasn't too hard. Every time I reached an obstacle, an hour or two of googling usually yielded a solution.
I began to grow increasingly curious about how web-applications worked. I started to like the idea of being a coder. So I kept hanging out with programmers, asking them questions, and building little side projects to keep learning. After a couple years of doing this I have turned into a pretty proficient programmer. Even though I'm a designer at Olark, I learn more about engineering every day and have even built production-scale features (not to mention countless prototypes).
My story involves years of hard work, but I'm convinced you can learn enough code to be dangerous much faster than I did. The resources for learning programming on the internet are great, but make one crippling assumption: they assume you want to become a programmer. They teach you the basics with great precision, they assume you want to know the right ways to build things. Which is a good assumption to make if you're helping someone who wants to be a programmer. But in this book I'm going to teach you the wrong ways of doing things. They won't scale, and they're not secure, but they will work. And that's all you need at this stage.
Because your goal is to turn your ideas into reality. You see opportunity and you want to seize it. But you can't, at least not right now, because engineering talent is one of the scarcest (and most valuable) resources in the world. And most of the good engineers have plenty of their own ideas, so they are not going to pay much attention to an unproven concept. But if you can validate your idea with users, and show that you're resourceful enough to scrap together a version 1 of your idea, your chances of attracting an engineer skyrocket.
I guess now's a good time to admit I also have an ulterior motive. When you're reading this book, I hope you discover an intrinsic joy in making things. In so many domains of life it is difficult to tell whether you're doing a good or a bad job. The feedback loop is tortuously long and indirect. But in hacking, the problems and solutions are addictingly concrete. Ask any hacker how it feels after you code a new feature or fix a bug. Pure dopamine rush. Not to mention the more general and lasting sense of contentment you get from having built something, the same way our grandparents generation probably felt after building a chair or cabinet, or how a caveman felt after fashioning a particularly handsome axe. I hope that after you read this book, you get addicted to making things and wanting to do it the right way, which of course requires a sustained period of effort. The world needs more builders.
If this sounds good to you, then I promise you'll find this book a valuable addition to your life. If you'd rather not get your hands dirty making things, or if you're looking for a more rigorous Computer Science type introduction to coding, then you should look elsewhere.
Let's get started!