How to Teach Yourself Web Development

By David Turnbull

At the age of twelve, after discovering the “Save as Web Page” option in Microsoft Word, I started to teach myself web development. I learned HTML first, of course, and then CSS and JavaScript, and then bits and pieces of PHP and Rails. (These days, I’m quite fond of Meteor.)

Over the years that followed, I considered getting a formal education, and I could see the value in doing so, but in the end:

  1. It was too expensive.
  2. I struggled with learning in a classroom setting.
  3. I was already making comfortable progress.

But it’s not like this was always an effortless process. I wasn’t just learning how to write code for the web, after all. I was also learning how to learn, and that’s what we’re about to discuss.

Here are five steps for teaching yourself web development.

1. Pick an area of web development that excites you.

You can’t just “become a web developer” by reading a certain book or watching a certain number of videos. Web development is a big field and trying to be a jack-of-all-trades will likely leave you exhausted, frustrated, and only a little further ahead than when you first started.

Being a web developer is like being a scientists. There are foundational ideas that apply across disciplines but, ultimately, you need to specialize. You have to commit to something forever though — it’s easier to move to another area once you’ve mastered one — nor will you be limited by your choice. Someone who is intricately familiar with PHP can do a lot more than someone with a basic grasp of ten cutting-edge web technologies.

But at this point, there’s no right answer. As long as you have a grasp of HTML and CSS, you simply need to pick whatever seems interesting. Perhaps discover what your favorite websites are built with. You’ll find that Rails is all over the place but JavaScript frameworks are on the rise. I’m working with Meteor because I like its real-time features. Your reasons, however, don’t precisely matter. Just try to follow your own interests, since that’s the only way you’ll be able to maintain your motivation.

If nothing specifically excites you, stick with the most common technologies, like JavaScript and PHP. There’s so much training material available that you’ll at least get a thrill from the abundance of available support.

2. Ignore (most of) the “guidance” from seasoned web developers.

Seasoned web developers usually offer well-intentioned advice to beginners that is completely impractical to implement. This is because they:

  1. Don’t remember being a beginner.
  2. Expect too much from someone who just needs to grasp the basics.
  3. Have preferences based on problems you may never encounter. (Such as issues with scaling to millions of users.)

Ask what language you should learn, for instance, and the debate that follows won’t be what’s best suited for you. It’ll be a debate based heavily on the biases the developers themselves have developed through their work.

Here’s how I see it:

Whether or not you start learning PHP or Rails or JavaScript, or whatever else, is irrelevant. Why? Because making the switch from one language to another is incredibly insignificant compared to making the leap from not being a web developer to then being a web developer.

There are experienced web developers with great advice but, when advice is offered, ask yourself: Is this truly the best way for a beginner to approach this process? Or is this simply how the developer had wished they’d learned?

3. Give yourself a precise (and achievable) project.

After learning the basics of web development, try building something without following a book or tutorial. By far, this is the most effective way to:

  1. Get the thrill of making something.
  2. Discover the weak spots in your knowledge.
  3. Learn how to actually solve problems.

It doesn’t matter what choose to build but keep the scope of the project as small as possible. If you can forsee yourself spending days on this project, it’s too big. Make it smaller. You don’t want it to drag-on.

Also make sure to define an end-point for the project. What features will it have when you can label it “done”? You want to know when you’re allowed to feel satisfied with what you’ve made. (And this doesn’t have to mean when the project is ready for the world since there’s no need to publish the creation.)

Depending on what area of web development you specialise in certain projects may be simpler to create but here’s a few ideas worth considering:

  • A to-do list application.
  • A private blogging tool.
  • A tool for tracking workouts.

Basically, any sort of project that’s main purpose is to track some basic data is a good way to test your knowledge as a beginner.

4. Commit to a specific amount of daily practice.

When you’re getting started with web development, you’ll make quick progress in some areas, but there’ll come a time when your progress slows and this is where a lot of beginners throw up their hands in frustration, and give up.

