4 ms·

I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I don't like the idea of needing the machine to explain to me how

I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I don't like the idea of needing the machine to explain to me how my own code actually works. The feeling of complete understanding is an important motivator to me.

iainmerrick 8y ago
I don't like the idea of needing the machine to explain to me how my own code actually works. I think it's useful to turn that on its head a little -- I know how the code should work, but a debugger can show me what it's actually doing, so I can see what's going wrong. I don't think there's a big difference here between debugging and testing, say. Couldn't you also say that tests explain how your own code works? I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I like to think of debugging more as a science. It's literally a mix of theory and experiment: the program does something weird, you run some random experiments to gather more data, you come up with a theory that explains the results, you design an experiment to test your theory; a successful theory will then lead you to the correct fix. A good debugger can help get the most data from your experiments. It's as if the LHC had sensors capable of tracking individual gluons, or the ability to replay a specific collision over and over, or even the ability to set up a desired collision from scratch.
pjc50 8y ago
I find it quite useful to have the machine explain to me how other people's code works, especially once working on a system of sufficient size and legacy that a truly complete understanding is impossible. Especially over here in C++ land where surprises lurk under every operator.
akerro 8y ago
If you had a bug, then you didn't know what machine is doing. You think you have an idea it's doing X, while it does Z. If you have ever written a bug because you should have written ++x instead x++, then you need the machine to tell you what it's doing, because it's not doing what you think. If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary.
- comboy 8y ago
  > If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary I know just the guy. He was interested in learning how to code.
pjmlp 8y ago
Good luck achieving that in feature implementations on distributed teams with 10+ devs. There isn't such thing as "my own code".
yoklov 8y ago
> I don't like the idea of needing the machine to explain to me how my own code actually works. But you're fallible. This is the same reason you need to use a profiler to see if your optimizations actually sped anything up. A debugger shows you what really happens, not what you think happens.

iainmerrick 8y ago

I don't like the idea of needing the machine to explain to me how my own code actually works. I think it's useful to turn that on its head a little -- I know how the code should work, but a debugger can show me what it's actually doing, so I can see what's going wrong. I don't think there's a big difference here between debugging and testing, say. Couldn't you also say that tests explain how your own code works? I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I like to think of debugging more as a science. It's literally a mix of theory and experiment: the program does something weird, you run some random experiments to gather more data, you come up with a theory that explains the results, you design an experiment to test your theory; a successful theory will then lead you to the correct fix. A good debugger can help get the most data from your experiments. It's as if the LHC had sensors capable of tracking individual gluons, or the ability to replay a specific collision over and over, or even the ability to set up a desired collision from scratch.

pjc50 8y ago

I find it quite useful to have the machine explain to me how other people's code works, especially once working on a system of sufficient size and legacy that a truly complete understanding is impossible. Especially over here in C++ land where surprises lurk under every operator.

akerro 8y ago

If you had a bug, then you didn't know what machine is doing. You think you have an idea it's doing X, while it does Z. If you have ever written a bug because you should have written ++x instead x++, then you need the machine to tell you what it's doing, because it's not doing what you think. If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary.

comboy 8y ago
> If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary I know just the guy. He was interested in learning how to code.

pjmlp 8y ago

Good luck achieving that in feature implementations on distributed teams with 10+ devs. There isn't such thing as "my own code".

yoklov 8y ago

> I don't like the idea of needing the machine to explain to me how my own code actually works. But you're fallible. This is the same reason you need to use a profiler to see if your optimizations actually sped anything up. A debugger shows you what really happens, not what you think happens.