| [Agans 2002] | David J. Agans:
Debugging.
American Management Association,
2002,
0814471684.
|
Its first sentence says, “This book tells you how to find out
what's wrong with stuff, quick,” and that's exactly what it
does. In fifteen (very) short chapters, the author presents nine
simple rules to help you track down and fix problems in software,
hardware, or anything else. His war stories are entertaining
(although I think one or two are urban myths), and his advice is
eminently practical.
|
| [Brand 1995] | Stewart Brand:
How Buildings Learn.
Penguin USA,
1995,
0140139966.
|
This beautiful, thought-provoking book starts with the observation
that most architects spend their time re-working or extending
existing buildings, rather than creating new ones from scratch. Of
course, if Brand had written “program” instead of
“building”, and “programmer” where he'd
written “architect”, everything he said would have been
true of computing as well. A lot of software engineering books try
to convey the same message about allowing for change, but few do it
so successfully. By presenting examples ranging from the MIT Media
Lab to a one-room extension to a house, Brand encourages us to see
patterns in the way buildings change (or, to adopt Brand's metaphor,
the way buildings learn from their environment and from
use). Concurrently, he uses those insights to argue that since
buildings are always going to be modified, they should be designed
to accommodate unanticipated change.
|
| [Castro 2002] | Elizabeth Castro:
HTML for the World Wide Web.
Peachpit Press,
2000,
0321130073.
|
A clean, clear, comprehensive guide to creating HTML for the web,
with good coverage of Cascading Style Sheets (CSS).
|
| [Castro 2000] | Elizabeth Castro:
XML for the World Wide Web.
Peachpit Press,
2000,
0201710986.
|
Like other books in Peachpit's Visual Quickstart series, this one is
beautifully designed, and easy to read without ever being
condescending. Its 16 chapters and 4 appendices are organized into
1- and 2-page explanations of particular topics, from writing
non-empty elements to namespaces, schemas, and XML
transformation. Throughout, Castro strikes a perfect balance between
“what”, “why”, and “how”, and
provides a surprising amount of detail without ever overwhelming the
reader.
|
| [Chase & Simon 1973] | W.G. Chase and H.A. Simon:
"Perception in chess",
Cognitive Psychology,
vol. 4,
no. ,
pp. 55-81,
1973.
|
The original paper comparing the performance of novice and master
chess players when confronted with actual and random positions.
|
| [Clark 2004] | Mike Clark:
Pragmatic Project Automation.
Pragmatic Bookshelf,
2004,
0974514039.
|
This entry in the Pragmatic Bookshelf series focuses on getting your
project to build itself, and (more importantly) tell you how the
build went, automatically. Clark doesn't confine himself to running
Make at 3:00 a.m.; he also covers ways of automatically re-running
tests, building and testing installers, monitoring applications, and
more.
|
| [DeMarco & Lister 1999] | Tom DeMarco and Timothy Lister:
Peopleware.
Dorset House,
1999,
0932633439.
|
This was the first book I ever read that said that the leading cause
of software project failure was people, rather than technology.
Using anecdotes, humor, and common sense, DeMarco and Lister explain
how important good physical space, aligning authority with
responsibility, and clear direction are.
|
| [Fehily 2003] | Chris Fehily:
SQL.
Peachpit Press,
2003,
0321118030.
|
This very readable book describes the 5% of SQL that covers 95% of
real-world needs. While the book moves a little slowly in some
places, the examples are exceptionally clear.
|
| [Feldman 1979] | Stuart I. Feldman:
"Make---A Program for Maintaining Computer Programs",
Software: Practice and Experience,
vol. 9,
no. 4,
pp. 255-265,
1979.
|
The original description of Make. Last time I checked, Stu Feldman
was a vice president at IBM, which shows you just how far a good
tool can take you…
|
| [Feathers 2005] | Michael C. Feathers:
Working Effectively with Legacy Code.
Prentice-Hall PTR,
2005,
0131177052.
|
Most programmers spend most of their time fixing bugs, porting to
new platforms, adding new features---in short, changing existing
code. If that code is exercised by unit tests, then changes can
be made quickly and safely; if it isn't, they can't, so your first
job when you inherit legacy code should be to write some. That's
where this book comes in. What to know three different ways to
inject a test into a C++ class without changing the code? They're
here. Want to know which classes or methods to focus testing on?
Read his discussion of pinch points. Need to break inter-class
dependencies in Java so that you can test one module without
having to configure the entire application? That's in here too,
along with dozens of other useful bits of information. Everything
is illustrated with small examples, all of them clearly explained
and to the point. There are lots of simple diagrams, and a short
glossary; all that's missing is hype.
|
| [Fowler 1999] | Martin Fowler:
Refactoring.
Addison-Wesley Professional,
1999,
0201485672.
|
Like architects, most programmers spend most of their time
renovating, rather than creating something completely new on a blank
sheet of paper. This book presents and analyzes patterns that come
up again and again when programs are being reorganized. Some of
these are well-known, such as placing common code in a utility
method. Others, such as replacing temporary objects with queries, or
replacing constructors with factory methods, are subtler, but no
less important. Each entry includes a section on motivation, the
mechanics of actually carrying out the transformation, and an
example in Java.
|
| [Friedl 2002] | Jeffrey E. F. Friedl:
Mastering Regular Expressions.
O'Reilly,
2002,
0596002890.
|
The definitive programmer's guide to regular expressions.
|
| [Gamma et al 1995] | Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides:
Design Patterns.
Addison-Wesley,
1995,
0201633612.
|
The book that started the software design patterns movement. Much
of the discussion has been superseded by more recent books, and the
use of C++ and Smalltalk for examples feels a little dated, but it
is still a landmark in programming.
|
| [Glass 2002] | Robert L. Glass:
Facts and Fallacies of Software Engineering.
Addison-Wesley Professional,
2002,
0321117425.
|
I really wish someone had given me something like this book when I
took my first programming job. If nothing else, it would have been a
better way to start thinking about the profession I had stumbled
into than the “everybody knows” factoids that I soaked
up at coffee time. Some of what he says is well-known: good
programmers are up to N times better than bad ones (his value for N
is 28), reusable components are three times harder to build than
non-reusable ones, and so on. Other facts aren't part of the
zeitgeist, though they should be. For example, most of us know that
maintenance consumes 40-80% of software costs, but did you know that
roughly 60% of that is enhancements, rather than bug fixes? Or that
if more than 20-25% of a component has to be modified, it is more
efficient to re-write it from scratch? Best of all, Glass backs up
every statement he makes with copious references to the primary
literature; if you still disagree with him, you'd better be sure you
have as much evidence for your point of view as he has for his.
|
| [Goerzen 2004] | John Goerzen:
Foundations of Python Network Programming.
APress,
2004,
1590593715.
|
This book looks at how to handle several common protocols, including
HTTP, SMTP, and FTP. Goerzen also doesn't delve as deeply into their
internals, but instead on how to build clients that use them. His
approach is to build solutions to complex problems one step at a
time, explaining each addition or modification along the way. He
occasionally assumes more background knowledge than most readers of
this book are likely to have, but only occasionally, and makes up
for it by providing both clear code, and clear explanations of why
this particular function has to do things in a particular order, or
why that one really ought to be multithreaded.
|
| [Good 2005] | Nathan A. Good:
Regular Expression Recipes.
APress,
2005,
159059441X.
|
A great how-to for regular expressions, with examples in many
different languages.
|
| [Gunderloy 2004] | Mike Gunderloy:
Coder to Developer.
Sybex,
2004,
078214327X.
|
This practical, readable book is subtitled “Tools and
Strategies for Delivering Your Software”, and that's
exactly what it's about. Project planning, source code control,
unit testing, logging, and build management are all
there. Importantly, so are newer topics, like building plugins
for your IDE, code generation, and things you can do to protect
your intellectual property. Everything is clearly explained, and
illustrated with well-chosen examples. While the focus is
definitely on .NET, Gunderloy covers a wide range of other
technologies, both proprietary and open source. I'm already
using two new tools based on references from this book, and plan
to make the chapter on “Working with Small Teams”
required reading for my students.
|
| [Harold 2004] | Elliotte Rusty Harold:
Effective XML.
Addison-Wesley,
2004,
0321150406.
|
This book explains which of XML's many features should be used when:
Item 12 tells you to store metadata in attributes, and then spends
six pages explaining why, while Item 24 analyzes the strengths and
weaknesses of various schema languages, and Item 38 covers character
set encodings. It's more than most developers will ever want to
know, but when you need it, you really need it.
|
| [Hock 2004] | Roger R. Hock:
Forty Studies that Changed Psychology.
Prentice Hall,
2004,
0131147293.
|
In forty short chapters, Hock describes the turning points in
our understanding of how our minds work. The book isn't just
about psychology; you'll also learn a lot about how science gets
done, and about the scientists who do it.
|
| [Hunt & Thomas 1999] | Andrew Hunt and David Thomas:
The Pragmatic Programmer.
Addison-Wesley,
1999,
020161622X.
|
This book is about those things that make up the difference between
typing in code that compiles, and writing software that reliably
does what it's supposed to. Topics range from gathering requirements
through design, to the mechanics of coding, testing, and delivering
a finished product. The second section, for example, covers
“The Evils of Duplication”, “Orthogonality”,
“Reversibility”, “Tracer Bullets”,
“Prototypes and Post-It Notes”, and “Domain
Languages”, and illuminates each with plenty of examples and
short exercises.
|
| [Johnson 2000] | Jeff Johnson:
GUI Bloopers.
Morgan Kaufmann,
2000,
1558605827.
|
Most books on GUI design are long on well-meaning aesthetic
principles, but short on examples of what it means to put those
principles into practice. In contrast, GUI Bloopers presents case
study after case study: what's wrong with this dialog? What should
its creators have done instead. And, most importantly, why? The net
effect is to teach all of the same principles that other books try
to, but in a grounded, understandable way.
|
| [Kernighan & Pike 1984] | Brian W. Kernighan and Rob Pike:
The Unix Programming Environment.
Prentice Hall,
1984,
013937681X.
|
I have long believed that this book is the real secret to Unix's
success. It doesn't just show readers how to use Unix---it explains
why the operating system is built that way, and how its "lots
of little tools" philosophy keeps simple tasks simple, while making
hard ones doable.
|
| [Kernighan & Ritchie 1998] | Brian W. Kernighan and Dennis Ritchie:
The C Programming Language.
Prentice Hall PTR,
1998,
0131103628.
|
The classic description of the one programming language every
serious programmer absolutely, positively has to learn.
|
| [Knuth 1998] | Donald E. Knuth:
The Art of Programming.
Addison-Wesley,
1998,
0201485419.
|
The lifework of the man who invented many of the basic concepts of
algorithm analysis, these massive tomes are like Everest:
awe-inspiring, but not for the weak of heart. Most readers will
find
[Sedgewick 2001]
much more approachable.
|
| [Langtangen 2004] | Hans P. Langtangen:
Python Scripting for Computational Science.
Springer-Verlag,
2004,
3540435085.
|
The book's aim is to show scientists and engineers with little
formal training in programming how Python can make their lives
better. Regular expressions, numerical arrays, persistence, the
basics of GUI and web programming, interfacing to C, C++, and
Fortran: it's all here, along with hundreds of short example
programs. Some readers may be intimidated by the book's weight, and
the dense page layout, but what really made me blink was that I
didn't find a single typo or error. It's a great achievement, and a
great resource for anyone doing scientific programming.
|
| [Lutz & Ascher 2003] | Mark Lutz and David Ascher:
Learning Python.
O'Reilly,
2003,
0596002815.
|
This is not only the best introduction to Python on the market, it
is one of the best introductions to any programming language that I
have ever read. Lutz and Ascher cover the entire core of the
language, and enough of its advanced features and libraries to give
readers a feeling for just how powerful Python is. In keeping with
the spirit of the language itself, their writing is clear, their
explanations lucid, and their examples well chosen.
|
| [Margolis & Fisher 2002] | Jane Margolis and Allan Fisher:
Unlocking the Clubhouse.
MIT Press,
2002,
0262133989.
|
This book describes a project at Carnegie-Mellon University that
tried to figure out why so few women become programmers, and what
can be done to correct the imbalance. Its first six chapters
describe the many small ways in which we are all, male and female,
are conditioned to believe that computers are "boy's things".
Sometimes it's as simple as putting the computer in the boy's
room, because "he's the one who uses it most". Later on, the "who
needs a social life?" atmosphere of undergraduate computer labs
drives many women away (and many men, too). The last two chapters
describe what the authors have done to remedy the situation at
high schools and university. This work proves that by being
conscious of the many things that turn women off computing, and by
viewing computer science from different angles, we can attract a
broader cross-section of society, which can only make our
discipline a better place to be. The results are impressive:
female undergraduate enrolment at CMU rose by more than a factor of
four during their work, while the proportion of women dropping out
decreased significantly.
|
| [Martelli 2005] | Alex Martelli, Anna Ravenscroft, and David Ascher:
Python Cookbook.
O'Reilly,
2005,
0596007973.
|
A useful reference for every serious Python programmer, this book is
a collection of tips and tricks, some very simple, others so complex
that they require careful line-by-line reading. The book's companion
web site is updated regularly.
|
| [Mason 2005] | Mike Mason:
Pragmatic Version Control Using Subversion.
Pragmatic Bookshelf,
2005,
0974514063.
|
Yet another book from the folks at Pragmatic, this one is everything
you'll ever need to know about Subversion, which is on its way to
becoming the version control system of choice for open source
development.
|
| [McConnell 2004] | Steve McConnell:
Code Complete.
Microsoft Press,
2004,
0735619670.
|
This classic is a handbook of do's and don'ts for working
programmers. It covers everything from how to avoid common mistakes
in C to how to set up a testing framework, how to organize
multi-platform builds, and how to coordinate the members of a team.
In short, it is everything I wished someone had told me
before I started my first full-time programming job.
|
| [McConnell 1996] | Steve McConnell:
Rapid Development.
Microsoft Press,
1996,
1556159005.
|
This book describes what it takes to develop robust code quickly,
what mistakes are often made in the name of rapid development, and
how to identify and analyze potential risks. It includes a list of
25 best practices, and discusses things that most other books leave
out (like recovering from disasters and dealing with impossible
demands). Unlike most “how to do it better” books, it
isn't try to sell any particular practice or style, which adds even
more weight to McConnell's carefully balanced opinions.
|
| [McConnell 1997] | Steve McConnell:
Software Project Survival Guide.
Microsoft Press,
1997,
1572316217.
|
A condensed manager-level version of the same author's Rapid Development.
|
| [Pilgrim 2004] | Mark Pilgrim:
Dive Into Python.
APress,
2004,
1590593561.
|
A good introduction to Python, which is also available on-line at
Dive Into Python .
|
| [Powazek 2001] | Derek M. Powazek:
Design for Community.
New Riders,
2001,
0735710759.
|
This book isn't about web logging, streaming video, or managing
mailing lists. Instead, it's about how to structure web sites so
that they will foster on-line communities. The writing is personal
without being sappy or overbearing, and the author draws upon a
wealth of personal experience to explain why you sometimes don't
want to make it easy for people to post comments, or how best to
deal with abusive posters. There's a lot of no-nonsense analysis of
the cost of interactivity, and interviews with the creators of some
of the web's most successful community sites.
|
| [Ray & Ray 2003] | Deborah S. Ray and Eric J. Ray:
Unix.
Peachpit Press,
2003,
0321170105.
|
A gentle introduction to Unix, with many examples.
|
| [Rosenberg & Stephens 2005] | Doug Rosenberg and Matt Stephens:
Use Case Driven Object Modeling with UML.
Addison-Wesley,
2005,
0321278275.
|
An update of Rosenberg's 1999 book of the same name; in just eight
chapters, the authors present a slimmed-down core of UML organized
around a four-stage design process. Each stage has clearly defined
steps, and concrete milestones which specify what ought to be
produced (i.e., how to tell when you're finished).
|
| [Scanlan 1989] | David A. Scanlan:
"Structured Flowcharts Outperform Pseudocode: An Experimental Comparison",
IEEE Software,
vol. 6,
no. 5,
pp. 28-36,
1989.
|
Describes an experimental comparison of pseudocode with
equivalently-structured flowcharts, in which flowcharts did
much better than in earlier studies.
|
| [Schneier 2003] | Bruce Schneier:
Beyond Fear.
Springer,
2003,
0387026207.
|
A thought-provoking look at how we are encouraged to think about
security, and how much security is actually desirable. For example,
he explains why security systems must not just work well, but
fail well, and why secrecy often undermines security instead
of enhancing it.
|
| [Schneier 2005] | Bruce Schneier:
Secrets and Lies.
Wiley,
2005,
0471453803.
|
Having written the standard book on cryptography, Schneier now
argues that technology alone can't solve most real security
problems. The book covers systems and threats, the technologies used
to protect and intercept data, and strategies for proper
implementation of security systems. Rather than blind faith in
prevention, Schneier advocates swift detection and response to an
attack, while maintaining firewalls and other gateways to keep out
the amateurs.
|
| [Sedgewick 2001] | Robert Sedgewick:
Algorithms in C, Parts 1-5.
Addison-Wesley Professional,
2001,
0201756080.
|
Far too many programmers still think and code as if resizeable
vectors and string-to-pointer hash tables were the only data
structures ever invented. These books are a guide to all the other
conceptual tools that working programmers ought to have at their
fingertips, from sorting and searching algorithms to different kinds
of trees and graphs. The analysis isn't as deep as that in Knuth's
monumental The Art of Programming, but
that makes the book far more accessible. And while the author's use
of C may seem old-fashioned in an age of Java and C#, it does ensure
that nothing magical is hidden inside an overloaded operator or
virtual method call.
|
| [Skoudis 2004] | Ed Skoudis:
Malware.
Prentice-Hall,
2004,
0131014056.
|
This 647-page tome is a survey of harmful software, from viruses
and worms through Trojan horses, root kits, and even malicious
microcode. Each threat is described and analyzed in detail, and
the author gives plenty of examples to show exactly how the attack
works, and how to block (or at least detect) it. The writing is
straightforward, and the case studies in Chapter 10 are funny
without being too cute.
|
| [Spinellis 2003] | Diomidis Spinellis:
Code Reading.
Addison-Wesley,
2003,
0201799405.
|
The book's preface says it best: “The reading of code is
likely to be one of the most common activities of a computing
professional, yet it is seldom taught as a subject or formally used
as a method for learning how to design and program.” Spinellis
isn't the first person to make this point, but he is the first
person I know of to do something about it. In this book, he walks
through hundreds of examples of C, C++, Java, and Perl, drawn from
dozens of Open Source projects such as Apache, NetBSD, and Cocoon.
Each example illustrates a point about how programs are actually
built. How do people represent multi-dimensional tables in C? How
do people avoid nonreentrant code in signal handlers? How do they
create packages in Java? How can you recognize that a data
structure is a graph? A hashtable? That it might contain a race
condition? And on, and on, real-world issue after real-world issue,
each one analyzed and cross-referenced. There's also a section on
additional documentation sources, and a chapter on tools that can
help you make sense of whatever you've just inherited.
|
| [Steele 1999] | Guy L. Steele Jr.:
"Growing a Language",
Journal of Higher-Order and Symbolic Computation,
vol. 12,
no. 3,
pp. 221-236,
1999.
|
The best (and wittiest) discussion ever published of how programming
languages ought to evolve.
|
| [Spolsky 2004] | Joel Spolsky:
Joel on Software.
APress,
2004,
1590593898.
|
Joel on Software collects some of
the witty, insightful articles Spolsky has blogged over the past few
years. His observations on hiring programmers, measuring how well a
development team is doing its job, the API wars, and other topics are always
entertaining and informative. Over the course of forty-five short
chapters, he ranges from the specific to the general and back again,
tossing out pithy observations on the commoditization of the
operating system, why you need to hire more testers, and why NIH
(the not-invented-here syndrome) isn't necessarily a bad thing.
|
| [Thompson & Chase 2005] | Herbert H. Thompson and Scott G. Chase:
The Software Vulnerability Guide.
Charles River Media,
2005,
1584503580.
|
My current favorite guide to computer security for programmers,
this books walks through each major family of security holes in
turn: faulty permission models, bad passwords, macros, dynamic
linking and loading, buffer overflow, format strings and various
injection attacks, temporary files, spoofing, and more.
|
| [Ullman & Liyanage 2004] | Larry Ullman and Marc Liyanage:
C Programming.
Peachpit Press,
2004,
0321287630.
|
A gentle introduction to C, with many examples.
|
| [Williams & Kessler 2003] | Laurie Williams and Rober Kessler:
Pair Programming Illuminated.
Addison-Wesley,
2003,
0201745763.
|
A combination of an instruction manual, a summary of the authors'
empirical studies of pair programming's effectiveness, and
advocacy, this book is the reference guide for anyone who wants
to introduce pair programming into their development team.
|
| [Wilson 2005] | Greg Wilson:
Data Crunching.
Pragmatic Bookshelf,
2005,
0974514071.
|
Every day, all around the world, programmers have to recycle legacy
data, translate from one vendor's proprietary format into another's,
check that configuration files are internally consistent, and search
through web logs to see how many people have downloaded the latest
release of their product. It may not be glamorous, but knowing how
to do it efficiently is essential to being a good programmer. This
book describes the most useful data crunching techniques, explains
when you should use them, and shows how they will make your life
easier.
|