I may have been short in the past so let me clarify.
1) What if your typo ends up causing you to swap the usage of two different variables? Something as simple as two counters, i and j, in a nested loop.
If you use i or j for a variable name then you have already failed any test I would give. At least use foo and bar they are easy to differentiate visually.
2) I would disagree with you that programming is a "cutting edge skill." The core concepts of programming that we use today have been around now for almost several decades -- far longer than the personal computer, the graphical IDE and even longer than the debugger.
Go out into the woods and build a stone knife then. Humans have been around far longer than you think. Our minds can no longer keep up with the volume of information -- no more than you can keep up with the number of conversations that you start online in one day.
3) For what it's worth, my job is software development, and has been for a long time now. Every program I write, I do in four plus stages. First, I design. Second, I actually put a pencil to paper (1/5" grid paper is my preferred format) and write most of the code. I leave out some of the sanity checking and other repetitive lines (but always making note of them in the margins). Only after that do I even start typing anything in to a text editor (my preferred IDE). The fourth step is to finally test the code out. Before I even do this, I am already fairly confident that everything works well, but I don't always trust myself completely. If necessary, I will do the debug-test loop until everything passes all my tests.
For what it is not worth, my job has been software development for a very short period of time. Th things I deal with on a day to day basis are the mistakes people so stuck up as to believe they are the only person in the world that will ever see the code make. You never come up to see what good, tested code is already around you.
4) Pencil and paper are about the simplest usable interface available to me.
Most of the problems I have been asked to do as a "programmer" involved nothing more than thinking about what I could do with what I knew a computer was capable of. Many times this boils down to a redirection of input.
Asking someone to code on paper is just as ignorant as spending hours looking for typos rather than letting a compiler catch them. The problem is that a cutting edge skill is being taught in an age old fashion.
Slashdot Mirror
I've actually worked with that simulator before -- bad collision detection is probably the least of it's worries.
Notice the minimized browser in the bottom screenshot?
I may have been short in the past so let me clarify. 1) What if your typo ends up causing you to swap the usage of two different variables? Something as simple as two counters, i and j, in a nested loop. If you use i or j for a variable name then you have already failed any test I would give. At least use foo and bar they are easy to differentiate visually. 2) I would disagree with you that programming is a "cutting edge skill." The core concepts of programming that we use today have been around now for almost several decades -- far longer than the personal computer, the graphical IDE and even longer than the debugger. Go out into the woods and build a stone knife then. Humans have been around far longer than you think. Our minds can no longer keep up with the volume of information -- no more than you can keep up with the number of conversations that you start online in one day. 3) For what it's worth, my job is software development, and has been for a long time now. Every program I write, I do in four plus stages. First, I design. Second, I actually put a pencil to paper (1/5" grid paper is my preferred format) and write most of the code. I leave out some of the sanity checking and other repetitive lines (but always making note of them in the margins). Only after that do I even start typing anything in to a text editor (my preferred IDE). The fourth step is to finally test the code out. Before I even do this, I am already fairly confident that everything works well, but I don't always trust myself completely. If necessary, I will do the debug-test loop until everything passes all my tests. For what it is not worth, my job has been software development for a very short period of time. Th things I deal with on a day to day basis are the mistakes people so stuck up as to believe they are the only person in the world that will ever see the code make. You never come up to see what good, tested code is already around you. 4) Pencil and paper are about the simplest usable interface available to me. Most of the problems I have been asked to do as a "programmer" involved nothing more than thinking about what I could do with what I knew a computer was capable of. Many times this boils down to a redirection of input.
Asking someone to code on paper is just as ignorant as spending hours looking for typos rather than letting a compiler catch them. The problem is that a cutting edge skill is being taught in an age old fashion.