5 ms·

I don't know, if I can debug code on my workstation, that does not seem extremely difficult. Time consuming, if anything, but I feel like anyone with sufficient

I don't know, if I can debug code on my workstation, that does not seem extremely difficult. Time consuming, if anything, but I feel like anyone with sufficient grit could do that, regardless of education. Tracking down a bug and fixing it with a one-liner does not feel like productive programming (though it brings value to the business). If I can't debug code on my workstation, e.g. it's running on Kubernetes with service mesh and a cool feature must be added, that's when all hell breaks loose. For example, debugging why Kubernetes deployed on OpenStack will push an image to its internal repository but won't pull from it, that is hell and I'd much rather debug HTTPD than that.

ehnto 7y ago
> if I can debug code on my workstation, that does not seem extremely difficult. Time consuming, if anything, I find debugging saves time overall. I don't have to guess about anything, I can see it working or not working, quickly run one liners to confirm. Sometimes getting an application into a certain state takes a bit of wrangling too, and a debugger helps save time by not having to constantly set up that state to see how things have occurred. You can just sit on a breakpoint while you deduce what's going on. A bug that happens at checkout success is a good example. Going through checkout over and over again is time consuming.
- BossingAround 7y ago
  > debugger helps save time by not having to constantly set up that state to see how things have occurred Absolutely. I found out very quickly in my career that I can either stare into the code for hours to see the tiny mistake, or spend 10 minutes stepping through the code to let it tell me what's wrong. But, it is of course more difficult if you have to debug a complex code base that you don't know. It might take you hours to even know where to place debuggers. So, it can be time consuming, but of course it's still orders of magnitude faster than staring into the code, trying to see where the issue is.
leetrout 7y ago
Is that a common issue you’ve hit with K8S? I had this exact issue in an OpenShift system.
onion2k 7y ago
I don't know, if I can debug code on my workstation, that does not seem extremely difficult. If you wrote the code, sure. Then you have the context of each step you took to iterate the code to what's there now, with some insight in to where the issue might lie. Take someone else's code that's the final, non-working version and it's a different story. Debugging is hard.
bluGill 7y ago
For simple bugs yes. However if the bug is a one in a million race condition between threads where the lock is held/released at the right time except for one place where it isn't even obvious the other thread can write the data. This is particularly bad if there are performance considerations and the design ensures some places where it looks like a race are actually not and so a lock would be a bad thing. Without fully understanding the complex design you cannot add the needed lock in without adding in uneeded locks that kill performance.
- lowbloodsugar 7y ago
  see https://en.wikipedia.org/wiki/Heisenbug https://en.wikipedia.org/wiki/Heisenbug
- nullc 7y ago
  > However if the bug is a one in a million This is what RR is for: you only need to be able to reproduce the bug once inside RR. > ensures some places where it looks like a race are actually not Uh be careful, if you're writing in a high level language... such as C: there are no safe data races. https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong https://software.intel.com/en-us/blogs/2013/01/06/benign-dat... The compiler is free to reorder operations in ways that make what appears to be a safe data race unsafe.
  - bluGill 7y ago
    There are limits you can place on the compiler. There are atomics in the compiler. There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. There are times where you know the other thread isn't started yet. There are platform specific ways to flush all the caches long after the race in question which can be tied to something else that is synchronized across threads...
    - saagarjha 7y ago

ehnto 7y ago

> if I can debug code on my workstation, that does not seem extremely difficult. Time consuming, if anything, I find debugging saves time overall. I don't have to guess about anything, I can see it working or not working, quickly run one liners to confirm. Sometimes getting an application into a certain state takes a bit of wrangling too, and a debugger helps save time by not having to constantly set up that state to see how things have occurred. You can just sit on a breakpoint while you deduce what's going on. A bug that happens at checkout success is a good example. Going through checkout over and over again is time consuming.

BossingAround 7y ago
> debugger helps save time by not having to constantly set up that state to see how things have occurred Absolutely. I found out very quickly in my career that I can either stare into the code for hours to see the tiny mistake, or spend 10 minutes stepping through the code to let it tell me what's wrong. But, it is of course more difficult if you have to debug a complex code base that you don't know. It might take you hours to even know where to place debuggers. So, it can be time consuming, but of course it's still orders of magnitude faster than staring into the code, trying to see where the issue is.

leetrout 7y ago

Is that a common issue you’ve hit with K8S? I had this exact issue in an OpenShift system.

onion2k 7y ago

I don't know, if I can debug code on my workstation, that does not seem extremely difficult. If you wrote the code, sure. Then you have the context of each step you took to iterate the code to what's there now, with some insight in to where the issue might lie. Take someone else's code that's the final, non-working version and it's a different story. Debugging is hard.

bluGill 7y ago

For simple bugs yes. However if the bug is a one in a million race condition between threads where the lock is held/released at the right time except for one place where it isn't even obvious the other thread can write the data. This is particularly bad if there are performance considerations and the design ensures some places where it looks like a race are actually not and so a lock would be a bad thing. Without fully understanding the complex design you cannot add the needed lock in without adding in uneeded locks that kill performance.

lowbloodsugar 7y ago
see https://en.wikipedia.org/wiki/Heisenbug https://en.wikipedia.org/wiki/Heisenbug
nullc 7y ago
> However if the bug is a one in a million This is what RR is for: you only need to be able to reproduce the bug once inside RR. > ensures some places where it looks like a race are actually not Uh be careful, if you're writing in a high level language... such as C: there are no safe data races. https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong https://software.intel.com/en-us/blogs/2013/01/06/benign-dat... The compiler is free to reorder operations in ways that make what appears to be a safe data race unsafe.
- bluGill 7y ago
  There are limits you can place on the compiler. There are atomics in the compiler. There are times when you know you are safe because there is a future write that is memory barrier protected so even though there is a potential race, before the other threads can read it this thread will write something else. There are times where you know the other thread isn't started yet. There are platform specific ways to flush all the caches long after the race in question which can be tied to something else that is synchronized across threads...
  - saagarjha 7y ago