

The First Rule of Programming: It's Always Your Fault - sharksandwich
http://www.codinghorror.com/blog/archives/001079.html

======
marrone
Another similar rule I like to follow is that if a user of your site cant
figure out how to do something, it is your fault not theirs

------
jcromartie
That's funny, because I have always had this notion internally (don't blame
the tools, look in your code first), but in a recent project it actually _was_
the tool that was broken more often than not. Consider the issue where:

    
    
      String s = (String)(vect.remove(vect.size() - 1));
    

... throws a NullPointerException, where the code:

    
    
      Object o = vect.remove(vect.size() - 1);
      String s = (String)o;
    

... works fine.

Can you spot the bug? No, because there is no good reason for it to fail.
There is no good explanation for a bug like that. And, when it's in expensive
proprietary enterprise software you can count on support _NOT_ giving half a
rat's ass about the problem.

~~~
pmjordan
Compiler problems suck, because you start wondering if the rest of your code
will start failing in weird and wonderful ways once it reaches the customer.
I've had a fair share of compiler/system library issues in game development;
the console SDKs I've used were unbelievably flaky, all the way from compiler,
build system, debugger to system libraries and hardware itself. Not fun. For
many people it becomes difficult to maintain the "it's always your code's
fault" mantra in that situation.

~~~
nradov
I'll always remember that long night back in 1992 trying to figure out why one
of my freshman CS assignments suddenly stopped working when I had finished the
features and was just cleaning up the code. It turned out there was a bug in
the Sequent Dynix Pascal compiler that caused my program to fail when I
deleted a comment. It took me quite a while to figure that out and put the
comment back in. :-)

In retrospect it was a valuable lesson. Always use source code control, and
check in small changes frequently. That way you can easily roll back in small
increments to figure out which change broke something.

------
raju
Agreed. A project I worked on in grad school involved developing a thick
client (Swing) for a large corporation. Well, we pushed the envelop with
Swing, and it was several times where a bug was actually in Swing, and we had
to find a workaround in our code while we waited for Sun to fix it.

But on the flip side, everytime we saw something weird happen, our knee jerk
reaction was, "Its a bug in Swing". And our project leader would look at us
and say, "Java works". His philosophy there was that if your basic assumption
is that the tools you are using are broken, you can never get anything done!
Start by assuming you made the mistake, and work away from that point.

~~~
nostrademons
I did a Swing project soon after Java 1.3 came out and kept finding odd bugs
where the behavior of the code directly contradicted the behavior in the
JavaDocs. My experience was basically that if you didn't do things exactly as
they did in The Java Tutorial, chances are it wouldn't work. Or it'd mostly
work, but with weird edge cases when you did something unexpected.

I asked my QA manager about this, and he said that the word on the street was
that Java 1.3 was not QA'd. They just made sure that the tutorial worked and
pushed it out the door.

I've had similar experiences with Java AJAX frameworks. The basic stuff from
Sun (JavaEE, JSF) seems fairly robust, as long as you use it in the intended
way. But many of the add-ons like Facelets, A4J, RichFaces, etc. are made by
small 2-3 person startups, and they don't QA or document their code at all.
Moreover, their code frequently makes functionality in the _base_ JSF layers
break (eg. you have to use ui:repeat instead of c:forEach with Facelets, and
then you have to use a4j:repeat instead of ui:repeat if you add A4J). Maybe
that's changed since they were bought by JBoss, but it's something to keep in
mind whenever you use bleeding-edge libraries by small teams.

So I'd amend that: start by assuming you're wrong, but if you can't find
anything in your code, look at your dependencies in order of least-used ->
most-used. Chances are, software like Python or Apache or Java has been fairly
well-exercised, and most of the bugs have been worked out. But there's no
reason to believe that JPartTimeOneDeveloperLibrary is any better than code
you write yourself, and if you use untested projects like that, you should
budget time to look through their source code and debug their problems and
send in patches.

Unfortunately, sometimes managers get it into their head that a 3rd-party
library is more reliable than it actually is, often because the vendor has the
chutzpah to charge a hundred grand for it, and they mandate you use it. This
should be considered a bug in your manager, but unfortunately there's no fix
for that...

------
joshstaiger
Whenever I run into a frustrating "bug in the compiler" type problem I find
it's useful to take a walk or revisit the problem again the following day.

Many times my mistake becomes obvious right away.

~~~
tom_rath
On rare occasions I still find myself falling into the "I'll get it soon" bug-
seeking trap. That evil state can keep you spinning your wheels for hours.

I've a rule to help recognize it: If I start spouting frustrated profanity, I
have to step away from the screen for at least an hour. It's amazing how
obviously simple the solution is on my return.

------
bdfh42
I am pretty sure that every trainee and junior programmer I have ever mentored
has come to me with a "bug in the compiler". I always try and find the
gentlest way possible to tell them that it's unlikely that there is a bug and
if there was then in all probability their more experienced colleagues would
know about it.

Usually however it is a good start point for revisiting the topic of program
structure and the tricky question of "state". A quick re-write of the
offending routine usually removes the "bug".

------
sanj
I live and die by this. I've spent a number of years muttering to myself "It's
not the compiler. It's not the compiler." (Though, strictly speaking, these
days "It's not the interpreter.")

And then I remember that day that a coworker tracked down a microcode cache-
sharing bug on dual processor servers that he notified Intel about.

------
jrmurad
Always? I just returned from fixing a problem. A system call for UDP
connection wasn't working. It worked yesterday. I could, however, ping and ssh
over the network interface.

I tried an earlier branch. Same problem. After that, I replaced the NIC,
rebooted, and everything worked.

Sometimes it really is the hardware/library/compiler/... There was probably a
lot more investigation I could have done before going to that level (as the
author suggests) but in this case it was most efficient to try replacing the
card early and identify/eliminate it as the problem.

------
edw519
Remarks from 2 mentors I have never forgotten:

1\. Everything worked fine. You came along and did something. Now it doesn't
work. I wonder if it has something to do with what you did.

2\. I seriously doubt that the operating system, which has worked perfectly
well for 20 years, suddenly and unexpectedly messed up on the exact same day
you arrived.

~~~
sant0sk1
A remark from 1 mentor I have never forgotten:

1\. If you can't think in base-8 you CAN'T be a programmer!

so I set out to write a program that would think in base-8 for me...

------
zach
I think someone's watched A Bug's Life recently.

<http://www.youtube.com/watch?v=NWSrwEYJBrg>

