What is programming?

What makes a programmer?

If you have not programmed before, don’t worry. Programming is not rocket science—it is, well, programming. The hard part about learning to program is that you get hit at the start with a lot of ideas and concepts, and this can be confusing.

However, if you think that learning to program sounds like hard work and that you might not be able to do it, I’d strongly suggest that you put those thoughts aside. Programming is as easy as organizing a birthday party for a friend.

Programming and party planning

If you were organizing a party, you’d have to decide who to invite. You’d have to remember who wanted vegetarian pizza and which kids can’t sit next to each other without causing trouble. You’d have to work out what presents the kids would take home and what everyone would do when they were at the party. And you’d have to organize the timing so that the magician or the band doesn’t arrive just as the food is being served. To help, you’d organize the party using lists like those shown in Figure 2-1. Programming is just like this. It is all about organization.

If you can organize a party, you can write a program. What happens in a program is a little different, but the basic principles are the same. And because a program contains elements that you create and manage (unlike unruly kids), you have complete control over exactly what happens. What’s more, once you’ve done some programming, you might start to approach all tasks in a systematic way, so a bit of programming experience can turn you into a better organizer overall.

Programming is defined by most people as “earning huge sums of money doing something that nobody can understand.” I define programming as “determining a solution to a given problem and expressing it in a form that a computer system can understand and execute.” One or two things fall out of this definition:

• You need to be able to solve the problem yourself before you can write a program to do it.

• The computer has to be made to understand what you are trying to tell it to do.

You can think of a program as a bit like a recipe. If you don’t know how to bake a cake, you can’t tell someone else how to do it. And if the person you are talking to doesn’t understand instructions such as “Fold the flour and sugar into the mix,” you still can’t tell him how to bake the cake.

To create a program, you have to take a solution that you have worked out and then write it down in simple steps that the computer can perform.

Programming and problems

I also like to think of a programmer as a bit like a plumber. A plumber arrives at a job with a big bag of tools and spare parts. Having looked at the plumbing problem for a while, he opens his bag, takes out various tools and parts, fits the parts together, and solves your problem. Programming is like that. You are given a problem to solve, and you have at your disposal a big bag of tools, in this case a programming language. You look at the problem for a while, work out how to solve it, and then fit the bits of the language together to solve the problem. The art of programming is knowing which bits you need to take out of your bag of tools to solve each part of the problem.

The art of taking a problem and breaking it down into a set of instructions you can give to a computer is the interesting part of programming. However, learning to program is not simply a matter of learning a programming language. Nor is programming simply a matter of coming up with a program that solves a problem. You must consider many things when writing a program, and not all of them are directly related to the problem at hand.

To start, let’s assume that you’re writing your programs for a customer. He or she has a problem and would like you to write a program to solve it. We’ll also assume that the customer knows even less about computers than we do. Initially, you’re not even going to talk about the programming language, the type of computer, or anything like that; you are simply going to make sure that you know what the customer wants. Because programmers pride themselves on their ability to come up with solutions, as soon as they are given a problem, they immediately start to think of ways to solve it—this is almost a reflex action. Unfortunately, many software projects have failed because the problem that they solved was the wrong one. Coming up with a perfect solution to a problem the customer doesn’t have is something that happens surprisingly often in the real world. The developers of the software quite simply did not find out what was required or desired. Instead, they created what they thought was required. The customers assumed that because the developers stopped asking questions, the right solution was being built. Only at the final handoff was the awful truth revealed. It is very important that a programmer should hold off making something until she knows exactly what is required.

The worst thing you can say to a customer right away is “I can do that.” Instead, you should first think, “Is that what the customer wants? Do I really understand what the problem is?” Asking these questions is a kind of self-discipline. Before you solve a problem, you should be sure that you have a watertight definition of what the problem is, which both you and the customer agree on.

In the real world such a definition is sometimes called a functional design specification, or FDS. An FDS tells you exactly what the customer wants. Both you and the customer sign it, and the bottom line is that if you provide a system that behaves according to the design specification, the customer must pay you. Once you have your design specification, you can think about ways of solving the problem.

You might think that having a specification isn’t necessary if you are writing a program for yourself, but this is not true. Writing some form of specification forces you to think about your problem at a very detailed level. It also forces you to think about what your system is not going to do. You need this clarity when building something for yourself as much as when you are working with a customer. The specification sets expectations right at the start.

Modern development techniques put the customer at the heart of development and involve them in the design process in an ongoing way. These techniques reflect the assumption that it is very hard to get a definitive specification at the start of a project. As a developer, you don’t really know much about the customer’s business, and the customer doesn’t know the limitations and possibilities of the technologies that can be used to solve the problem. With this in mind, it’s a good idea to make a series of versions of the solution and discuss each version with the customer before moving on to the next one. This is called prototyping.

Programmers and people

Finding out what the customer wants is one of the most important aspects of any programming task. However, communication with other people is important in lots of other situations, too. Perhaps you want to convince a wealthy backer that you have the idea for the next big thing or persuade a customer that you have the best solution to his problems.

Not all programmers are great communicators at the start. But the important thing to remember is that communication skills can be learned, just like a new programming language. This might mean going outside your comfort zone—nobody likes standing in front of an audience for the first time—but with practice you can master communication skills and vastly increase your chances of going a long way in this business.

Effective communication also extends to writing. Being able to create text that other folks can read is a very useful skill, and again, the best way to do this is with practice. My advice is to start writing a blog or a diary. It doesn’t matter that only your mom reads your blog at first; the important thing is that you write regularly. If you write about something you are interested in (I write about programing—surprise, surprise—at www.robmiles.com), you will quickly become much better at it.