The First Rule of Programming: It's Always Your Fault

blog
104

Depends on the each situation. As a programmer, I think each time your come across a bug, investigation is should be done before giving any answer. Sometimes it is as easy putting a breakpoint in the suspected section of code and figuring out the problem.

Other times, much harder. Consider a case with many 3rd party components are running and a memory exception happens and all you have is a memory address at the point of crash. This case requires crash dumps and using some low level tools to figure out which exe or dll the memory address resides in. Other posters have pointed out similiar examples of these type of scenarios.

I don’t think it is always your fault as a programmer, especially in today’s age of large and numerous frameworks.

I think it is better to say: We as developers should always assume responsibility to find a solution to the problem/bug. And then if it is your fault saying, “I made a mistake, its my fault.” Don’t assume anything, test, debug, and explore to find the root of the problem.

Everyone makes mistakes, that’s why there should be lots of QA on your product/code.

105

One of my formet bosses summarized it well :

"If it ain’t on fire, it’s a software problem"
Bob Norvell

106

We had some code at work that broke over the course of a few releases of Qt 4. Some of it is still broken.

Google is your friend. After two hours of GUI voodoo incantations, we started to do more targeted, judicious Googling and found a fix in fifteen minutes.

The Qt documentation is not very nuanced and it’s changing fast. We’re staring at another framework release in June, I think. The path between release and proven rock-solid stability is always hacked with a machete.

107

Yep, it’s 99% your fault. But for a professional full-time programmer, fumbling with 2-3 bugs per week, that means you’ll find no less than 1 system (or library, or anything else) bug per year.

Experience here is very important, because it helps you to track down whose errors might be your fault and what cannot possibly be in less time. The ability to determine that and 1) fix your error or 2) produce a good work-around when you can’t fix someone/thing else’s error is very precious.

Last year we had network application using a foreign library connecting to a remote server. Multiple-instancing the library (loading two dlls using it) on a single application caused Win2003 server network layer to randomly halt. It was relatively fast for me to determine that the fault was either in the foreign software or in in a O/S bug on which the developers of that library fumbled upon: the only network related difference with already working production servers was in that library, and the bug happened relatively fast (in a few minutes since the app started). Also, it didn’t happen on other O/Ses.

The hard part was convincing my boss, a M$ evangelist. Eventually I managed to get him on the server console and had him try to ping our network back. The machine froze under his hands…

I will always remember him staring at the monitor end then at me, in an enlightened bewilderment.

108

What if you code in machine code :wink: pentium bug, does that count?

109

Blaming myself actually costed me a lot of time (I do it naturally, never had to learn or think about it). For example asking myself what in the world I could possibly be doing wrong (php echo’s which just weren’t working and such), and then learning about 15 minutes later that the FTP was failing to update the file because the classmate still doesn’t know how to set FTP permissions (he chmodded one includes folder to 777 for me, leaving still no access to any other folders -.-).

From the other side, I can imagine that it also could have costed me a lot of frustration and time if I blamed the software I was relying on right away. Now I’ve experienced a couple times that it was not my fault (while often it was my fault :p), I think I’ve found a pretty good balance. The underlying system is usually not thát hard to check, so after about 10 minutes of troubleshooting (10/15m is usually enough time to go through most of the possibilities) I start checking the system.

110

I got my old PS2 out this week-end and my 6-year old son was playing with it.

He came in my room and complained the game was not working. I said it was more likely he was not doing the right thing.

When I had a look, the game was asking him to ‘Press Select’ and true enough the Select button was broken on the PS2 controller!

So yes, Select is broken.

1 Like
111

Ultimately the developer decides what libraries and tools to use. The onus is ultimately on the dev to evaluate tooling and libraries before using them to build their product. If the library or tool is faulty don’t use it. Thus… it’s still ‘Always Your Fault’ :smile:

112

It’s always the code! -devopsguy

113

I know this is only tangentially related to the subject of the original post, but I felt like asking it here. Obviously when it’s just you and the computer, you should always assume it’s your fault, but when working on a team, there are slightly different rules. I’ve often erred far too often on taking responsibility for other peoples’ mistakes, because due to my hyper-conscientiousness, I’m afraid of looking like I’m shirking responsibility if I don’t.

What if it’s a bug that was introduced in a module written entirely by a colleague?

Dealing with a situation right now where a colleague of mine wrote a feature without any input from me (although I would have loved to be consulted).

A month ago, doing routine code quality duties, I added a dangling comma to the last method in an object, to enforce eslint rules. Thus the Git blame now shows my name on that line.

Today (a month after I added the comma), the feature suddenly has a bug in production. The particular method that is the source of the bug is the one I added a dangling comma to (a change which had no effect on the functionality).

My colleague comes to me with a screenshot of the broken line (the one he wrote months ago) and says, hey, this isn’t working, can you fix it? And gets the project manager involved. I don’t know if he came to me because the last git blame on that line was mine or not. I assume so, but don’t want to jump to conclusions.

What I do know is that, given that I haven’t spent any time with the feature that my colleague built, it will take me all day to learn this feature and fix this bug, when, given that he built it, I would imagine he could fix it far faster than I could learn the entire feature and debug it myself.

My end goal is to have the bug fixed as quickly as possible for the good of the team. So do I take 6 hours to fix it myself? Or do I request the colleague in question spend time on it and fix it in perhaps 20 minutes?

What is the suggested course of action in this situation? I don’t want to say “that’s not my problem”, but I think there might be a time and place to do so.

2 Likes
114

I agree with your assessment that your colleague can probably find and fix the bug faster since he wrote the code, but sometimes a fresh pair of eyes will see something that the original “eyes” will gloss over and miss. Has your colleague given it more than a cursory glance (and didn’t see what broke) or has he actually looked for the bug and cannot find it?

It seems odd he had a screenshot of the broken line and didn’t fix it himself. Go to your colleague and express your concern about the time it will take for your to learn the feature he wrote as to what you think he could fix in much less time. IF he says he looked at it and didn’t see the problem, then fine - work on it yourself. Maybe ask him for a little “together” time on it with him (hopefully) giving you a glimpse as to what his (broken) code was supposed to do and where the affected code is/should be located.

Five minutes of talking with him could direct you to what is affected by the broken code and you may be able to fix it yourself in the 20 minutes you figure he could do it in.

Communicate with him. Then you won’t be jumping to conclusions and you could save yourself a few hours of work.

1 Like