Fog Creek Software
Discussion Board




Stupid CS Exam Questions

On many university CS exams, there are the 'trace a bit of code' questions.  Is there any value to this?  I sat there yesterday tracing some stupid code through three or four levels of recursion and through five or six threads, only to realize that I'd made some goofy mistake at the top level!

But in almost fifteen years of software development, I've never had to trace something without a debugger & call stack!  I've never had to trace a bit of code without any implementation cues - the variables & classes in the code snippet on the test were all 'foo', and 'bar', and 'x',... 

Do you agree with me that uni tests are worthless - both for future professionals & future academics?  If so, what the hell motivate them to design tests this way.

anon
Monday, June 14, 2004

Actually that's one of the more relevant exam questions I've heard of.

Regarding having a debugger - I've had to figure out how code works without a debugger - I only had one tier's code and no access to the production system, so I simply couldn't run it on its own.

I was stuck tracing code looking for the bug. :-/

(found it, BTW - boundary condition and an assumption about the data entry)

Philo

Philo
Monday, June 14, 2004

The problem makes sense for three reasons:

1) Code reviews are important, get good at it.

2) Appreciate how hard it is to read obfuscated code and you'll try to not write it. 

3) Profs enjoy seeing the students squirm.

Tom H
Monday, June 14, 2004

I've been programming in Perl, PHP, or Java for almost 5 years and I've never, ever used a debugger or watch window.  I do just fine tracing code.

It's a good skill to have.  Actually.. I'd say it's an *essential* skill to have if you're going to go about calling yourself a programmer.

muppet is now from madebymonkeys.net
Monday, June 14, 2004

Yeah, I don't really see a problem with that. Come on, we've all been given crappy code with no documentation to "fix".

In addition to the remarks made preiously, it may also be testing your ability to hold several complex things in your head at one time.

Some people can, and some can't, but I reckon it is a useful trait for a developer.

Steve Jones (UK)
Monday, June 14, 2004

School is too easy.  Do something usefule with your time.

Brett Favre
Monday, June 14, 2004

If you could trace your code do you think you
would need a debugger? If you were consistently
tracing your code do you think you would generate
as many problems that required a debugger?

son of parnas
Monday, June 14, 2004

"I've been programming in Perl, PHP, or Java for almost 5 years and I've never, ever used a debugger or watch window.  I do just fine tracing code."


hmm wanna race?

me vb6?

u whatever u like.....

jon
Monday, June 14, 2004

Actually, that skill does come in very useful.

I am unfortunate enough to work in the ASIC industry. I program in VHDL.

There are no debuggers and stack tracers and fancy tools. They simply don't exist. Our tools, in term of sophistication, are more than a decade behind mainstream languages.

Imagine working on multi-million gate designs done by a team of 100 with only code-tracing abilities in everybody's arsenal... it's a nightmare sometimes.

Mat_ian
Monday, June 14, 2004

If you can't trace code, how do you expect to write code?

Me, I've got a mind like a steel sieve.  If I have to put a piece of code down for a couple of weeks to work on something more urgent, when I come back to it I'm going to have to spend some time reading over my old code to see what it does.

As for reading obfuscated code, you'd really better learn to do that trick.  When a new hire suddenly disappears just as his code rolls to production, you can expect that you'll be debugging a lot of obfuscated code.  Get used to doing it under stress too.  People with dicey code tend to bail at the most inconvenient moment.

Clay Dowling
Monday, June 14, 2004

Tracing code is a very useful skill. I'm doing research related to statistical modelling, and I run simulations that can take several days to run.

One approach to finding bugs is to run the code, and let it crash out. Then you make an educated guess at the cause of the bug, 'fix' it, and iterate this process until the bug is fixed. On demanding programs like mine, this would take weeks, so I need to be able to mentally trace the code through.

Your profs are not as stupid as you'd like to think they are.

C Rose
Monday, June 14, 2004

>> "I need to be able to mentally trace the code through."

If indeed this is the case, I imagine you are an outlier.  On 99.999% of the code in the universe, even if you don't have an actual debugger, you have access to the 'printf debugger' or some kind of log.  And even if you don't have a log, you're going to have some idea what the code is trying to do.  It's not some stupid 'foo' object randomly recursing and spawning 'bar' threads for no apparent reason. 

And I didn't say I *couldn't* trace code, I just said I don't think it's a useful test question because it's so easy to make a clerical error.  If you make a clerical error in the office, you work through lunch or stay fifteen minutes late.  If you make a clerical error on a test, you're screwed. 

Just like in engineering classes, there are profs who simply ask you derive the solutions and jot the formula, and there are other profs who insist on giving you the data in different units without giving the conversion factors, and take off full credit for a misplaced minus sign even when your setup & logic were correct.

anon
Monday, June 14, 2004

so in other words they teach you to be thorough and careful.

for shame.

muppet is now from madebymonkeys.net
Monday, June 14, 2004

Clay wrote:
>>If you can't trace code, how do you expect to write code?

That is the essence of the whole issue.  I would insert the word "good" (or some other similar modifier) between write and code.

Besides, all code serves as an example - some brilliant ideas that you can learn, some horrible ideas that should be avoided and possibly corrected.  The rest are mostly mundane snippets of code that just get the job done.

Jim L
Monday, June 14, 2004

See, I'm finding it really hard to believe that the majority of you guys have actually had to debug horribly obfuscated code without the use of even a print statement.  Call me a skeptic.

anon
Monday, June 14, 2004

One thing I wish I was exposed to in CS was dealing with (finding bugs, extending, etc.) legacy code. I suppose I had self-inflicted blindness in assuming that I was only going to work on brand-new code but in my years in the industry I’d say that I’ve written far less code “from scratch” than maintaining legacy spaghetti code.

