I don't think we disagree very much: On interactive debugging, it's terrific stuff when it's needed. I've done a LOT of programming, and a few times I've used

I don't think we disagree very much: On interactive debugging, it's terrific stuff when it's needed. I've done a LOT of programming, and a few times I've used interactive debugging: When I needed it, it was terrific. Net, I just haven't needed it very much. On my current project, I haven't needed it at all yet. I believe that I've written the challenging code, and I had no problems with debugging. For some of the trickiest parts of the code, I just coded the operations twice, once a simple, slow way and once the faster, trickery way I wanted in the final version; then I had the code compare the results. I ran enough test cases to have good confidence that the two versions give the same, and correct, results. If the results were not the same, then to find the difference, instead of interactive debugging, I would have just 'desk checked' the code carefully. I find such desk checking terrific stuff -- each little possibility for a problem has to be checked, and sometimes more than one error is found. With interactive debugging, I can be tempted to quit checking when the first error is diagnosed for just that one test case -- not so good. Or, "Joe, there's a bug in here somewhere. Find it with desk checking."! Or, "Mary, Joe says that this code is correct. Here's $1000: If you find an error, then you get the $1000; else Joe does."! I wouldn't have coded just the tricky version and then tried to use interactive debugging to be sure the version was correct: My test cases were too extensive for checking 'interactively'. For "I can't imagine adding print/log lines for every imaginable variable in a scenario.". I don't do that either or need to. Occasionally a few print or log file writes, in a small part of the code, say, where I just added some code and something doesn't work, have been enough. Generally, though, any reasonably complex system should be able to report, at levels of detail requested in real time, what it is doing, and a lot of print or log statements are a start. In my most important code, I have such statements controlled by a variable that specifies 'message level', that is, the 'level' of detail of the messages. My intention is later to use Microsoft's code instrumentation infrastructure to send the contents of such statements to some 'system management' platform. So, generally I like 'messages' from code. And, actually, in my testing, I have lots of such print statements executing. The output of a small test case can be some thousands of lines, and I explore them with the capabilities of my text editor; I wouldn't want to do that work with interactive debugging. E.g., recently I had to reinstall the Microsoft software on my boot drive (grim story) so wanted to be sure my code would compile and run as before. So, for each directory of code, I made a copy of the directory and in the copy again ran the relevant scripts to compile the code and to run it on the test cases. Then I took the output, with its thousands of lines, and used a simple editor macro to do a line by line comparison of the new and old output files. Some lines were different because of time and date stamps or reports of allocated memory addresses. A few editor commands removed those lines, and then the old and new output compared perfectly. I can't see any easier or better way to do such a test; I want the print statements and don't want interactive debugging as a substitute there. To me so far interactive debugging is so unimportant I haven't even taken the time see what is available with VB. I believe that somewhere I saw that VB has interactive debugging also via command lines; if so, then that should be the most I would want. But I haven't even looked. Here are my 'source control' tools! First, if I am making any change at all in an old program or any significant change in a program still under development, then I start with a new file. So, if the last version of the program was PROG013.VB, then the next version is PROG014.VB; that is, I copy file PROG013.VB to file PROG014.VB, put some explanatory documentation at the top of the file, and start making changes. I don't don't even see the "014" -- I have an editor macro find that for me! My editor gives me a directory listing, and one keystroke sorts the files in descending order on time, and then PROG014.VB is right at the top of the list ready for work! You mentioned "undos" -- that's PROG013.VB! Of course another source of 'undos' are the daily incremental disk backups! And another souce is just my text editor. Second, for making changes in a program, typically I slap a time and date stamp on the change. So my editor does that, e.g., Modified at 01:32:46 on Wednesday, December 1st, 2010. For source code files, the editor puts this line in as a comment, choosing the comment syntax based on the file extension. So, I get time and date stamps, and that's close enough for me for a "logbook" of changes! For "comments for explanation", I'm big on those! For "I'm not a fan of English docs either": Well, fundamentally there's no alternative: Again, as I wrote: "There is, so far on this planet, exactly one way to record and communicate meaning -- a natural language, and of these, now, the most important is also my native language, English." Fundamentally, that statement is just true. Sure, with enough detective work, decoding, etc., people commonly guess at the meaning given much less than what I described. Other aids to understanding the meaning include mnemonic symbol names, pretty printing, and your "readable" code. Still, at least fundamentally, these aids cannot replace English as the source of meaning. You wrote if(noUser || userIsBusy) Okay. For using English documentation, I gave as examples college texts in math and mathematical physics. In such books, the symbols are carefully defined and maybe also motivated, discussed, and illustrated. Then commonly the exposition can continue with some 20 lines of algebraic derivations without additional English. Your statement 'if' can be seen as parallel. For your symbols noUser userIsBusy likely somewhere you specify the data 'type' of these as 'logical' or some such, and then your code can be plenty clear. Yes, keeping the English documentation up with the code is a pain: For an on-going development project, it can be tempting to rely on the fact that the team does know the code and delay a lot of documentation. But if the project goes on for many months, then staff can leave and leave the project short on what parts of the code 'mean', and new staff can arrive and be lost and nearly useless. Further, at some point development slows and the software becomes an 'asset' of the company. For continuing value, there needs to be enough documentation so that a new team could with reasonable efficiency take over and 'maintain' the code. So, that new team needs, typically, quite a lot of good English documentation, both as comments in the code and as an external paper. So, before the original development team goes on to other work, it can be important to take one more pass over the code documentation and get it up to date and clear. Sorry 'bout that. Generally on code and its internal documentation, Knuth's work on 'literate programming' is one polished way to proceed. In particular, for the code I wrote a year ago, without reasonably good documentation I wouldn't know what the heck the code does or what I was thinking about. Here's a related point on IDEs: Of course, can use SQL Server Management Studio to 'define' a database, that is, say what the tables are and for each table what the columns are. Yup, can do that! But I refuse to! Instead I define the database using the T-SQL statements in a text file, and here's why: The text file has about as many blank lines just for 'readability' as T-SQL lines. Then the comments are about five times as many lines as the sum of the blank lines and T-SQL lines. These comments explain what the heck I had in mind for that database 'schema' (in the traditional sense, not really in the sense of SQL Server 2005 and later). So, when a table has a clustered key and also a separate index, the comments explain why. Etc. So, that 'schema' with its documentation is a rock solid part of my project; as I write code to manipulate the database, all the code writing draws from the ONE, SAME documentation of the database as the code should. If I typed the schema into the SQL Server Management Studio IDE, then I'd miss out on the documentation and the primary source of crucial 'meaning'. GUIs have often been praised with "What you see is what you get", but there is a perceptive old response, "What you see is all you've got.". Or, using SQL Server Management Studio to type symbol names into text boxes just does NOT create the crucially important meaning. Sure, one way to be sure that English documentation is not "flat out wrong" is to omit all the English documentation! But I suspect that if you were to maintain code written by someone else, then you'd rather have more English documentation, possibly with some errors, than less. Yes, important, undocumented code can be a form of job security! But for my 'job security' I want the code well documented because in two years the code may need some changes and I may be the person who has to make them.