Readings
The course requires a single reading, namely, the chapter on "ego-less programming" of the following book:
Weinberg. The Psychology of Computer Programming. Vab Nostrand Reinhold Co., 1971
This incredibly old book contains a lot of astute observations about the relationship between code and its creator, the software developer. Don’t get scared just because it uses code snippets from one of the worst languages ever designed (Hopper’s COBOL). The observations, and Weinberg’s suggestions on how to think about/react to them are good ones.
The following lists of (also old) books and book chapters cover many of the ideas from this course:
Gamma, Helm, Johnson, Vlissides. Design Patterns. Addison-Wesley, 1995
Northeastern’s library makes the on-line version available to all students.
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.
Beck also wrote an equally concise book on agile programming. You may wish to look into this one, too.
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 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. There isn’t much to teach about it (until some manager really insists on it, at which point you may wish to look for a new job).
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.
End Note On many occasions, CCIS 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 and its prerequisites. 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 for real.)