I’ve been spending a bit of time lately catching up on a lot of reading. I’ve been diving into a pile of books and articles that supposedly all software engineers read. Some of the topics are common sense and others are eye opening. The list of topics range from high level overviews on software engineering to very specific technical manuals. The techie books have always been great for learning new technology. I find that the most enjoyable part of the tech books is when you can take what you’ve learned there and apply it into some real code. It doesn’t matter if its sample code that I’m working on or an actual production level product, either way learning a new technology is fun.
The books and articles that focus on software engineering in general are great to read also. I really enjoy the high level picture of how things should work. I find it very refreshing to know that so many software engineers have similar issues when it comes to attempting to create that perfect masterpiece. However, the most frustrating aspect of these books is when you try to put to practice what you’ve read. It turns out to be much easier to try out a new technology than it is to use a new programming technique or methodology. All these books offer ideas on how to create ideal software and what’s the mark of a good software engineer, but very few of them provide any information of how to truly measure it. Without know that, how can you possibly determine if any change is needed. In any case, I find all these books to be real page-turners and I can’t wait to get a few minutes to sit down and start that next chapter. I would recommend all these items to every inspiring software engineer. If you’re interesting in my current book list, you can find it below. Give a few of these a try and see how you feel about them.
Book List (in no particular order)
1. Dreaming in Code (Scott Rosenberg)
2. The Pragmatic Programmer (Andrew Hunt and David Thomas)
3. The Mythical Man-Month (Fred Brooks)
4. The Cathedral and the Bazaar (Eric Raymond)
5. No Silver Bullet – essence and accidents of software engineering (Fred Brooks)
6. Software Aspects of Strategic Defense Systems (David Parnas)
7. Software Design Manifesto (Mitch Kapor)
8. Essential Windows Presentation Foundation (Chris Anderson)
9. Joel on Software (Joel Spolsky)
10. Software Estimation: Demystifying the Black Art (Steve McConnell)
11. Code Complete, Second Edition (Steve McConnell)
12. Microserfs (Douglas Coupland)
13. Peopleware (Tom DeMarco and Timothy Lister)
14. The singularity is near : when humans transcend biology (Ray Kurzweil)
15. Zen and the art of motorcycle maintenance (Robert Pirsig)
Two cents on Software Development 
Excellent post. I totally agree with the following:
>
I read The Mythical Man Month after reading other books, like Rapid Development, in which it was so heavily cited that it was overkill to read the original source.
The only other one I read from your list was Code Complete, which is heavy going, but a must read for programmers. Other than that one, my reading tended more toward the project management and what’s wrong with software development types of books. Even Alan Cooper’s About Face really falls in that category more than into programming.
I agree Jay. Code Complete is a must read for all developers.
Greg, I just finished ‘Mythical Man-Month’ and ‘No Silver Bullet—Essence and Accident in Software Engineering’.
Suffice it to say, Fred Brooks was very observant and remarkably prescient.
Interspersed among many great points, two things caught my attention:
1. Code reuse can be expensive. It takes time and effort to develop, test, and document a component that is worthy of reuse. It also takes time for successive developers to learn about these reusable components. Perhaps most notably, a development shop must know in advance which components will be reused for it to realize any benefits of scale.
2. [Direct Quote from the MM-M]:
…The reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer’s reluctance to commit himself to the defense of decisions which he knows to be tentative. “By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.”