01: A First Program

The very first exercise simply has you printing things to the screen. We will use something called console.log. This may seem like a lot to type just to print something to your terminal, but remember that JavaScript comes from a history of the browser. In the browser there really is no input and output other than the HTML page. We are using JavaScript from the terminal, and Node simply uses the browser console to talk to the terminal.

The Code

The format of these exercises is very simple:

• You read the exercise and the code as best you can.
• You then attempt to type in the code yourself based on what you saw me do.
• If you run into trouble, you can email me at help@learncodethehardway.org or contact me on the chat channel. Just be sure to give yourself 1-2 days before you ask for help.
• Then you should try to break your code in different ways to see what happens.
• Finally you can attempt the study drills, but don't get stuck on them. They are intended more as additional studies and exercises for you to try, but if they are too difficult feel, free to record which ones you couldn't do and come back to them later.

Here's your code:

console.log("You are writing text to your screen.")
console.log("This is called 'standard output'.")
console.log("This stuff in the ( ) is a string.")
console.log("Start a string with a double-quote.")
console.log("Write what you want.")
console.log("Then end with a double-quote.")

Work In Chunks

If you watch me (or someone else) code in a video you may see me work very fast. This is mostly to save time on the videos and not actually how I want you to attempt these exercises. Obviously, if you're an experienced programmer you can do whatever you want. But, if you're a beginner then you should do the code in tiny chunks.

You do not write code by writing hundreds of lines and then expect it to work. Computers are ruthless when it comes to mistakes. Every line you write has a chance of having a mistaken, and this probability of mistake increases with each line. This means if you write two or three lines there's a smaller probability of a mistake than if you wrote 700 lines. The easiest way to code is to actually write only a few lines at a time, then run your code and fix any problems that you have. This helps you focus on where the errors could possibly be because most likely any errors you get on each run are in the lines you've just written.

Now, you may think that writing code is similar to writing an essay. In an essay you have your idea, you come up with your structure, and then you write a first draft. Once you have your first draft you go back and you edit it. Programming does not work this way. In programming, things work way better if you write small little pieces, review them for errors, then run them and fix any problems you run into.

Dealing with Mistakes

Programming is brutal. The computer's job is to tell you that you are wrong all day long. It does not care how you feel, or that you're having a bad day, or that you think what you wrote should work. The only thing it cares about is that what you wrote matches what it expects to see. Any errors in what you write usually result in a very cryptic error message that is difficult to decipher. For some people this can be a humbling experience. But the fun part of programming is that after you've made all these mistakes you finally get it working and you feel like a hero.

When you make a mistake don't take it personally. Simply try to find out what you did wrong, and try to fix it. Usually if you are writing the code in small chunks what you have to look at is a fairly small piece. Sometimes though, the problem is much more complex, so I will try to show a few errors that come up that you should anticipate. Ultimately though, a lot of programming is learning how to debug your terrible code. It's quite all right for your code to be terrible in the beginning; you simply have to work on it until it's better.

I am also a huge fan of throwing out garbage. If you write some terrible code and it's full of errors, or you didn't follow my instructions and wrote 700 lines of garbage, then throw it out. It is demoralizing to attempt to fix a lot of very terrible code. It's easier to simply trash it and start over based on what you already know and do it better again. In fact, I would say it's better for you to focus on slowly building code and keeping it working as you build it than it is to be able to print out hundreds of lines and then fix it later.

What You Should See

You are writing text to your screen.
This is called 'standard output'.
This stuff in the ( ) is a string.
Start a string with a double-quote.
Write what you want.
Then end with a double-quote.