Yeah, I consider myself primarily a web developer. It's a fun world to live in. I've written a lot about what that means, but I want to give a kind of intro to it here before you read everything else. I want you to see the whole picture.
web development is building stuff for the web! it's between designing things and engineering things. being a developer means you need to do a little of both. a designer designs an experience and typically hands it off to an engineer to actually make it work. an engineer takes a design and figures out how it should work best and build it. a developer looks at it a little more abstractly: it's more like fixing a problem or bringing an idea to life.
I often compare it to photography. There's the brilliant photographer who can take amazing pictures and there are the genius technicians who can make that photo negative turn into an amazing print. The person in between is one who can take great photos and develop them by themselves. They may not be the greatest photographer or have the most amazing prints, but they are the master of the entire process, and can look at it as one process.
I also often compare the developer to a magician, being given a problem or an idea and seeing it to at least an initial implementation. Go to a meeting, figure out what someone needs, and come back in a week with a functional decent-looking result. Magic. Prototyping and agile development are a magician's sport.
There is, of course, a cost for this attitude: you won't get the level of polish and glamour a designer would bring or the benefit of systematic problem-solving an engineer would toil over. Instead the developer focuses on results and efficiency of process. For this reason developers are great at being good at as much as they can and being able to rapidly produce solutions, even if they don't look the best or are the most programmatically efficient.
the whole picture this series will try to fill is this: you want to make a website that's dynamic and looks good and whatever. how do you do that?
A web developer should know all of these steps and be familiar with them. A web developer, alone, should be able to build a blog from scratch and make it look decent.
your best friend is a good API/programming reference. your task here is never to learn a programming language through memory; it's to learn the syntax and then know how to look up its vocabulary.
think of any foreign language... you don't need to know every word, you need to know its grammar. you have a dictionary to look up all the words you don't know.
engineers will learn C++ or perl or fortran or whatever through raw memorization; you don't have to. the only thing you really have to remember is how to look it up.
gotapi is a good place to start.
followed closely by google, lol.
eventually you'll also want to get familiar with google chrome's built-in dev tools or firefox's firebug extension. every good web developer uses them. but you don't have to really worry about that now.
the best way to learn is to do. the best way to learn is to ask. the best way to learn is to surround yourself with examples from people who know what they're doing.
so come up with a project to practice with. a good, simple, beginner project is to make a blog site, or a to-do list web app.
ask people who know more than you, who are experienced, about how they got where they are. ask them where they think they are now.
go to sites you really like and try to figure out how they did it, and keep trying until you get it right.
remember that web developers make prototypes, or small quick trinkets to highlight a solution to a problem. they don't have to be pretty or complete, they just have to work. I have probably a hundred folders of quick prototypes in a dozen languages; it's how I learn.
honestly i'm writing these guides as a mix between guide and tutorial and essay and thought-process. i'll switch from upper to lowercase, from capitalizing sentences to not, utilizing bulleted lists and code examples. i'll try to be concise and yet informative. tell me if i'm not.
I write a lot like I'd try to talk to you. I've taught people a lot of this stuff before, and I've always found that a more colloquial approach to learning is better and easier. this is a pressure-free learning experience; there are no grades or anything, i want you to read these because you want to.