For someone without programming experience, starting in web development can feel very daunting. You’re in that uncomfortable first stage of competence (“you don’t know what you don’t know”), so you might think that you have to spend months assembling a foundation in computer science before you can build a website of any sophistication.
Not so! Web development and CS are different enough that you can start learning the former without having a strong base in the latter. I say this largely based on my own experience.
When I started web development six months ago, I was a full time law school student and barely knew any programming – only the basic stuff you pick up in your first few hours of study. Four months after I started, I got a job offer from Pivotal Labs, took a leave from law school, and moved out to SF. I was extraordinarily lucky to run into awesome mentors (the benefit of attending Hacker School cannot be overstated), so I don’t mean for my story to be representative. But I do think it suggests that people without CS backgrounds can become web developers, and that it probably takes less time than you think.
This blog post is an attempt to help others get started in web development. It’s meant to be a lay of the land, “here’s what you need to do” type roadmap for your first couple of months, the kind of map that I wish I had been given when I first started coding.
I’ve been wanting to do this for a while but have put it off because I didn’t think I knew enough. I still don’t know enough, so please let me know if you spot any errors or mischaracterizations* below.
There are (roughly) four unequally-sized clusters of knowledge that you’ll need to pick up in your first couple of months.
1) The basics of a web framework (e.g. Ruby on Rails), AKA “the structure that will contain the pieces of my website and the connections among them.”
2) Front-end development, AKA “how to make content appear in the right way and look nice in people’s browsers.”
3) Version control, AKA “how to use the fancy/free software that programmers use to keep their code revisions organized so that they can modify their code without worrying and so that they can more easily collaborate with others.”
4) Deployment, AKA “how to actually get your site onto the internet.”
I’ve numbered these clusters 1-4, but they aren’t meant to be tackled in any particular order. You’ll learn all of this stuff concurrently.
The time distribution here should actually look something like “Pick a web framework” => 1-10 minutes”. “Learn that web framework” => “Lots and lots of (happy) hours.”
There are lots of web frameworks to choose from. I’m going to discuss Ruby on Rails because it’s what I know best and because there are so many excellent resources out there on it.
So what’s a web framework? My understanding is this: before frameworks came along, people used to have to set up a lot of the same stuff every time they decided to make a new website. Since this was a major pain in the ass, programmers developed frameworks like Rails to take a lot of the repetition out of web development. People like to say that Rails stands for “convention over configuration.” What this means is that Rails makes web development easier by assuming you want things done the conventional way.
Resources to use for this:
I’m deliberately going to present just a small fraction of the myriad Rails/Ruby resources out there because choice paralysis sucks.
Part I) Read Michael Hartl’s wonderful/free Rails Tutorial. A word of warning: although Hartl’s tutorial is amazingly clear and comprehensive, it is not a walk in the park. Go through it slowly and look things up whenever something doesn’t make sense. If you find yourself just mindlessly going through it and copying/pasting his code just so you can finally “finish” the tutorial, STOP yourself. When things don’t make sense, go to one of these resources immediately:
• Google. Someone will likely have written a blog/forum post about the very thing you’re wondering about. Turn to Google first for any questions you have.
• Stack Overflow. It is amazing how quickly a programmer out there will answer your question (my questions are often answered in under an hour), however specific it might be.
• Railscasts. Ryan Bates has over 300 screencasts on all Rails-related topics. An amazing resource.
• Rails Guides. These really professional seeming guides appear to be written by members of the core Rails team. They’re challenging to understand at times (since they’re written for experienced programmers), but many of the introductions are accessible.
Part II) At the same time as Part I, start learning Ruby. Hartl will teach you how Rails works, but if you don’t know Ruby, too much of Rails will feel like magic. Here’s what you should use to learn Ruby, presented in the order in which you should use them:
(Also highly recommended: If you want a fun challenge, go to projecteuler.net and do a some of the problems with the stuff you learned from Codecademy.)
• Go through this excellent Ruby Tutorial. As you read it, open up your terminal (e.g. iterm on a mac), open up irb (the interactive ruby shell), and immediately start playing around with the syntax you’re learning. (And look up “terminal” and “irb,” if you don’t know what they mean.)
• At about the same time as the above, download and start going through the Ruby Koans. They’re a series of fun/informative exercises that cover most of the basics of Ruby.
• Finally, read Eloquent Ruby. Eloquent Ruby assumes some degree of familiarity with coding generally, so don’t start reading this until you’ve gone through the Koans and the Ruby Tutorial. Eloquent Ruby will not just teach you how Ruby works, but about how you should use Ruby (i.e. the way that Ruby programmers have determined is best practice).
An incomplete/inexact definition of “front end” and “back end” might go something like this: the “back end” in web development is where you store and organize the data on a website. A site like Yelp has to remember lots of things: its users and their profiles, huge amounts of restaurant info, which user said what about a particular restaurant, etc.
Yelp stores this information on servers, big computers sitting off in some remote location. When you search for “Pizza in San Francisco,” your computer sends a request to Yelp’s server. Yelp’s server sends back the requested information (per the way that Yelp has instructed the server to behave) to your browser in the form of HTML, which your browser renders (i.e. turns the HTML into text and images and arranges the text/images in the right way in your browser window.). This latter part – the set of instructions about how data should appear in the user’s window (as opposed to which data should be sent back) — that’s the “front end.”
Resources to use for this:
Learn HTML and CSS at w3schools. Edit: Thanks to the commenters below for pointing out the deficiencies of w3 schools. Please check out w3Fools and Mozilla’s set of documentation/tutorials instead. HTML is the markup language that governs the structure of a page, e.g. there should be a header, followed by a paragraph. CSS is the language that determines how a given page should be styled, e.g. the header should be in size 18 font, and the paragraph below it should have blue text.
Put roughly, version control systems let programmers take snapshots of their code (formally called “commits”) at any point in time. By the end of a project, a programmer will have accumulated hundreds or thousands of these snapshots.
The importance of version control wasn’t immediately obvious to me. When I write an essay, I don’t keep track of every small change I make to my Microsoft Word file. Why should it be any different when I write code?
It turns out the answer is (at least) two-fold. First, programmers sometimes write code that causes unexpected problems. When this happens, it’s great to be able to easily revert to the last working version of their code. Second, programmers often work together on the same project. When they do this, they need to be able to easily merge their code. Version control systems like Git (by far the most popular) make it easy to do both these things.
Resources to use for this:
Hartl will introduce you to Git, but he won’t explain much. To learn more, go here:
• Git Introduction. Made by the folks at Github (an amazing website that lets programmers easily share code and work on projects together – you should sign up on Github very early on).
• Understanding Git Conceptually. A well written, concise yet thorough explanation of how git works. Read this before going through Git Immersion. (Thanks to commenter Polygonchorus for pointing this one out. Looks really great.)
• Other resources: Git Guide: Stylish and simple. Go here to learn about the basic commands. Git Community Book: An excellent reference, although probably not something you need to read front to back.
When you develop your website, most of the time you’ll examine it in your “development environment,” — that is, on your own computer – NOT on the internet.
The rationale behind having a development environment is simple: it takes time to push your code onto a remote server (i.e. a server that’s actually out on the internet). And since you’ll constantly be inspecting your website as it’s developing, it’d be very annoying to have to wait 20-30 seconds for the remote server to receive/process your code before you could see the effect of your changes.
When you’re feeling ready, Heroku makes it really easy to deploy your code (Hartl explains how to do this). Here’s the info on setting up Heroku with Rails 3: http://devcenter.heroku.com/articles/rails3. If you want to set up a custom domain name, Heroku provides an extensive tutorial on this too: http://devcenter.heroku.com/articles/custom-domains.
This should be enough material to last you for a couple of months, but it won’t take you much farther than that. But hopefully by then you’ll already be building and learning from your own projects! Here are some parting thoughts:
• Pick a project idea that really excites you and start working on it much earlier than when you feel ready. I recommend starting your own project even before you’re done with the Hartl tutorial. Working on your own project is the easiest way to get hooked on this stuff.
• As good as the resources I’ve mentioned here are, they cover only a small slice of what you need to know to build your own website. Expect to have to look stuff up all the time. Don’t worry – even the best programmers still need to do this.
• You’re going to run into bugs and other problems frequently. This can get frustrating, but try to keep cool and think systematically. Read up about debugging best practices and come up with a list of bugs that crop up routinely. Come up with a mental reaction plan for when these problems appear (example line of reasoning: Okay, so my users can’t sign in properly. What could be causing the problem? Well, it could be A, B, or C. If it’s A, then I would expect that…). Write or talk out loud, if it helps. But don’t just sit there and stare at the code and hope for an epiphany.
• Work with and learn from other (aspiring) programmers. Coding/talking about coding with other people is hands down the fastest and most fun way to learn (I especially recommend pair programming). Of course, the best possible thing you could do for yourself is go to Hacker School.
*Some commenters have pointed out that since web development is just a small subset of coding, it would be more accurate to title this post ”Learning Web Development” instead of “Learning to Code.” They definitely have a point, so I hope that the title of this post doesn’t mislead people into thinking that web development is all there is to coding (there’s much, much more, most of which I don’t understand). That said, web development is still a subset of coding, so those who start in web development are in fact learning how to code.