The best books for a budding C++ software engineer

This tour de force probably couldn't get written today. Kernighan and Plauger take snippets of Fortran and PL/I code from real, published textbooks and find things to fix about them. Now, many of their specific concerns are relics of the "structured programming" wars of the 1960s (overuse of arithmetic IF and GOTO) or quirks of the programming languages in question (undeclared variables silently getting the wrong type); but this is educational in itself. If you wonder what's so bad about GOTO, or why we need to declare functions and variables before use, this book may enlighten you. And despite its age, almost every example finds some present-day analog. For example, Kernighan and Plauger's advice to avoid manually counted Hollerith strings in Fortran applies equally to manually counted array bounds in C++: don't write "int a[5]" when you can write "int a[]". The authors boil every couple of pages down to a language-agnostic mantra, such as: "Let the machine do the dirty work." "Make input easy to prepare and output self-explanatory." "If a logical expression is hard to understand, try transforming it."

The title, of course, is a reference to Strunk and White's The Elements of Style (1959), which has its own mantras equally applicable to software design: "Put statements in positive form." "Use orthodox spelling." "Express coordinate ideas in similar form." But that's a story for another day.

Next to Fred Brooks' The Mythical Man-Month, this is perhaps the most classic of all classic programming books.

The authors write: "Besides showing how to make effective use of the language, we have also tried where possible to illustrate useful algorithms and principles of good style and sound design."

The book is astoundingly practical as a tutorial, which is itself a testament to the Unix "pipe" model of programming: By page 13, they've introduced getchar and putchar, and by the end of Chapter 1, twenty pages later, you've implemented a host of useful utilities including cat, wc, and detab. In Chapter 5 you implement a function recognizable as the now-standard qsort; in Chapter 8 you implement malloc itself.

Now, I recommend "K&R1," not the more popular "K&R2." The first edition was issued in 1978 at a slim 225 pages; the second edition, a decade later, added conformance with ANSI Standard C89 at the cost of an additional 50 pages in the process. At the time, this was a bargain: you get all the timeless benefits of K&R, plus learn C89 in the process.

These days, I'm not sure learning C89 is much better than learning K&R C: you'll have to update your knowledge somehow, either way. And I like old things. So I recommend you treat yourself to a trip through history and read K&R1. To coin a phrase: "Get the little book!"

This book greatly influenced my philosophy around style. Norman's ostensible subject is the design of physical objects, like emergency exits, shower faucets, and refrigerators, but most of what he says is directly applicable to software design and API design, too.

For example: Whatever you expose or document about your interface, the user will take that and form a mental model of the implementation—and he'll program against that mental model, not against your documentation. So you'd better make sure that your interface—by exposing certain details and deemphasizing others, appropriate naming, and so on—suggests a mental model that will be useful to the user (even if it is not correct in every particular).

For example, a horizontal rod mounted on a door affords pushing (a bit of jargon that's entered my technical vocabulary), while a vertical rod affords pulling. If you use the design language of a horizontal rod, people will push it, no matter how many signs you put up! Designing appropriate interfaces is an important art for the software engineer; this book may open your eyes to patterns you never saw before.

Every "computer person" should read GEB at least once. Preferably in high school, when you still have the free time to dive deep into all the recreational math exercises. If you're already working 40-hour weeks and wonder who has time for Hofstadter's 750-page "metaphorical fugue on minds and machines," all I can say is: Better late than never!

Scott Meyers' Effective C++ series was insanely influential around the turn of the millennium. Then C++11 obsoleted almost the whole series by changing the language out from under it. This book—Scott Meyers' last, as of 2024—is the only one that remains relevant to today's C++. It assumes the reader is reasonably familiar with C++98, and then explains smart pointers, move semantics, perfect forwarding, std::initializer_list, decltype and auto, and many other "modern C++" features, in Meyers' trademark item-oriented format, which is easily digestible and quotable.

The past decade of C++ standardization has added plenty of things that this book doesn't mention; but the subjects it does talk about, by and large, have not yet become obsolete. And there's still nobody who writes about C++ quite like Scott Meyers.