3 ms·
In my experience, a debugger is most helpful when you are unsure of the behavior of the language or libraries or machine on which you are working. It shows you
by bhk 5y ago
In my experience, a debugger is most helpful when you are unsure of the behavior of the language or libraries or machine on which you are working. It shows you what happens at various levels and validate or invalidate your assumptions or what you were led to believe.
Sitting and thinking on the other hand, is best for dealing with errors in your own thinking. Ideally, we should have a well-thought-out argument for why something will work, so when it doesn't, our argument needs to be refined.
- zwieback 5y agoExactly, perfect summary. Expanding on the first point, a debugger is invaluable for me if I can run my program up to a point and then use the "immediate" window to run a few API calls to see what would happen in that context.
- svachalek 5y agoI agree. Unfortunately over my career (going on 30 years) the ratio of my thinking to other people's thinking in the systems I have to develop is shrinking and shrinking. Modern software runs on systems layered onto systems layered on systems of systems. "Debuggers" are more sorely needed than ever but the traditional concept of a debugger is decades out of date and sorely needs to be reinvented for heterogenous, distributed, and parallel interactions.
- wilburTheDog 5y agoI think this is very true. The most vexing problems I've run into lately have all been because something is going wrong in a step I don't have much control over. Like in one case the proxy was stripping out the Authorization header for PUT requests (seriously). Or in another the corporate-signed certs used by all the on-prem systems weren't validating on AWS because they don't have a valid root cert. I really wish I had a "debugger" that could trace the interconnections between all the systems my app depends on.
- spockz 5y agoIn both cases you would have been helped by proper error reporting and by tracing. (See OpenTelemetry) For the first the remote server could say there is no Authorization header where tracing confirms it was there when sent by the client but not by the proxy. For the second it would be really nice to see more detailed logging on the server side about why a particular peer certificate was rejected. My biggest gripe with current OpenSSL and Java TLS implementations is this lack of detailed reporting.
- wilburTheDog 5y agoIn the first case the request worked when executed in Postman but failed when executed from a browser, which said it was a CORS error. Using the logs we traced it up to the authorization step in APIG, which wasn't being executed (because auth header was required to execute it) and so wasn't generating logs. And that's where I was stumped, because it was not a part of my mental model that request headers could disappear between client and APIG. We eventually realized the browser uses the proxy and postman doesn't, so we asked the networking group and they admitted they were removing the auth header in the proxy. Regardless of the details this is one of those situations I wasn't able to solve by just thinking about it. If I had a 'debugger' that could step through these API requests it would have been much easier to figure this one out. I don't know enough about OpenTelemetry to say if it would have helped or not.
- spaetzleesser 5y agoExactly. If you live in a pure C world without external dependencies it makes sense to sit down and think it through. If you live in something like .NET or Java where you do a lot of interfacing with libraries and APIs a debugger is very useful to just discover how these systems are behaving.