This happens because beginners usually rely on achieving milestones to feel satisfied. Milestones aren’t predictable though. After getting a handle on the basics, you can go days or weeks without making significant leaps.

There is, however, an alternative approach:

Instead of focusing on achieving milestones, commit to learning and practicing web development for a specific amount of time every day. At least twenty minutes is a good starting point but there’s no precise limit or requirements. Just pick whatever length you can reasonably manage on a consistent basis.

The point in commiting to a time frame is that you’ll then allow youself to feel satisifaction for meeting that commitment. The milestones will continue to arrive, but as a pleasant by-product, rather than an unpredictable goal.

5. Engage with a significant amount of training material.

You may have seen the writing-focused video from Ira Glass where he suggests that people “do a lot of work.”

Ira Glass on Storytelling from David Shiyang Liu on Vimeo.

It’s a simple belief that leads to a state of skill, and the idea easily applies to web development. You have to write a lot of code if you want to be a developer but what a lot of people don’t realise is that the code doesn’t have to be your own. There’s an immense value in following along with the code from books and tutorials and video training material — like that covered on sites like SitePoint and in books and courses from sites like Learnable.

You do have to be engaged with the material — you should consider the purpose of each line of code as you’re writing it — but even though you’re “learning by rote”, you’re still learning.

Here’s what most people don’t consider:

The syntax isn’t the difficult part of web development. It’s a stumbling block for beginners but, afterward, the tricky part is determining how to think about how to solve certain problems. Here, the grand irony is that beginners often think of far more complex solutions than a professional would.

With this in mind, the benefit of following allow with an immense amount of training material is that:

  • You can see how different developers solve different problems.
  • You can see how different developers solve similar problems.

When you’re ready to work on your own projects, this exposure to how problems can be solved will provide the mental tools required to:

  1. Identify the core of what the actual problem is.
  2. Figure out what’s required to solve that problem.

You may not be able to recall any precise solutions, but that won’t matter. Most problems have been solved before, in some form or another, and half of the difficulty of “speaking in code” is understanding what you’re trying to say. Beyond that point, the syntax and details are far easier to grasp.


I’ve only shared a handful of “big picture” tips for teaching yourself web development, but they’re definitely things I wish someone had told me when I first got started.

If you’re already on your self-education journey, where did you begin? And how have your techniques for learning changed since first getting started?


Thanks for this. As one who is struggling to make much headway with learning JS, it's always good to have some pointers. My weakness is that I'm not good at "getting my hands dirty", so to speak—which seems to be essential for learning to program. But I've had to accept that reading the books and getting the theory is simply not enough.

There are some older JS books I like, but I know there are more modern ways to code JS. One exercise I've been finding useful is to see if I can adapt those older scripts to newer conventions, as well as stripping out deviant code for older versions of IE, stripping out dependency on jQuery etc. It's very satisfying to adapt code like that.


Good tips, but I strongly disagree with your second point. Yes, there are crusty old devs who refuse to learn new technologies and techniques, but one of the best ways to learn is to find a mentor. Learning web dev is very hard because you have to really learn at least three technologies at once to make anything useful (HTML, CSS and JS, plus something server-side or graphic design).

As someone who frequently helps people learn web development, countless times I've seen people fail at the getting started phase and they need someone to ask for help. StackOverflow and forums are great if you know enough about what you're doing to phrase the question. Sometimes all you know is "it's broken." Having someone you can sit with and say, "what's wrong here?" is extremely valuable.


Whether or not you start learning PHP or Rails or JavaScript, or
whatever else, is irrelevant. Why? Because making the switch from one
language to another is incredibly insignificant compared to making the leap from not being a web developer to then being a web developer.

That issue comes up when you ask for help and someone chimes in with the belief that in order to receive the correct kind of help, a certain approximation needs to be established that determines the mediums used to fulfill requirements, hence the constant topics of languages, etc. That always comes up when someone coming into the field(s) inquires about what they need to learn: the common response I always see others reply with is, "Well, what do you want to do?" (Which incites the language dialogue because most enterprise shops have traditionally used a specific set of technologies whereby those not considered enterprise would use others -- as an example, I mean.)

