Software Engineering discussion

My freshman programming class used PL/1 with punched cards, batch submissions, and line printer output (the last year before interactive terminals). In that environment, you are forced to take time to carefully think about what is going wrong with a program and how to fix it correctly, because each cycle takes so long. With instantaneous change code - recompile - try again cycles, I find that I don't think as carefully. I wonder which approach is less time consuming in the long run?

I also find myself preferring print statements to fancy interactive debuggers. I also wonder if this is just habit, or if others find that debuggers are overrated and underused. With iOS programming, I do use the debugger more than I have in the past, but that is mostly to get a handle on the control flow, which is new to me. I am often frustrated that I can't see object state as clearly in debuggers as in UML diagrams.

I agree that fixing compile issues labeled as warnings instead of errors often pays off in the long run.

I think that debugging is much more art than science, and that this is the main reason it isn't usually formally taught in programming classes.

I wish I knew more about different types of debuggers. This chapter mentions a few but doesn’t really go into many details. At work, besides a debugger already built in IDE, we use a real-time debugger; it allows to monitor and change state of the program variables in real-time – like oscilloscope with electronic circuits except changing states part. I’ve heard about profilers, but never got a chance to use one. I think it would be interesting to get into low level details of some debugging format like DRARF2 and try to figure out if it’s possible to get a real-time objects information without stopping execution and code instrumentation.
I think debugger can also help to overcome issues described in Psychological Considerations in Debugging section.

Nice chapter. It put a nice formal description to a heuristic activity that I often do.