| Where I work (IBM Watson Orders) they sometimes call me "the debugger guy". I love a good debugger and what it can do for me. I don't use it only for debugging; it's also a great tool to help anyone understand a complex codebase like ours. Not sure how or why the code reaches a particular function? Set a breakpoint and then look at the call stack. It's all right there. And if you want to write some experimental code that will execute in the context of that breakpoint, just open the Python console. You can import any modules you need and test your new code immediately. I also appreciate good logging. Especially when there was a problem yesterday in one of our customer's drive-thrus. I can't attach a debugger, but I've helped make sure we have solid information in the store logs. Just the other day I was working on some testing code that would send an MQTT message to one of our services, and then it did a sleep(n) call to wait for that service to complete our task. The number of seconds to sleep was pure trial and error. Sleep too long and the tests take too much time to run. Don't sleep long enough and the tests become unreliable. So I figured I would add a bit of code to that service to send another MQTT event back to the test code after completing its task. Instead of sleeping, the test code would just wait for that signal. But where to put that MQTT call in the target service? It's a lot of rather complex code. So I slathered that service with hundreds of log.info("abcxyz") calls, every place I could find to put one. It quickly became apparent from the log where the service completed the task and it stopped logging other messages. That's where I added the "I'm done" signal. One thing that helped here is that our logging library adds the line number where each log.info() was called. So I didn't have to customize that log message, I could just copy and paste the same log.info() call hundreds of places. I think every developer should learn how to effectively use both a debugger and logging. Otherwise you're working with one hand tied behind your back. We had a conversation about this last week, including a link to an article with a title I found astonishing - "Debuggers are for Losers": https://news.ycombinator.com/item?id=35013732 |
It allows you to learn them very fast.
VS has great debugger for C# which allows you to do a lot of stuff when running the program, so sometimes I even develop the soft while having debugger and breakpoints attached