Hammers and Nails and Writing Complicated Code

The ability of students to find complex solutions to simple problems is a constant source of amusement and amazement. I’m probably neither the first or last teacher to make that observation.

One of the great things about programming is that there are usually many ways to solve the same problem. Of course the goal is always to find the fastest and most easy to understand solution. What I have noticed from my students lately is that they often tend to focus on the tools they understand the best and try to use them in places where they are not always ideal.

What I am seeing recently is that some kids really "get" while loops and other really "get" for loops. So they sometimes use while loops when a for would be easier and for when while would be easier. Using the type they are more comfortable with often means they have to add complexity.

For example I had a student create a for statement with a pretty complicated evaluation in the middle. The initialization looked typical as did the incrimination at the end. The comparison in the middle though checked two different conditions neither of which was related to the loop control value. Index out of range errors almost inevitably followed. Adding a third condition will fix the problem but really the problem called for a while loop.

Likewise some students seem to love to use while loops to initialize arrays when a for just strikes me as more natural and less complicated to set up. There is nothing intrinsically world with these various solutions. They just sometimes require some modifications that make the program a little more confusing. Confusion is code is almost never a good idea.

I don’t blame students for these things. For most it is a lack of experience at looking at the problem and spending the time to find the simplest solution. Students just seem to want to start writing code and making it up as they go along. Their natural inclination when something goes wrong is to add more code. Sometimes that is what is needed but often times what they really need to do is redesign the code and approach it from a different direction.

They’re going to invent things that are new to them because they haven’t seen enough other ways to do things. Complexity seems like the answer because simplification seems, to the inexperienced programmer, to be the path away from completion.

Eugene Wallingford tweeted the other day that “In practice, simplifying a sentence almost always makes it better.” I replied that the same is usually true with code and he agreed. We tend to teach students that more words is better. Better in research papers for example. I had a student turn in an essay with a 95 word sentence not that long ago. I’m pretty sure that would have been better as several smaller sentences. Likewise breaking code down into smaller segments and keeping those segments as small and tight as possible usually makes them better.

Simplification is something we have to teach. using multiple tools and methods to solve problems is something we also have to teach. We need students to be comfortable with multiple tools so that they are ready, willing, and able to use the best tool for the job.