I remember way back in the day when I was learning HTML. I was at University of Michigan and happened to be sitting next to an experienced developer in one of the computer labs. He noticed that I was using one of those WYSIWYG web design tools (I think it was the now-defunct Adobe GoLive.)
Probably just from glancing at me working for a couple seconds, he was able to determine that I was a total newbie. He asked me if I was learning HTML and I nodded, feeling slightly embarrassed. So he asked if he could give me some friendly advice:
“When you’re learning, don’t use any of those tools that do stuff for you. Code everything by hand. Otherwise, you’re not really learning to code.”
At the time, I didn’t think much about the advice he gave me, but in hindsight, it was maybe one of the most important pieces of advice I’ve been given and it has stuck with me ever since.
In the case of a tool like Dreamweaver or some other WYSIWYG tool, where you can drag and drop stuff onto a canvas and the tool will write the HTML for you, it might be pretty obvious: if you’re not actually writing the code yourself, then you’re never going to actually learn to code. Worse, the code being created is likely to be pretty god-awful. (In general, I would recommend that you do not use a tool like Dreamweaver, but instead use something more light-weight and modern like Sublime Text.)
He then showed me how to open up my html files using a basic text editor like Notepad, and said I should code every last character by hand. “Having to repeat all that markup over and over is what is going to allow you to learn.”
But this lesson runs deeper than that, and may manifest itself in more subtle ways.
First, it is not limited to HTML markup. In general, anytime you are using a tool that is writing code for you, or in which you are using ready-baked code, you should think long and hard if you want to use that tool. Here are some examples of what I’m talking about:
- Frameworks – don’t use a framework, like Bootstrap or 960 or whatever. Better to start from scratch with a basic HTML page and learn to evolve the page design from there.
- Preprocessors – I love Compass and Sass, but I would strongly recommend against using it if you’re learning CSS. It’s just too much to learn all at once.
- Abstraction Languages – Coffeescript, HAML, and other similar tools allow you to code in a much more succinct way. With HAML, for example, you don’t need to type in any closing tags or use any brackets, but instead just rely on indentation. It’s super-fast, but if you’re trying to learn that and HTML and ERB, you’re just trying to chew more than you can swallow. Learn HTML and ERB first, or whatever language is being abstracted, and get really good at that, then starting using these abstraction languages.
Where do you draw the line?
How far do we want to take the idea of doing everything from scratch? Does this mean, for example, that you shouldn’t use Rails and instead re-create everything Rails does directly in Ruby? (In case you didn’t know, Rails is basically a gem or mini-framework that sits on top of the larger programming language Ruby.)
Well, it’s going to be judgment call, and in the case of using Rails, I think that is a good place to draw the line. You should definitely be focusing on learning Ruby, but that doesn’t mean you shouldn’t use Rails as well, which will save you a lot of time, if you’re creating web applications, that is.
The main rule of thumb, though, I’d say is this:
Learn the underlying language first before starting to use a tool that makes using it easier.