- A Sentimental Gen-X Programmer Culls his Tech Books
- Cocoa Programming for Max OS X Second Edition
- Danny Goodman’s AppleScript™ Handbook
- Database Processing
- Web Design on a Shoestring
- Designing with Web Standards
- Learning Java
- DocBook 5: The Definitive Guide
- PDF Hacks
- Programming the Perl DBI
- Translucent Databases
- XQuery
- High Performance MySQL
- Code Complete
Book: Code Complete
Author: Steve McConnell
I picked this one up after it was mentioned by Jeff Atwood in the original Stack Overflow podcast. It’s a classic, but it never grabbed me. I only ever skimmed it for interesting bits. I didn’t care for the tone — like this bit on from a section called “Debugging by superstition”
If you have a problem with a program you’ve written, it’s your fault. It’s not the computer’s fault and it’s not the compiler’s fault. The program doesn’t do something different every time. It didn’t write itself, you wrote it., so take responsibility for it.
If a squint I can see how this might be well intended — but it’s pretty hostile language and aggressively lays blame at the feet of the programmer when something doesn’t work as expected. It’s true that computers don’t so something different every time — but the libraries and systems code we all rely on (even back then) are too complex for any one human to fit in their head. Blaming the programmer in order to create a sense of guilt in order to create a sense of responsibility is just a poor way to treat people/readers.
There was enough of this attitude sprinkled throughout the book that I have never been able to get past.
If I was writing the above section I might try something like this.
If there’s a problem with a program you’ve written or are working on, you’re ultimately the only one that can fix it. Maybe that third party library is doing some bananapants thing, or maybe the compiler defaults are creating behavior you’re never seen before, but those aren’t things you’ll be able to change. They’re the firmament you’re building on, and you need to work within their constraints.