I think I get what you're trying to explain there and it makes sense... It's just that the initial baby steps someone takes when trying to become whatever a "web developer" is anymore is monumentally defined by what exactly said steps consist of and due to how these fields are, everything boils down to specifics.

(And don't take that in any specific way -- it was just something that came to my mind when I read that part of the article, which was great, btw. smile )


I've been a "designer" for o ver ten years, and a dev for 8 or 9. If you really want to be a dev, read a lot of books on dev. The worst mistake i think a dev student can make is believing that all the info is on the net, so therefore there's no reason to buy books. Books are so much more comprehensive. They take you to the next level, whatever that happens to be for you at the time.


Could you give an example of something where the book is more comprehensive than reading it on the web? I find your claim to be actually opposite of my own findings.


Individual topics may not be more comprehensive, but the advantage of a book is that it puts all the pieces together systematically. I see a lot of people who've learned web design piecemeal on the web, and who thus have bigs gaps in their knowledge, because their learning on the web was about grabbing random bits of info here and there.

I'm sure everything could be found on the web, but usually the learner doesn't know what to search for to make sure all the gaps are filled in. That's why I recommend starting with a book, then moving on from there.


It's been a long time since my major learning phase, but one book that comes to mind was called "Advanced PHP5" by Larry Ullman. I had read a lot of PHP books, but this one really helped me with OOP concepts, among other things. I find some online resources of great value, such as the PHP docs, but it doesn't tell a story the way "Advanced PHP5" did. Theres a lot of info in a book like this, info that is consolidated. I could find all of that info browsing the internet and looking at multiple websites, but this book packages it up nicely. It pieces the info together in a way that could be puzzling if broken into parts and spread across the web.


Nicely put, @Oscar_Blank. thumbsup

Spot on.


Ah yes that does make sense. Thanks for the clarification Ralph!


Agree with pick, give, commit and engage but I can't go with ignore. While it's true I am ancient, what this advice assumes is that older web devs stop learning. Any developer who does that will soon be an ex-developer, young or old. What you get from experienced devs is (or should) is not how to implement specific technology but how to approach it, how to think about it and how to come up with your own answers. As newz2000 says, that kind of mentoring is invaluable.


Yeah, publishers still have to pay people to be editors and writers.

With books/magazines/journals/etc you are reading something from someone who is almost always being paid, and companies that want to stay in business do not pay people who are idiots.

By contrast, any fool can publish stuff on the Internet - and they do!!! wink

There is lots of great free content on the Internet, but it often lacks the rigor and editing for which published materials are known.

P.S. There is this publisher called SitePoint that puts out some pretty nice books - which I have bought - that can compete with anything on the Internet. (I enjoyed some of the SP CSS books...) smile


Agreed. The author's reasoning behind his option may on the surface seem sound, but in reality it's smoke and mirrors. Asking ANY developer what language someone else should work in is like asking them what automobile is the best to be chosen. The answer that will be given will be based on experience and comfort levels.

A mentor is crucial to developing the RIGHT approaches and methodologies. How to approach a problem, the pitfalls to avoid, etc. I have always said that a number of our problems with the current state of web development came because people decided that it was cheaper and easier just to add more hardware to a problem rather than learning to develop properly. Memory management, efficient code structure are two areas which "seasoned" developers, especially those that started outside of the web realm, are hands down better at. Database structures are another area which the tools available today can almost cause more problems than they can correct.

There are things that can be learned from us dinosaurs that used to have to learn to work within the boundaries of the machines we worked on. Battery life on mobile devices would be astonishing if the developers of today's mobile operating systems took some of the concepts that us old mainframers employed.


Awesome article and learned a few things. Perhaps, I should hold my opinion on "How to do it right"... this is one of those things developers needs to make the mistakes to understand the concept.

Get the latest in Front-end, once a week, for free.