Search CompSci.ca
Subscribe
Education
Super Paper Programming
In today’s over digitalized environment, I think that many people, especially younger students, are missing the value that paper and pencil still supply to the field of computer programming. No, not the punchcard programming, or writing pseudocode on a paper exam — that’s bad. I’m talking about sketching out your concepts — that’s good!
It’s difficult to implement the code, if the ideas involved also have to be figured out at the same time. Some students jump to their code editors, but the efforts quickly come to a halt as the problem at hand exceeds trivial knowledge. This is especially apparent with problems involving Geometry. How would one figure out if two circles collide with each other? Sketching out the situation on paper leads to the answer much faster than a blank stare at the variable names.
There are at least two parts to this approach:
Figuring out something new. When faced with a new problem, we probably need to do some thinking and to explore some of the ideas that come up. One should be much more willing to make mistakes in a rough sketch on paper, than typing up code that might not even work.
In a sketch, we could also start out with familiar objects, and figure things out from there. For the above example, it should be obvious that two circles are involved. It’s much easier to spot, from the sketch, that the distance should also be measured. It’s not as apparent when the same two circles are represented by a few lines of code in a text editor.
Keeping it all in your head. Even if all the individual parts are well understood, sometimes it’s helpful to visualize how it all fits together. Perhaps more applicable to the data structures, or database layouts — sometimes the total amount of information can quickly become overwhelming. Having a diagram to refer to, keeps the mind available for figuring things out, not remembering all the details.
The technique of sketching our the situations of new problems encourages more thought to be put into development. This is why we explicitly allow “Unlimited amounts of pens, pencils, erasers, and paper” in the DWITE rules.
Together with rubber ducking, paper sketches are reasonable, accessible, and simply helpful approaches to problems. Sometimes, even more so than bothering teachers for hints.
Read more
Discussion
Post a comment
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Haha what a coincidence. In one of my classes we’re doing paper prototyping, class diagrams and such and we’re doing it on paper.
It’s true though, whenever I’m stuck I just write out my thoughts and it always helps. I think most people can think better when they write it out on paper than on a computer. Its the reason why a lot of people write out essays first on paper then type them up.
Reply to comment
Writing pseudocode is never bad. Steve McConnell advocates writing pseudocode before writing real code. When writing pseudocode, you don’t have to worry about the implemenation details right away. You can use the pseudocode as comments.
Reply to comment
@John, I didn’t mean that pseudocode itself is bad — it’s not. I just never was a fan of paper exam questions that ask to write code. Pseudocode could certainly be used along with the sketch, to allow for a new level of detail.
Reply to comment
I agree that many younger students are missing this. One of the hardest things to get beginning computer science students to do is actually think first. They want to get right into the code. At least at my school anyway. Give them a problem and the just sit there playing with the code until it works (or they think it works). Its a very ugly habit to get into.
Reply to comment
@neal, exactly! It’s a very common thing for students to do, especially at the early state, when this is easily accomplished. Then problem, of course, is when the task requires some deeper analysis and thought. I’ve seen too many high school students just sitting there, unable to do anything on their own.
Reply to comment
The problem is that the first couple years of Computer Science the programs that you’re asked to write are easy (small) enough to do it without much thought. I’m in 3rd year and this is the first year that we have a program that is large enough that we actually need to design properly.
I think that a design course should be done in 2nd year to get it drilled into the students heads that this is the proper way to code. We’re currently writing modules for moodle and if we didn’t design first we’d be lost.
Design should be taught very early on because it’s probably one of the most important parts of a program. If you don’t design properly you’re program could:
1) have a lot of bugs
2) be impossible to maintain
3) take a lot longer to program
4) cost a lot more
Reply to comment
Cs246 baby! UML, OCL, design patterns and more. Although I get the vibe that people are struggling more with C than with the design.
Reply to comment
@Adam — a problem doesn’t have to be “large” to require a sketch. Sorting binary trees for example. It’s not that big, it certainly doesn’t come in modules. Though grasping the concept of what’s happening to the tree’s structure, entirely in one’s head, is quite a challenge.
Though the point still holds — design should be taught early on.
@Martin — I get the vibe that people are struggling with Java, design, and just about everything else. CS134’s withdrawal deadline has been postponed into December.
Reply to comment
I remember in the 90’s, yes I am dating myself here. But I had sold my C64 thinking I was getting an Amiga 500. That fell through and I was left in the position of having $500 and no computer. A few years later I got my first PC. It was difficult to program without a computer. So out came the graph paper (best kind for coding) and I wrote a notebook worth of software without code. The beauty of it was you literally get a feel for the code and it forces simplicity. No copy’n'paste only cut’n'paste if you really wanted. If you have to do it more than once, you put it in a method/function otherwise your hand cramped.
As a side effect my code reads like an essay. And I write it like one. Start with an outlook at the highest level and do deeper. Simpler code, less code and only the last portions are generally low level. This keeps it portable and maintainable.
Reply to comment
@Darrell — that would probably make for an interesting exercise. It would certainly take a lot of determination to write as much code, just on paper, but you are absolutely right in terms of it reinforcing some good habits.
Reply to comment
[...] a pen and paper. Visualize the problem before you start coding. Try the sample input on paper and see if you understand exactly why the [...]