At first glance, the question seems reasonable, but it makes some terrible assumptions:

  • lines of code=force
  • lines of code=value
  • all lines of code are equal

None of this is true.

Why did a fix that seemed so simple take two days?

  • Because the problem was a vague description of how to reproduce it. It took me several hours to reliably reproduce it. Some developers would immediately contact the person reporting the problem and would require more information before conducting an investigation. I try to get as much as possible from the information that is available. I know that some developers do not like to fix errors, and therefore they do everything possible to get rid of them. Saying that there is not enough information is a great way to look like you are trying to help but not do anything. I know that reporting errors can be difficult, and I am grateful to everyone who does this. I want to acknowledge the error messages, trying to get the most out of the information provided before asking for more details.
  • Because the problem was related to functionality that I am not familiar with. I rarely use this particular function and never understood the details. This means that it took me more time to understand how to use it and to understand the nuances of how it interacts with the software.
  • Because I took the time to investigate the real cause of the problem, and not just look at the symptoms. If some code throws an error, you can just catch the statement and suppress the error. No error, no problem, right? Sorry, making the problem invisible to me is not the same as fixing it. Swallowing errors can easily lead to unexpected side effects. I do not want to deal with them in the future.
  • Because I investigated whether there are other ways to reproduce the problem, and not just the steps described. Certain steps to reproduce the problem can show the problem in one place, when in fact it can be more deeply rooted. Finding the exact cause of the problem and considering all the ways to get it provides valuable information. It is very useful to consider how the code is actually used and where there may be other places with possible (other?) Problems, or it may show inconsistencies in the code, which mean that the error is caused (or processed) in one code path, but not in friend.
  • Because I took the time to check if there were other parts of the code that might be affected by this problem. If one error occurred, the same could be made in other places in the code base. Now is the time to check it out.
  • Because when I found the cause of the problem, I was looking for the easiest way to fix it with minimal risk of side effects. I do not strive for speed. I want to correct the situation so as to eliminate confusion or other problems in the future.
  • Because I thoroughly tested this change and made sure that it solves the problem for all the different code paths that were affected. I don’t want to rely on anyone else to verify that I did the right thing. And I do not want the error to be found in the future, and I will have to return to this code when I mentally move on. Context switching is expensive and unpleasant. Having a special tester to look at the “same” change again is something I want to avoid when possible.

I do not like to correct mistakes. Partly because they can be felt as a result of a previous failure on my part. Another reason I don't like fixing bugs is because I prefer working on new things.

What could be worse than fixing a mistake? Need to fix the same error more than once.

Each time I spend time making sure that any error is completely fixed, so that it does not need to be encountered, investigated, corrected and tested more than once.

Source