How Can I Improve at Hand Written Programming Exams?

[DR13]

So I am taking an intro to programming class and am doing pretty well. I am getting high 90s on all assignments and end up helping others during lab time (used to practice programming). However, on our last exam I got a B on the test (about average). Not too bad, but I know I can do better. Now I realized that my problem was that we have to hand write the programs on the test and I have a tough time checking my written code. When doing it on the computer I just compile and check the errors and usually do a good job of solving them. But when I try to self compile and run through examples in my head I find that I have a tough time catching errors because I think that the program is doing what I want it to do. It is kind of like how when you read a paper you wrote it is tough to catch spelling errors or awkward wording because you read what you are expecting, not what is actually there.

Hopefully I did a good job explaining my problem. Have any of you guys ever had this problem? How did you solve it?

Thanks
DR13

 

[NobodySpecial]

Although I think it's unreasonable to mark down spelling errors (essentially typos) being able to design code on a white board/paper is an essential skill.
If you are using the computer to find logic errors - ie the program not doing what you expect rather than just syntax errors - then you aren't going to progress as a programmer.

 

[MathematicalPhysicist]

Yes I had a course of programming for physicists.
The mark was split between the final exam and a computer programme (some physical simulation) project.
For the project I got 97 points and for the exam 62 points, not that I plan to be a programmer anyway.

I understand your difficulty, I am not sure how can you fix this though.

 

[turbo]

@ OP: Do you group subfunctions clearly as you write, indent, and otherwise make it easy for yourself to identify nested routines, recursions, etc? My programming years are way behind me, but I found that if I was very rigorous about formatting (and commenting) while coding, I could parse the code in my head without compiling, running, and looking for errors after the fact.

Pardon me if my terminology is not up-to-date. I was self-taught in creating business-oriented executables. My college programming was ancient (CUPL, then FORTRAN) - very simple brute-force stuff.

 

[jambaugh]

I had a parallel but very different experience when once I applied for a part time job doing data entry for the IRS (while an undergraduate). I can fly on a keyboard with a backspace key, usually I know I mistype as I type and immediately backspace to retype as I go. But the test used electric typewriters and we could not "backspace". This slowed my typing down substantially and I didn't make the cut. The problem was my using the backspace key as a crutch and developing bad habits.

The only answer is to practice the way you will be tested. Next programming assignment you get you need to write it out first (use a word processor without even syntax highlighting) and try to get it error free before copying it into the programming editor.

A good practice is to pretend you are explaining the program to another programmer as you compose it. That inner dialogue may help you catch errors as you make them and auto correct.

 

[turbo]

A good practice is to pretend you are explaining the program to another programmer as you compose it. That inner dialogue may help you catch errors as you make them and auto correct.

A good suggestion. Commenting stuff that is "obvious" to you when you write it is a good way to avoid brain-farts a bit later. If you are a very linear thinker and are under time pressure, it can be a bit disconcerting to retrace your thought processes to try to de-bug code manually.

 

[DR13]

Ok. Thanks everyone for the advice. When I review for my next exam I will write my answers out on paper and check them before trying them on the computer. Also, I like the idea of commenting even the written code. I think it will make it much easier for me to follow my logic when I go back over it.

Thanks!

 

[turbo]

Ok. Thanks everyone for the advice. When I review for my next exam I will write my answers out on paper and check them before trying them on the computer. Also, I like the idea of commenting even the written code. I think it will make it much easier for me to follow my logic when I go back over it.

Thanks!

You're welcome. I was self-employed as a programmer, and commenting even some mundane stuff saved me a lot of time and money, since what seemed "crystal-clear" while coding didn't always seem so obvious when trying to parse the code before compiling. Good luck on your exams.

 

[jeffasinger]

As far as the commenting goes: If you have commented code, and you've made a small mistake somewhere, but the intent is clear, I find that the professor is usually a little more lenient, because it is easier for them to understand the overall logic of your code.

 

[Chunkysalsa]

I had a C programming class where we constantly had questions that were like "Given XXXX code, what is the output" You then had to write out what your computer would print out to the screen. It was superbly annoying because you would get points off for every single little mistake and the code was written with as many random spaces and formatting strings stuck in the middle of prints.

I ended up with a B in the class because I kept messing up the tests (low Bs, high Cs) while getting perfect grades on the projects. Albeit I didnt exactly prepare for the tests ahead of time. I honestly found it hard to to study and take those tests, while programming was simple for me. It not like I was unfamiliar with the pen and paper. I would map out all my code on paper before writing it.

 

[symbolipoint]

The way I remember learning to write BASIC programs, if one did not show the flow diagram for a question, exercise, or problem, then one did not receive credit.

