Return to Answer

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.

EDIT

Yes, my point #1 is overstated. Even the best engineered application platforms do have their share of bugs, and some of the less well engineered ones are rife with them. But even so, you should always suspect your code first, and only start blaming compiler / library bugs when you have clear evidence that your code is not at fault.

Back in the days when I did C / C++ development, I remember cases where supposed optimizer "bugs" turned out to be a due to me / some other programmer having done things that the language spec says have undefined results. This applies even for supposedly safe languages like Java; e.g. take a long hard look at the Java memory model (JLS chapter 17).

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.

The bug is in your code, not the compiler or the runtime libraries.

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.