[treerex]

I started programming in 1982 and became adept at writing my code (especially machine language) out by hand before converting to hex by hand so I could key it into the monitor (this on a 6502, VIC-20). Having to do this makes you very careful: you made sure your logic was correct before you converted. You ran the code through your head multiple times to make sure it worked. Even today I rely on reading and rereading the code I write to find logic bugs before I compile and run the code. I find that kids coming out of school (yes, now that I'm old enough to be the father of current college graduate I'll call you kids) are more likely to code whatever comes to mind and then "run and pray" that it works. If you're lucky, they'll use a debugger if it doesn't work. If you're unlucky, they start putting in print statements.

I sometimes wonder if this type of programming is a side-effect of the short attention spans teens and twenty-somethings have now... but that's a subject for another time.

[userbinator]

code whatever comes to mind and then "run and pray" that it works.

I've noticed this too, especially having worked with the newer students. Whenever I point out what needs to be changed, before I finish the sentence they make one of the changes (sometimes incorrectly) and then hit "build and run" in their IDE before I can stop them - and then often face a very long list of compilation errors, because I hadn't finished telling them everything that needed to be changed. I've also observed on many occasions someone trying to fix a bug by making many, many tiny changes, seemingly randomly, and attempting to compile and run between each change to "see if it works now", their code turning into a horrible mess in the process. A suitable term for this could be "IDE thrashing", since it appears to come from the "instant gratification" that they provide. Quite unproductive, and usually a sign that whoever is doing it has only a very vague idea of how their code works.

When I started using IDEs, the temptation was certainly quite strong, so I can certainly understand how those who started with one could fall into this trap. I think it takes a lot of discipline and the realisation that these frequent iterations are breaking concentration and making it more difficult to focus on the problem to avoid it. Even today most of my work is done with a text editor, a whiteboard, a pencil, and lots of paper. Whenever I face a non-obvious bug, my first reaction is not to "try something that might work", but to think carefully about the code/algorithm again and see if I didn't miss something the first time I designed it, because it tends to be just an indication that there's something further wrong.

[danbmil99]

> If you're lucky, they'll use a debugger if it doesn't work. If you're unlucky, they start putting in print statements.

I think you got that backwards. printf debugging is a very useful but dying skill. If you have a usable debugger and you're working on one atomic single-threaded module, great -- but if you are doing low-level, asynchronous stuff, often on disparate platforms, the ability to write a log file and debug things that way is a precious resource.

[treerex]

I completely agree: I do a lot of printf debugging in exactly the cases you describe. As with everything though it's a tool, and not necessarily the first one to go to.

[NhanH]

Out of curiosity, wouldn't print statement go along with reading and rereading code methods? I switched from using debugger to mainly using print statement (and log, but they're functionally similar) because the feedback loop for using debugger is significantly longer. If you have the code in your mind and a "sense" of what could go wrong, seeing the state of program when it failed is generally sufficient for me.