Hello everyone.  Today’s topic is common programming mistakes and it’s a little unusual.  I don’t mean things like syntax errors, but rather misconceptions.

For example, if a creature from another planet were to observe us, it might notice that we all have our own computers, we work on our own separate files, we hand in our assignments individually, we’re graded separately, and so on.  It might _take_ programming to be something people always do on their own, independently. That would be a MIS-take.

With the notable exception of Dilbert, most programmers prefer to work with others, and do.

Programmers are usually part of a team including people filling many roles with whom they interact.  They have meetings, exchange phone calls and emails, and even instant message each other.  Programmers can interact with people like customers who are outside the team.  They also interact with each other very directly when they code together and check their work.  This is what we’ll do today.

Computer Science education, yours and mine, typically emphasizes writing programs.  It’s much more a composition class than a literature class.  The compositions are generally never revised or read by others.  They are written once and that’s the end of it.

Here are some typical activities related to programming and my estimation of how much effort is spent reading, writing, and re-writing.  In school we spend most of our time with the implementation, which is heavy on the writing.  In this project we are mostly reusing code and updating it so that the emphasis is on reading and re-writing.

When we program, our first concern is generally whether the program gets the correct answer or not.  We don’t worry much about how it is structured, whether it looks good, if someone else can understand it, if we might be able to reuse parts of it for another assignment, and so on.  Qualities other than correctness are addressed much later if at all.

We don’t want to pile up too many requirements on the code, but here is a short list of them.  Concentrate first on clarity, making it simple, readable, concise, and consistent and then move on to correct and potentially efficient.

So, here is a chance for us to broaden the perspective of anyone watching, either from outer space or from over your shoulder.  It might even be your perspective.  This is the scenario. You work for a company that has two products, a game and a business application, written by two different departments.  Both programs need a function to calculate the minimum and maximum values in a vector.  For the game, it is used to keep track of high scores.  If someone beats the lowest score in the top ten list, that person’s can be added to the list.  If the score is above the highest score, the person becomes the new champion. The business application includes a graphing function.  In order for all points to fit on a graph, you have to know the range of values, which is characterized by min and max.

Since both products are for the same company, only one solution is needed.  However, both departments in charge of the products need to be satisfied with the result.  They send you as representative of one department to work with a representative of the other department.  You both need to come up with a single solution.

This time we’ll just assign people randomly so that you don’t have to worry about being either Walley or Asok.

What we’ll do is called pair programming.  Two people work together in roles of driver and navigator.  This practice is becoming more and more popular in industry.  Colleges are starting to use it and it wouldn’t surprise me if you were asked about it at a job interview.  This exercise will be a small head start. It has been found that two people working together like this can often get more done than two people working apart. The driver uses the keyboard and mouse to enter the code, explaining what’s going on and reacting to what the navigator says. While the driver works on details, the navigator thinks about the larger issues.  For instance, that a function call doesn’t have enough arguments or that a particular variable name might be better.  The navigator watches for typos and other problems.  If someone needs to figure out some strange syntax or look up a library function, it is the navigator so that the driver can keep on entering code.  The navigator is not supposed to do this:

The navigator does not get to do what Wally is doing here or play computer games.

Rather than have you and your partner write the code from scratch, the company checked to see what was already available on the internet and found four different versions.  They can’t decide which one to use and aren’t really satisfied with any of them.  You need to read through the code and understand it well enough to decide which is the best one to start with.  You will want to make changes to this code either as you type it or afterwards so that it is better in some identifiable way than what you started with. Of course I wrote this code, so this is your chance to tear it apart and make it better.

The code you will see very shortly may look a little strange to you.  That’s always the case with someone else’s work, but this code is somewhat difficult to understand.  In some cases something was done once one way and once a different way so that it problems aren’t obvious.  Indeed, there seems to be a small bug somewhere in each version of the function.  You may be able to find it right away, but I encourage you to clean up the code first so that the problem is obvious.  Clean it up either way.

Here’s a reminder of the procedure.