In my first post, I mentioned that one of my goals for this blog was to learn by teaching. I suppose this is a lot like the concept of Rubber Duck Debugging where the act of explaining your code to someone, even an inanimate object like a rubber duck, forces you to think everything through in meticulous detail so that gaps in your own knowledge become apparent. It’s an interesting idea, and one that I’ve had a lot of success with in the past. Unfortunately, since I didn’t actually have a rubber duck on my desk (though I did have plush fish, which would have worked just as well), I tended to talk to my technical lead. Though I’m sure I bugged him more than my fair share, he probably got pretty used to me wandering over, ranting for two or three minutes, calling myself an idiot when the light finally flicked on, and disappearing back to my desk.

Anyway, in the spirit of rubber duck debugging I present to you my Programming Basics series. This will be a short series – just enough to get the basic building blocks into place to build out a real, though fairly trivial, project I’ve been meaning to create. From there, we’ll move into the actual project, explaining new concepts and updating (also known as refactoring) our code as we go.

Well, the type of programming you’re doing and the language (and type of language) you’re using plays a big part in defining this, but it really comes down to one main idea: programming is about processing and manipulating raw data and turning it into useful information.

The project I mentioned wanting to build is a type of drinks recipe site, sort of like The Webtender. The programming of this website fits the definition I gave above. The aim of the site is to take user-contributed drink recipes, variations, votes and comments (the “raw data“) and use it to allow people to look up their favorite drinks, find new ones they might like, and suggest things to make when they’re trying to throw a party with just a few different types of alcohol to use (the “useful information“). Admittedly, this isn’t as useful or complex as crunching numbers to find a cure for cancer, but it still fits the definition.

From a practical perspective, a person writes a program by giving the computer a set of instructions to use in order to get the data from its raw state to something useful. These statements are written in one of many programming languages (such as C#, Java, Python, or PHP). These languages have their own unique grammar (or “syntax”) which are generally unlike spoken languages, such as English. Also unlike English, where minor grammatical errors (for example, saying “John and me are going to the park” rather than “John and I are going to the park”) can go unnoticed, even the slightest mistake in a programming language will result in an error message which will cause your program to fail to run.

For now, until we get into working with PHP a few blog posts down the line, we will just assume that our programs can be written in English. This is actually a fairly common technique used by professional programmers when trying to plan the code they are about to write. When we write computer instructions in English for planning purposes, we don’t have to worry about the computer not understanding what we mean. The English code is for our own use to describe what we want to do, so as long as these instructions make sense to us, and we know how to later covert it into a real programming language, they suit their purpose just fine. This sort of English-language code is referred to as “pseudocode.”

If you were to write a basic program to ask a user for their name and then print a warning message if they aren’t who they should be, the pseudocode might look a bit like this:


Ask user for their name
If the user's name is Steve, print "Hello Steve!"
If the user's name isn't Steve, print "This is Steve's computer, you're not supposed to be here!"


These sorts of statements are the basic building blocks of computer programs; they give the computer a list of steps to execute, one after the other, until the job is done.

In the real world, however, programs are rarely so straightforward. Most programs need to adapt to the data they are given, and to react in different ways depending on the data they are working with. In fact, in the pseudocode example above you can already see that, even in trivial examples, the computer often has to make a choice about what to do. A user’s name can never simultaneously be and not be “Steve” (unless of course the cat belongs to Erwin Schrödinger), so the computer will never print both statements listed in the program, even though the print instruction exists twice in the program code.

In the next post, I will describe how to code such choices into your program, as well as how to use other techniques to control when certain statements are executed.