Hacker News new | ask | show | jobs
by hasbot 960 days ago
As a software engineer I always kinda enjoyed debugging. It allowed me to use a different skill and mind set than creating designs and implementing them.

Not to say I didn't get stressed out debugging. I had one demo while developing software for AT&T's 5ESS telephone switch. We had only one phone line in the test lab configured for our feature. Attempt after attempt the software just wouldn't work. Knowing the software worked, I checked everything I could all the while stressing out. Finally I asked the lab tech to check the line. Somehow our only configured line was disconnected. The problem was a stupid hardware issue.

2 comments

> As a software engineer I always kinda enjoyed debugging. It allowed me to use a different skill and mind set than creating designs and implementing them.

Same here. I always enjoyed the challenge of it, especially in complicated systems.

I always feel that debugging is much more of a science than normal software development.

You need to spot unusual behavior, figure out ways to isolate and reproduce it, come up with hypotheses as to what might be happening, design tests for those hypotheses, run the tests, find the solution, test the solution -- exactly like the interplay of experimental and theoretical science.

... Detective work.

(•_•)

( •_•)>⌐■-■

(⌐■_■)

I enjoy debugging when the tools are there, not so much when choices have been made to put everything too out of reach, either figuratively or literally. Debugging distributed systems in the cloud is exponentially more awful than debugging them when you can at least spin up all your services locally and that in turn is exponentially worse than when you can debug the problem in just one program.

An actual debugger also makes the act of debugging much nicer to me. I've never understood people who quibble about using either printf debugging or an actual debugger when using both is such a massive win. Arguably good tracing facilities should be highlighted here as well since they're much nicer than printf debugging when they're available.

> Not to say I didn't get stressed out debugging.

This is interesting because I remember very early in my programming journey I used to attach a lot of unnecessary things to not understanding why something was happening (or not happening) and gradually I just came to embrace the "Hang on, why is this so? I don't get it... Ohh, hang on... Wow, it really makes sense why this didn't work!" loop and internalize the fact that it feels really good when I get to the end of it.

The process of not knowing can only really get ruined by other people's expectations and behaviors for me at this point and I've learned over time that this can only be managed by being very assertive about how things are done (language choices, architectural choices, etc.) so as to make the process as easy and quick as possible. Ultimately it's a lot easier (at this point in my career) to convince someone that working with AWS lambda is a bad choice for performance, overall costs, debuggability and development speed (all to varying degrees) than it is to convince them later that there is a good reason that fixing that one problem is taking more time than it ought to.