5 Minute Guide to Learning Programming

After many years teaching programming, I have noticed a student work pattern that needs to be broken. Students simply do not approach programming projects the right way.

Your natural tendency is to do something called “blasting code”. You type in a bunch of code, sometimes by just typing in something you see in a book, or (much worse) copying and pasting something. You then add something new and try to run it. More often than not, you then spend WAY too much time trying to figure out why nothing works!

What did you learn by doing that?

Nothing! (Well, maybe your typing (or pasting) skills improved, but you learned nothing about programming!

DON’T DO THAT!

Programmers and Car Mechanics

Programmers are a lot like car mechanics. Both have a tool kit they will use to solve problems. The trick is to know what tool to use at what time as you solve a problem!

A new car mechanic, when handed a box of tools by a car wizard, does not take that box to a broken car, open the lid, and grab the first tool that comes out to work on the car.

Nope!

Instead, they spend some time studying each tool. It is in the box for a reason. It should be used in the right situation and only then. Each tool does one thing well, and cannot be forced to do something else. (Those folks who use hammers to drive in screws notwithstanding!)

Note

Tools are important, and you need to learn about them, and use them wisely. When I was a freshman at Virginia Tech (many years ago!), I got what you would call an Internship at McDonnell Aircraft Corporation in St. Louis. They were building F4 Phantom II fighter jets for the military in many different countries, and the Gemini Space Craft for NASA. It was a really cool place to work!

I was walking down the Phantom assembly line when I saw a huge tool chest full of shiny tools next to a new fighter jet. The thing was immense. I reached out to pick up one of those cool tools, only to hear a guy scream at me: “Don’t mess with my tools!”. I said I thought the company owned them, and he told me he owned each and every tool in that chest. There were thousands of dollars worth of tools there (and this was in 1965!). The company paid him a nice salary and included enough that he could pick out his own tools to do his work. We ended up having a nice talk about being a professional, and building amazing things. Airplanes in his case, computer programs in mine! I never forgot the lesson I learned that day!

Baby Stepping

The right approach involves something called “baby steps”. If you read about programming these days, you might see this rule:

“Find the smallest thing you can change in your code and make that one change. Make it work before you move on.”

What?

Code Should Run

The key idea here is that your code should always run. Maybe not correctly, and certainly not completely, but it should run. I cannot tell you how many programming assignments I have seen turned in that do not even make it through the compiler. That is just plain silly! And, there is no reason to let yourself get into that situation in the first place!

How to Make Your Code Run

So, how do you make a baby step, and make it run?

Study Your Tools

First, study each tool in your kit and make sure you know how it works, and how to type it in. (Not paste it in! You cannot copy and paste your way to a job!)

You really only have a few basic tools to learn:

  • sequence - on thing after another (not really a tool, just a way to use other tools)
  • Decision - the if-then-else statement that asks a question, then does one of two separate things.
  • Loop - do one thing over and over until something says to stop.
  • You also need to understand what a variable is, how to create one, and what that variable can contain.
  • You need to understand how to get data into the computer, and data back out of it as well.
  • And, you need to understand something about forming expressions. That involves that ugly math stuff. Programming in some languages lets you do fun thing like this:
print(50 * "*")

Which prints out a string of 50 asterisks. I sure wish C++ allowed that!

Write Dummy Code

Next, learn how to write “dummy” statements. You know you need to use a certain statement at this point, but you are not ready to write the whole thing. The most common place this might be useful is in a decision statement, where you do not know what the question should look like. Try this:

if( true) {
    cout << "something happens if true" << endl;
} else {
    cout << "if I see this, I broke something!" << endl;
}

Sure it is silly. That true is actually just a place-holder for code you will add later. For now, it is simple, a bit cute, and it should run! Those output statements will tell you which path the program took when it reached this code.

Once you learn about functions, write something like this:

int cool_function( void ) {
    cout << "When I figure it out, something cool will happen here" << endl;
    return 42;
}

Note

The function I created said it was going to return an integer, so I returned one. Which one? The “Universal Number”, of course. Once again, it is not right, but it will run! I will fix this up later.

Yes, this also looks silly, but programming is supposed to be fun, make something happen first, and tune it up as needed later!

Know What Will Happen

Finally, learn to know what to expect when your code run.

In that decision code example, I know what I will see when it runs, If I see the wrong output (or no output) I should be able to figure out why in short order. I am not studying tons of code, just a couple of lines I just typed in.

That is Baby Stepping!

An Example Session

In one of your labs, you need to write some numbers to a file. Let’s Baby Step our way to a start on that problem.

Starting Code

What is the shortest program you can write in C++ that will work? I am thinking “Hello, World!” and you should know this one by heart!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// Baby Step Lab
// Author: Roie R. Black
// Date: April 4, 2016
// Class: COSC1315

#include <iostream>
using namespace std;

int main()
{
    cout << "Baby Step Lab" << endl;
}

Note

Please identify yourself in your code. Some time later, you might look at this code and have no idea where it came from. A proper header (an identification comment at the top of your code) will help you identify the code, when it was written, and why. For me, if I see exactly the same code over and over, I start to wonder who actually wrote it, and who copied it. In school, copying another student’s work is forbidden. You do not want someone getting a job you want based on their ability to copy your work, do you?

Will this run? (It should!) Do you understand why each line is there? (You should!) If not, fix it before you move on. Did it run?

Add something new

We want to write a number to a file. How do we do that? First we need to create a file variable (actually, it is called a file “object”). To do this, we make a simple change to our code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
// Baby Step Lab
// Author: Roie R. Black
// Date: April 4, 2016
// Class: COSC1315

#include <iostream>
#include <fstream>
using namespace std;

int main()
{
    cout << "Baby Step Lab" << endl;

    ofstream outf;
    return 0;
}

This code will run exactly as before. The critical point is that it will run!. Do you know what we just did? If not, figure that out!

Next Change

The next change will actually create a file, but it will not have anything in it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
// Baby Step Lab
// Author: Roie R. Black
// Date: April 4, 2016
// Class: COSC1315

#include <iostream>
#include <fstream>
using namespace std;

int main()
{
    cout << "Baby Step Lab" << endl;

    ofstream outf;
    outf.open("test.txt");
    outf.close();
    return 0;
}

When we create an actual file, we ask our file “object” to open up a file on your system disk, and we give it a name. Make sure the name includes a “file extension” like .txt so the operating system can tell what kind of file this is.

This code will open up a file, put nothing in it, and close it. When the program ends, you should see that file on your system.

Warning

Where some tools, like Visual Studio, hide your file is something you need to figure out!

Output a Number

Once we know we can create the file, let’s stuff a number in it!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
// Baby Step Lab
// Author: Roie R. Black
// Date: April 4, 2016
// Class: COSC1315

#include <iostream>
#include <fstream>
using namespace std;

int main()
{
    cout << "Baby Step Lab" << endl;

    ofstream outf;
    outf.open("test.txt");
    int data = 1234;
    outf << data << endl;
    outf.close();
    return 0;
}

Check to see that this number really made it into the file before you move on!

Get a User Number

Next, and this will be our last step, let’s ask the user for the number to output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Baby Step Lab
// Author: Roie R. Black
// Date: April 4, 2016
// Class: COSC1315

#include <iostream>
#include <fstream>
using namespace std;

int main()
{
    cout << "Baby Step Lab" << endl;

    ofstream outf;
    outf.open("test.txt");
    int data = 1234;
    cout << "Enter a number: ";
    cin >> data;
    outf << data << endl;
    outf.close();
    return 0;
}

That is enough of a demonstration to show you how this works. One of you should remember this example, we did exactly this in my office when your code did not work.

One Last Thing

Do not fall in love with your code. Be willing to throw the whole thing away if it gets out of control. There is another saying in the programming world:

Plan on throwing one away, you will anyway!

I wrote a huge Python program for my Master’s Degree in Computer Science at Texas State, I threw the code away three times. It was version four that I was happy enough with to use for my research project!

You learn something by getting stuck. Remember how you got here, and find a better way to get things done in your next version.

I am a firm believer that your entire experience with programming will be much more rewarding if you follow this simple approach. As odd as it may seem, you may actually get things done quicker, since you spend far less time puzzling over why nothing works!

The best way to speed up, is to slow down!

As an incentive to try this out, I am going to post an assignment for you to work on until the end of the term. Check the next link.