All of the classes in University were “Write X from scratch” and I think it would be helpful to have classes which have you document, decipher, and/or debug “less than optimal” non-trivial code. That way not only are you competent with a debugger and know how to read “bad” code but you gain an appreciation about why code-standards are good things (and why some profs are style-Nazis).

Captain McFly
Monday, June 14, 2004

>> "Besides, all code serves as an example - some brilliant ideas that you can learn, some horrible ideas that should be avoided and possibly corrected."

I agree with you one-thousand percent.  It should be considered of the utmost importance that CS majors understand the difference between good code and bad code.  Is tracing through nonsensical code snippets an effective teaching tool?  Or would our time as students be better spent critiquing and analyzing software projects?

anon
Monday, June 14, 2004

+++have actually had to debug horribly obfuscated code without the use of even a print statement.  Call me a skeptic.+++

Who said that?  Print statement != debugger.

If you can't trace code, how do you know where to effectively place your print statements?  Do you just shotgun them all over the place?

I think the OP is a troll, to begin with.  Who in the world could argue that programmers don't need to be able to trace code, and be serious?

muppet is now from madebymonkeys.net
Monday, June 14, 2004

>> "Who in the world could argue that programmers don't need to be able to trace code?"

Who in the world suggested that programmers don't need to be able to trace code?  I'm arguing that tracing code is a stupid test question.  It serves no purpose on a test.

>> "Print statement != debugger."
If, by 'debugger' you mean a mechanism by which you can break execution and determine the state of your variables, then a print statement *is* a debugger.  The term 'printf debugger' has been around a long time to describe the tedious process we all know and hate.

anon
Monday, June 14, 2004

"I just said I don't think it's a useful test question because it's so easy to make a clerical error."

Hmmm.... I guess you're violently opposed to most math, physics, and engineering test questions, then.

"If you make a clerical error in the office, you work through lunch or stay fifteen minutes late."

First of all, if you make a clerical error on a test but work through everything else okay, I'd hope the prof will give you partial credit, just like if you forget to carry the "1" in your first equation of a complex derivation.

Secondly, if you make a clerical error in the office AND CATCH IT you might just have to stay late. Or you might just accidentally wipe out forty hours of test data. If you don't catch it, you might just cost the company hundreds of thousands of dollars in late shipping, warranty repairs, bug regression testing, etc.

Part of the very nature of the problem is teaching students critical and *careful* analysis of existing code. Sounds like you object to the "careful" requirement...

Philo

Philo
Monday, June 14, 2004

I'm currently writing a bunch of code in PLX (to fit the environment that I'm in.)  There are a ton of macros in my "Library" that are used for just about everything and they tend to interface with my code using variable names instead of parameters and include requirements that are not very well documented.  More than once I have had to walk their source code just to get MY code to compile...  Kind of puts you a little before a debugger huh?

Steamrolla
Monday, June 14, 2004

> If you make a clerical error on a test, you're screwed. 

Take heart. You still apparently have much education
to come.

Your  "clerical" error may cost your company a million dollar
contract and keep your options low grade toiled paper.
The real world is pretty harsh.

son of parnas
Monday, June 14, 2004

>> "First of all, if you make a clerical error on a test but work through everything else okay, I'd hope the prof will give you partial credit, just like if you forget to carry the "1" in your first equation of a complex derivation."

I'd hope the prof would give partial credit, too!  But many have not, and that's precisely the class of idiots I'm railing about!  There are many profs I've experienced who dock most credit when the calculations are wrong even when the logic is correct.

>> "If you don't catch it, you might just cost the company hundreds of thousands of dollars in late shipping, warranty repairs, bug regression testing, etc."

Unit testing!!!  Our minds are not designed to think like computers.  If they were, we would be able to trace code instantaneously.  Far better, I think, than having people trace nonsensical code, would be to teach these people to efficiently and effectively protect against mistakes with unit testing.  The proper use of unit testing will catch orders of magnitudes more errors than a legion of the best human code tracers.  I haven't even heard the term 'unit testing' once during the CS program.

>> "Or you might just accidentally wipe out forty hours of test data."

If you don't have your test data backed up, then I'm afraid you get what you deserve.

anon
Monday, June 14, 2004

if you can't trace code, you can't write good code.  How can you write a language that you can't read?  If you rely solely on your tools, then you're only as good as your tools.

This is a silly argument.

muppet is now from madebymonkeys.net
Monday, June 14, 2004

Unit testing isn't necessarily going to catch the .01% error that ends up increasing exponentially when your component is plugged into the rest of the system.  In this case, the small calculation error that you could easily have spotted by tracing through your code could easily pass a debugger/watch window inspection and on into production.

muppet is now from madebymonkeys.net
Monday, June 14, 2004

>Our minds are not designed to think like computers.

Our minds are currently more general than computers
so you should be able to do it.

> If they were, we would be able to trace code >instantaneously.

I don't know about instaneously, but you certainly
are able.

>Far better, I think, than having people trace
> nonsensical code, would be to teach these
>people to efficiently and effectively protect
> against mistakes with unit testing. 

You've already said you can't think like a computer
so how it you can ever write code without making
mistakes?

son of parnas
Monday, June 14, 2004

Mat ian,

What simulator are you using?  ModelSim (the de facto VHDL system) has a very nice debugger...

DavidJones
Monday, June 14, 2004

Hey DavidJones

I do indeed use ModelSim. Actually you are right, there is a step-through debugger, but ModelSim remains incredibly buggy, esp. with its support of variables. Ugh.

Then again my company hasn't upgraded its ModelSim license for several years. Maybe they've fixed all the bugs and improved the software.

Still, I'd say the debugging technology is light-years behind mainstream systems...

Mat_ian
Tuesday, June 15, 2004

*  Recent Topics

*  Fog Creek Home