6.12.0.3

Readings

keep your brain busy

The following lists of books and book chapters cover many of the ideas from this course:

  • Gamma, Helm, Johnson, Vlissides. Design Patterns. Addison-Wesley, 1995

    While editors keep dictionaries and style guides on their shelves, beginning software developers put this book on their desk.

  • Beck. Extreme Programming Explained. Addison-Wesley, 1999

    Beck is one of the first "explainers" of test-driven and extreme programming. He picked it up from 1980s academics, with whom he shared lab space in the 1990s. This book explains the whole eco-system of test-driven, example-driven, iterative software design and coins the phrase "extreme" programming. The philosophies are reminiscent of those of Fundamentals I and II—scaled to size.

    The book is a handy reference of how to approach software development in this style, though it could have been written as a 10 page essay.

  • Williams, Kesler. Pair Programming Illuminated. Addison-Wesley, 2002

    Williams conducted extensive research under Keller’s guidance on pair programming: the what, the how, its benefits, its potential downsides, the common misunderstandings, etc. This book presents her dissertation results as a an easily accessible guide to the practice.

  • Fowler, Scott. UML Distilled. Addison-Wesley, 1997

    For better or worse, you will encounter UML during your career. This book is one of many that explains UML and how to use some of it. This course uses UML simply as a doodling notation because you may encounter it in the real world.

  • Hunt and Thomas. The Pragmatic Programmer. Addison-Wesley, 1999

    Do not stop reading about the practice of software development after you take your first, second or third job. Keep up with what articulate developers have to say about creating good software and the practices that help. This book is an example of this kind of reading, practical and good advice from experienced programmers in a guru-style manner.

  • Strunk and White. Elements of Style, 3rd edition

    You will need to write memos if your investment into your education here is to pay off. This little book—a stand-by for many American editors for nearly a century—will help you express your thoughts in a concise manner. It is worth purchasing a copy and keeping it on your desk for the rest of your career, right next to an English dictionary. Your books on programming and software development will change far more often.

    Caveat Some rules in this book give questionable advice.

An enlightened software developer will eventually read most of these texts—and many more—it is unnecessary to read them to obtain a good grade (though I may insist on having you read an occasional chapter). Then again, I assume that college students who take my courses are not in it for grades but to learn and to prepare themselves for a career.

End Note On many occasions, CCS graduates end up in industry positions where their peers and supervisors do not know of, question, or reject (intentionally or subconsciously) the ideas and techniques taught in this course. Time and again, such graduates have approached me about how to educate their colleagues in these situations, because they have seen these ideas work for reasonably large projects. My best recommendation is to pick and choose readings (chapters, sections, blogs) from the above or based on the above list. It has the advantage of presenting the ideas independently of the course(s) and in a form that targets working programmers. (Nobody knows how to deal with managers.)