The HoPE Manifesto: Learn to Code
The HoPE Manifesto: Learn to Code
Preamble:
January 2011
To-date, my career has been defined by being a NoPE -- a Non-cOding Product Executive.
Sure, I've dreamed great things, learned enough about programming to "Be Dangerous" (dangerous to whom?)... I've even been called a "Hacker" by real programmers.
But until recently, I could never code. I could never take a simple idea, build it, and test it out with my closest friends. Until recently, most ideas would sit on my mental shelf, or tire the ears of my friends and loved ones.
Recently, that's all changed. It started with a nudge from my friend Sam, accelerated with the energy from my girlfriend Jackie, and bolstered by the patience of my dear friend Kyle. And today -- two short months after deciding to learn how to code -- I'm a a NoPE no longer.
Today, I'm a HoPE -- a Hacking-cOding Product Executive. I've released Ohours as my first production app, and now can produce prototypes of my ideas in only a few short days.
Below, I've outlined how I taught myself how to code in such a short time -- call it the HoPE Manifesto, if you'd like.
The HoPE Manifesto
Table of Contents:
- Introduction
- Committing to The Sweat Lodge
- A Week in the Sweat Lodge
- 3 Rules for the N00b Hacker
- Conclusion
Introduction:
The HoPE Manifesto is a document I hope to maintain and update, so it serves as a helpful resource for all who want to make the transition from NoPE to HoPE. Today, it includes all I've learned to date.
But, since education is an ongoing process, expect the document to grow and change as I learn more about becoming a developer. If you have questions or want me to clarify part of the document, use the comment thread below the post.
And now, let's get to work. ---
--Back to Table of Contents-- ---
Committing to The Sweat Lodge
The first key to learning anything is real commitment. How many people have taken years of Spanish classes but can't speak a word? Meanwhile, we all know people who studied abroad and immersed themselves for a few weeks and came away with the ability to communicate freely (though perhaps difficultly).
Learning to code is no different. If you think you can learn how to code by going to a few classes, being "taught" or sitting down for an hour or so every so often, you're 100% wrong and will waste your time. If you truly want to learn how to code (or learn any other new skill, for that matter) you must find some serious time to dedicate to the cause. And the cause is teaching yourself, not being taught.
I call this The Sweat Lodge.
When I left AnyClip, I spent a few weeks playing around with online tutorials and reading books about coding. Not surprisingly, I felt like I was as much of a NoPE after a few weeks of this as I did when I began.
My real education started the second to last week of October, when I took five days of my life and commited myself to Change.
For five straight days, I sat at my desk, from the time I woke up to the time I went to bed, and obsessed over my education. I barely showered. I ate at my desk. I obsessed.
I went into my personal Sweat Lodge a NoPE and emerged a HoPE. Did I have all the answers? No. In the weeks and months that followed that week, I've learned a huge amount more than what I learned in that week.
But in that week, I taught myself the most important, foundational lessons that allowed me to emerge a new person: the skill of self-sustenance.
So this is your first test: Are you willing to commit to The Sweat Lodge? Are you willing to take 5 days -- at least! -- of your life to go through mental hell? Do you really want to code or are you just saying you do?
If you're ready to dedicate yourself to your own personal Sweat Lodge, continue to the next session. ---
--Back to Table of Contents-- ---
A Week in the Sweat Lodge -- Your Curriculum
How you spent your week in The Sweat Lodge is all about curriculum and interest. But, since you're starting from basically nothing, I recommend finding a tutorial/book that will serve as your main course material.
I went with Michael Hartl's incredible book at RailsTutorial.org (here's a list of other resources you could try, but I'm going to talk about RailsTutorial a lot).
A quick note about "Why Rails":
I went with Rails for 2 reasons. The first may not apply to you: I had *some* exposure to Ruby on Rails in my past startups, so while still a mystery to me at first it felt slightly familiar. The main reason I went with Rails -- and why you should consider going with Rails -- is because of the unparalleled resources for beginners out there. Whether its the RailsTutorial itself, the amazing work Ryan Bates has done at RailsCasts, or a multitude of other tutorials, the Rails community has done a fantastic job of leaving educational breadcrumbs for new hackers.
So now you have RailsTutorial open, here's a general outline for your time in The Sweat Lodge (I'll go into more details on each part below):
- Step 1: Follow Chapter 1 of RailsTutorial. This first chapter takes you far (you'll deploy something to a live server!) and explains things unbelievably well. Congrats! You're now a coder!
- Step 2: Okay! Now do the rest of RailsTutorial.org and throw Michael $26 (price of the book in PDF form) if you're as thankful as I am that he wrote such a fantastic document. Below, read my tips on how to get the most out of following the tutorial. Hint: Learning is about experimenting, and that starts now.
- Step 3: Put RailsTutorial aside do Robin Fisher's super quick tutorial on how to make a simple "todo" list application. The application is so simple, in fact, this is a great time to use a "Gem" and play around with someone else's code.
- Step 4: Spend a day playing around with Ruby, learning about Strings, Arrays, and Hashes. Embrace the fact that Ruby is just a cool calculator that handles more than just numbers, and that makes your write words for commands instead of pressing buttons.
Step 1 - Chapter 1 of RailsTutorial.org In Chapter 1 of RailsTutorial.org, you cover everything from installing Ruby on your machine (if you don't have it yet), updating Ruby and your gems, getting Rails working, and learning a bit about GIT. At the end of the Chapter you will have even pushed your first "application" to a live server.
This is your first test of the week. Getting everything working can be super frustrating for some people, but guess what: once you're programming you're going to have bugs that are many times more frustrating. Get over it and push through it.
The key thing to learn in this first step is that no matter how great the resource, you'll always have questions. Installing RVM didn't seem clear enough on RailsTutorial? Go Google something else. Your education CANNOT be tied to one resource. There are thousands of amazing resources you will use throughout your new life as someone who codes. Prepare yourself by going outside the tutorial for more information and to dig deeper in this very first step.
Step 2 - The Rest of RailsTutorial.org Congrats! You pushed your first thing to a live server. Did that feel awesome or what?! Did you Tweet a link to all your friends?
Now it's time to hunker down and finish the tutorial. It's super long and you'll have to go back over and read a bunch of stuff over and over again, but by now we know you're 100000% dedicated to learning, so who cares? Each time you "get" something new it's so exhilarating that you can't wait to go back and read something again.
"Oh.... That make sense!"
As you're following this chunk of the tutorial, I have a few suggestions:
- Do the software tests. Writing tests sucks. Its a boring process and you don't see the results right away. If you're a slob like me, once you're out of the Sweat Lodge you may say "screw it" and forget tests all together. But while you're in the Sweat Lodge you need to write the tests. First of all, you'll pick up a lot of Ruby while you're doing them, and second of all Michael uses the tests as a way to teach you about programming in general -- and 90% of learning to code is learning to think about coding.
- Second of all, just like I stressed going off the tutorial for help in the first chapter, I believe it's super important to start experimenting with your code as you're learning. The first thing I changed while doing Michael's book was the background color of the application we were building. One line of CSS cascaded into lots of little changes, from the copy to the underlying code itself. While you're following his every step, get in the habit of being your own programmer and putting your own flavor into things.
- Lastly, unless Michael says (and he does sometimes) "it's okay if you don't understand this, we'll come back to it" then don't move on until you have some semblance of an understanding of what you're doing. You don't need to fully "get" everything you're doing all the time, but also don't gloss over what you don't know. Take the time to understand what you're doing. Again, by Googling for more info or looking at other materials you will always stumble upon a better way of understanding new concepts (like "MVC").
With this, go forth and do the RailsTutorial. It will take a ton of time, but you will learn so very, very much. Have fun!
Step 3 - Todo List/Authentication Tutorial Mashups Wow! You finished the RailsTutorial Book? Congrats!!! Now head over to this video tutorial and make a todo list application. It's way, way simpler than what you just built, but you're be exposed to some extra new skills (like nesting "resources"). By the way, while you're doing the tutorial, skip the MySQL part. SQLite (what you used in the tutorial) is just fine for development mode, until you're doing more hardcore stuff when you'll want to develop with the same DB technology you run in production.
Now that you've built the little todo list, you've no doubt noticed there's no authentication system. I know you're not passionate about this little project, but sink a little extra time into things and expose yourself to Ryan Bate's amazing RailsCasts -- specifically his RailsCast about adding the "Devise" gem.
Again, a big part of your education is about synthesizing information from different resources and experiences. I had you do the todo list application because there will be times when you want to combine concepts from RailsTutorial and the todo list when you build whatever you decide to build next. Now, you need to add a login layer someone else built, using a tutorial someone else is giving. Exposing yourself to as many sources and tools as possible will teach you the art of triangulating and synthesizing information and tools.
Step 4 - Play Around with Ruby You have done so much and I am so proud of you at this point. Truthfully, you could leave The Sweat Lodge at this point, but do you really want to? You've learned so much and you want nothing more than to go forth and start building the applications you wish more than anything existed.
If you want to, fine, but I recommend spending a solid day in your Ruby console (just type "irb" into Terminal) getting to know what Ruby has the power of doing.
For this part of your education, there's no better resource than just Ruby-Doc.org. I recommend spending your time learning about a Strings, Arrays, and Hashes. You'll be familiar with some of the methods from what you've done in RailsTutorial, but there are others (like the Collect method on Arrays, which I'm in love with) that you haven't been exposed to yet and which will prove super useful as you try new things or debug code.
I think playing around in IRB and the Rails Console is a major part of experimenting and learning, and so I think it's a perfect way to unwind your time in The Sweat Lodge. ---
--Back to Table of Contents-- ---
3 Rules for the N00b Hacker
You've emerged out of The Sweat Lodge a new person. In only a matter of a week or two -- while others were on vacation or at some conference collecting business cards -- you turned yourself into a different person.
Congrats. Are you glowing? You should be.
As you go forth with your new life, I have 3 Rules for you to follow.
Rule 1: Always Let Your Passion Be Your Guide
You went through The Sweat Lodge because you were passionate about learning how to code. Now that you have a foundation of education, the only way forward is by working on something you're incredibly passionate about.
Why? You've only learned a fraction of what you'll need to know to create the tools and services you wish existed. And, if you try and build something you're not 100% in love with, you won't have the enduring strength to bang your head against the wall, day in and day out, learning the next skill you need in order to do it.
If you're learning to code but already have other people working on "the real" application you want to exist, don't shy away from building the exact same thing in parallel, if that's the thing you want to exist most in this world. You can't learn by working on an idea any less serious than the most serious idea in your life, because you just won't find the energy to see it through.
In short, if you let passion be your guide, you'll be able to keep up the momentum you got from The Sweat Lodge and take your n00b hacking skills you the next level.
Rule 2: The "24hr head on wall" rule
While you're trying to build that awesome thing you always wish existed, you can bet that you are going to hit a wall along the way. There will be something that's not working and it's going to suck the life out of you as you try and get it working. It's a fact of your new hacking life.
If you're like me, you may have a friend or even someone you barely know who knows about Rails -- maybe you just have a Forrst or StackOverflow account. Either way, some way or some how you probably have some level of access to someone who can tell you what you are doing wrong or how to fix your problem rather quickly, BUT DO NOT TURN TO THEM FOR HELP!
In my early days of coding, I created "24 hour head on wall" rule for myself. I knew at any time I could turn to my friend Kyle Bragger for help, but if I did that I also knew I'd never learn.
So, I forced myself to spend at least 24 hours trying to work through a problem before I reached out to him for help.
90% of the time, I managed to solve the problem before I needed Kyle's help. But, 100% of the time I learned an incredible amount in the process.
You see, when you get help immediately you learn one thing. When you take a day to bang your head on the wall trying to solve your own problem, you run into so many tools and techniques that don't solve the problem you have at hand, but are super useful things to know about for the future or to optimize something you've already done.
3. The Only "Right" Way is "Working"
One of the most important lessons about learning to code came from one of my first 24 hours head/wall periods. After a solid day of pain, I went to bed demoralized. I knew there was a "right way" of solving my problem, but I didn't know what that right way was, and I didn't know how to learn what the "right way" was.
The next morning, in the shower of course, I had an "ah-ha" moment. While I was looking for the "right way" I forgot to look for "a way that works." I was looking for the wrong answer!
The one disadvantage to following great tutorials from great programmers is that they teach you the best, most elegant ways of programming something. What they don't tell you is that the only "right way" is just "working."
Since then, I've embraced the fact that what matters most is being able to string together a bunch of lines of code that eventually dump out what I wanted on the other side of things. I've accepted that I will always learn "more right" ways of doing things, but if I try to do it the "right way," I won't get anything done.
As my dear friend and mentor Kyle Bragger puts it: "Does it work? And do you understand why it works? These are the two conditions."
Now, when I learn something new, I go back and re-write my older code in better ways, and I savor the fact that I would have never learned those lessons if I hadn't just written bad-but-working code in the first place, moved on, and found myself where I was when I learned how to do it the "better way."
--- --Back to Table of Contents-- ---
Conclusion: A New Found HoPE:
People have always thought of me as a bubbly, positive, and enthusiastic person; but recently, people have made a point to tell me, "Nate, I've never seen you happier."
It's true. Once I committed to my education as a programmer -- in fact, starting the minute I emerged from "The Sweat Lodge" -- I felt like a totally new person.
Mixed together with my otherwise exuberant spirit and healthy sense of self-worth, I always felt like a piece of me was missing by not being able to code. Privately, I referred to myself as the "armless architect," being that I could tell people what to build but couldn't build anything myself. Literally... something was missing.
Today, I feel whole. In fact, though it was only a few months ago that I made the transformation from NoPE to HoPE, I have a hard time remembering what life was like before I embraced the idea that I could learn whatever I needed to learn to make whatever I needed to make.
My hope is that this document has helped you go on a similar path. No one can teach you like you can teach yourself, but hopefully this Manifesto has provided a helpful framework for that process.
Again, please let me know in the comments how I can make this document more useful for you as you're making a similar transformation, thanks for reading it, and congrats on the decision to go from NoPE to HoPE.
-- The End --