I had a C programming class where we constantly had questions that were like "Given XXXX code, what is the output" You then had to write out what your computer would print out to the screen. It was superbly annoying because you would get points off for every single little mistake and the code was written with as many random spaces and formatting strings stuck in the middle of prints.

I ended up with a B in the class because I kept messing up the tests (low Bs, high Cs) while getting perfect grades on the projects. Albeit I didnt exactly prepare for the tests ahead of time. I honestly found it hard to to study and take those tests, while programming was simple for me. It not like I was unfamiliar with the pen and paper. I would map out all my code on paper before writing it.

 

[MysticDude]

I understand your problem. When I had AP Comp Sci (hehe, last year), my teacher gave us some of those problems where he gave the question and you had to write the code. Most were pretty simple, but some confused me and I got them wrong. Why? Because I couldn't compile in my head. So whenever I was doing some free time practice programming, I compiled ONLY when I was completely finished with my own problems. That way, I went completely on my own while having the ability to just stop and use the compiler. This way I learned and got a little disciplined :D. Trust me, if you take the AP Comp Sci class (I had an easy teacher), you'll need to know how to compile in your head. I only got a 4 instead of a 5 because I did not do too well on the last two questions of the free response.

 

[Jokerhelper]

I think I'm pretty much on your boat when it comes to programming. Last year I took a course in intro programming (python) and I ended up being top of the class. My main weakness was that I could never spot syntax errors, so I don't think I would have done nearly as well if I was asked to write out a program on a test. I did well when it came to working out algorithms, but the tough part for me was "translating" it into coding.

Also, next term I'm taking another intro course in computer and programming for engineers (C++). I know it's a far more complex language and that we will be asked to write short programs in tests, so I'll try to remember and follow the advice that was provided in this thread. Thanks.

 

[twofish-quant]

Hopefully I did a good job explaining my problem. Have any of you guys ever had this problem? How did you solve it?

1) Yes I have this problem

2) I deal with it, by learning programming in ways in which I don't have to take a programming class. :-) :-)

 

[MathematicalPhysicist]

1) Yes I have this problem

2) I deal with it, by learning programming in ways in which I don't have to take a programming class. :-) :-)

Same here...
:-)

 

[Stan Marsh]

So I am taking an intro to programming class and am doing pretty well. I am getting high 90s on all assignments and end up helping others during lab time (used to practice programming). However, on our last exam I got a B on the test (about average). Not too bad, but I know I can do better. Now I realized that my problem was that we have to hand write the programs on the test and I have a tough time checking my written code. When doing it on the computer I just compile and check the errors and usually do a good job of solving them. But when I try to self compile and run through examples in my head I find that I have a tough time catching errors because I think that the program is doing what I want it to do. It is kind of like how when you read a paper you wrote it is tough to catch spelling errors or awkward wording because you read what you are expecting, not what is actually there.

Hopefully I did a good job explaining my problem. Have any of you guys ever had this problem? How did you solve it?

Thanks
DR13

Being able to write down codes without mistakes, or being able to check the bugs in the program is a useful skill, especially when you are writing long programs (like more then 1,000 lines). This skill demonstrates you ability to think carefully.
Do not rely on the computer to check the bugs.

 

[twofish-quant]

Being able to write down codes without mistakes, or being able to check the bugs in the program is a useful skill

As a professional programmer, I've found it a be a pretty useless skill. It's like being about to memorize 1000 digits of pi. Useful at parties, but no one in a software company will care if you can do it.

Especially when you are writing long programs (like more then 1,000 lines). This skill demonstrates you ability to think carefully.

Real work system tend to be 10 million lines of code. If you have 10 million lines of code that is being worked on by several hundred programmers at the same time, you will need automated testing systems like

http://buildbot.net/trac

to catch syntax errors. Also spending a lot of times with silly thinks like catching syntax errors means that you don't have time to think about basic design issues.

Do not rely on the computer to check the bugs.

Don't have people do what computers are good at. The more effort you have getting the computer to check for syntax errors, the more time that you have to catch "deep bugs."

 

[DR13]

Two-Fish that is exactly my point. On my last exam I didnt have any deep bugs or gaping holes in my logic. It was things like a missing return statement or forgetting to static_cast a variable or deleteing an extra sign on a cout statement. Things that would have been caught with one simple compile and running of the code. It gets annoying

 

[twofish-quant]

Two-Fish that is exactly my point. On my last exam I didnt have any deep bugs or gaping holes in my logic. It was things like a missing return statement or forgetting to static_cast a variable or deleteing an extra sign on a cout statement. Things that would have been caught with one simple compile and running of the code. It gets annoying

My advice is not to get too annoyed, and just do what you have to do to do well on the tests. On the one hand, learning to program these silly things isn't going to be that useful in your career.

On the other hand, learning to deal with and accept silly and pointless bureaucratic restrictions without going crazy is going to help you a lot. :-) :-) :-) :-)