Hi, I was wondering what are your favorite “technical books” and why do you love them? By “technical books,” I mean stuff that I could reasonably expense as part of my work’s learning budget. By “timeless,” I mean that they won’t immediately go out of date once the next version of the software is released.
I really love Coders at Work.
Coders At Work and Code (by Petzold) were the first two books I read on software development in late high school.
I’m glad to have such books in my formative times as a dev
Advanced Programming in the Unix Environment – a must-read for (aspiring) systems programmers.
I read the second edition. Many of the code examples were written targeting 90s BSD systems, and in many cases the code no longer compiles. There’s now a third edition, which I assume is updated for recentish Linux.
In either case, the fundamentals of Unix are still as relevant as ever.
I was going to say that I couldn’t think of any technical books that aren’t dated, but you’ve given a great counterexample. In particular, APUE talks about the rationale for the decisions and so let’s you easily understand which bits are still relevant and which bits were solving problems that aren’t the same ones that today’s software solves.
For anyone thinking about working on a kernel, Symbian Kernel Internals is a fantastic overview of a design that I wish more people would copy. It was, unfortunately, very poorly timed in hindsight. Symbian EKA2 was designed to support an application stack for the UI and a real-time stack for the radio in a single core, with no special hardware. Unfortunately, by the time it was finished, sticking a second ARM core on an SoC was sufficiently cheap that it didn’t really make sense to squeeze everything into one core. RAM was a bigger cost factor and EKA2 wanted to statically provision memory for the real-time stack to avoid allocation on any real-time paths. This meant it didn’t save much. In most other respects, it was ahead of its time. The driver model had power management built in from the start. The nano kernel did the kind of isolation that Hafnium is now bringing to Android (and that XNU now has for iOS). It’s a huge shame that Nokia decided that the solution to the problem, of having a dated and painful to use userland on an amazing kernel was to replace the kernel with Linux.
This year I read Debugging - The 9 Indispensable Rules The book is more than twenty year old at this point and use as example, among other thing, a lisp server connected to Mac System via serial cable. But you are not here for that, you are here for the 9 rules. I loved it so much that I have the 9 rules on a post-it under my screen and I glance at them everytime I have to investigate something in production. I think this is an underated book, but I would agree that the advice do end up being a bit obvious/generic
Data and Reality By William Kent is an all time favorite of mine, but the 3rd edition has been badly butchered. If you can find the 2nd edition somewhere I would go with that.
The Mythical Man Month by Fred Brook need no introduction. What I like about the edition I have is that it also contains not only his famous “No Silver Bullet” essay, but also a commentary on “No Silver bullet” that preemptively addressed most modern take on the essay that try to disprove it. Found it interesting.
I still love Domain Driven Design, and it still fill me with insight when I reread it. But I wish Eric Evans would update it to add the “missing” chapter on business events and also to deemphasize the OOP patterns, as a lot of people tend to focus on them rather than the more important concept of a shared language between the business and techical people.
I have high hope that Designing Data Intensive Application will stand up to the test of time, but its too early to tell. Still a big “recommend” from me, and it will absolutely remain relevant for the next 5-10 years at least
I have a harder and harder time recommending Clean Code, but there are still some good advice in it. Just skip the endless chapter where Martin refactor a class, the result is… not that great.
The 2nd edition is out of print and completely unavailable on ABE Books or Amazon. But you can find the 2nd edition in PDF form here and there online.
Dang, I’ve always meant to work through Data and Reality - what’s so bad about the 3rd edition?
The first problem is that whole portion of the text were removed because they were”outdated”. This is not a book about a specific technology, so it doesn’t matter that he speak about old stuff.
But the most annoying part is that the modern commentary by Steve Oberman is interspersed with the original text, and it end up altering the tone of the book a lot. Kent was meditating about software, asking question to the reader and making him reflect on how his software diverge from real life.
Oberman is more your traditional consultant telling you his data modeling method. He “know” how to answer Kent question. This is really annoying. I believe it is the real reason he removed portion of the text: it didn’t fit his view of how things should be done.
A much better way to update the book would have been to put the commentary at the end of each chapter, without altering Kent text. This way, we would have the original meaning and could then compare with Oberman own take on the matter.
I’ve only read the third edition and came away thinking it fair for an introduction to thinking about these things but otherwise lightweight. Hoberman’s interjections added useful context or explanation in a couple of places but were by and large unnecessary. Comparing it with the second edition, it’s three chapters lighter and huge swaths of others are also missing; chapter 7, Models, is almost halved.
It really is appalling. The guy who did the ‘revision’ adds all this commentary inline…but it’s clear that he truly doesn’t understand what the author is talking about.
+1 for Debugging. I’ve bought a few copies of it and given to people. It deserves more attention than it gets.
I try to keep a small shelf of books that transcend computing. https://functional.cafe/@fogus/109528016050758817
All of these books taught me about programming in general while also introducing me to the specifics and details of a language or a style of programming. (Kernighan is a common element, but I have no shame about that. He’s a remarkable writer. You can learn a ton from his UNIX manuals as well.)
I also highly recommend Jay Wengrow’s A Common-Sense Guide to Data Structures and Algorithms, but it’s not for everyone. I love this book, but I never studied CS in school (and my furthest math class was high-school-level algebra). If you’ve had formal training, it’s probably not something you need. (And you’ll likely find it too simple.)
My favorite is SICP + the original video lectures https://www.youtube.com/watch?v=-J_xL4IGhJA
I also enjoyed the little, seasoned, reasoned schemer and little prover. great fun.
and “Sets for mathematics” I would highly recommend this book to anybody who is curious about learning some mathematics, even if you do not know mathematics.
The two books I recommend, as they were two that fundamentally changed how I code:
‘Thinking Forth’ is an amazing book. I read it as a teenager and still recommend it to people today even if they have no interest in Forth.
I constantly go back to Domain Modeling Made Functional.
It provides a great introduction to functional concepts and mapping them to business domains. I haven’t read the original Domain Driven Design, but I don’t feel like I’m missing anything.
It’s written for F#, but I think it would apply to Haskell and Rust just as easily.
The Art of Electronics by Horowitz and Hill is an electrical engineering classic, starting with how transistors work and ending up at some quite advanced circuit design. What I appreciate is how intuitive the explanations are. It reads less like a traditional textbook and more like one of those cookbooks that explain how the cooking process works. Thank you Transistor Man!
I love The Practice of Programming - the examples are C, but the principles are timeless.
I am pleasantly surprised that so many of these responses include reasons why each title is so treasured. Too often, on other forums, these threads turn into a dumping of names and affiliate links.
I thoroughly recommend the first edition of Fowler’s Refactoring: Improving the design of existing code. The first edition is the only one that involves a compiled language (Java), and the explosion of strongly-typed languages and gradual typecheckers means that the Ruby edition and the second (JS) edition do not hold up as well.
The objective: “make the hard change easy, then make the easy change”. Make the hard change easy by making small, invertible, meaning-preserving code transformations until the program is in the right shape to accept your new change.
Steve Yegge describes it as “[w]hen I read this book for the first time, in October 2003, I felt this horrid cold feeling, the way you might feel if you just realized you’ve been coming to work for 5 years with your pants down around your ankles.” I had the same experience when I read it too.
One of the few tech books I reread every now and then, because it’s full of useful advice is Working Effectively with Legacy Code.
Also, imagine trolling your lead/manager/architect by having the entire team order a copy with their learning budget.
EDIT: I just had to link this: https://www.commitstrip.com/en/2019/03/13/like-a-good-wine/?
I’ve read a few chapters of this book; do you think there is much more that is actionable from the book than the thesis, which is that “legacy code is code without tests”? Crack open legacy code by writing tests for it and it becomes manageable (this is also the best way to learn it). Keep it as an impenetrable blob and it will be unmanageable forever. I’ve certainly found that to be true.
I admit, there is some Agile ideology being associated with this book. I am after the practical side though.
Regardless of anyone’s definition of legacy code, all programmers inevitably encounter other people’s code. The book teaches valuable techniques to get that code under control.
The first book that comes to mind is The Little Schemer. I had not written anything in the Lisp family of languages before nor since, but nevertheless had my own “My God, it’s full of
cars” moment when going through the exercises. I don’t think any other book expanded the ways I think about programming so much.Ted Nelson’s Computer Lib / Dream Machines is a wild and crazy book from the mid 70s, mostly handwritten with doodles. It’s large (11x17”?) and each side is a different book.
It’s a period piece, but still a blast to read.
The original was self-published and long OOP. There was a mainstream edition in the 90s that was a travesty, all typeset and squished to normal size. But lately Nelson’s been selling a facsimile edition identical to the original. I’m proud to have a signed copy. You can get it at https://computerlibbook.com/ .
My favorite one is: The Pragmatic Programmer, Second Edition
I really like explaining stuff, but when the person just don’t have the craft mindset yet (but want to have it), I always fall short and recommend this book. It’s an amazing introductory book to software craft that covers A LOT of concepts, practices, techniques,….
When people start to grasp these and change their mindset, they always have interesting questions :)
To give the book more importance, get the hardcover one, it feels really good!
I’d loved to have this book when starting to want to be good! Nowedays I order a buch of them and almost give them to my collegues / friends, it’s just soo important!!
To me the “obvious” ones would be “The Art of Computer Programming” by Donald Knuth and “Introduction to Algorithms” by Cormen, Leiserson, Rivest, and Stein (CLRS).
I also really like “The Algorithm Design Manual” by Steven Skiena - great mixture of entertaining stories, very practical advice, and good high-level algorithms reference.
One of the best books I have read in recent years was “Designing Data-Intensive Applications”. It does a great job at explaining various types of databases, the issues of sharding, replication, etc, and most importantly it explains how things can go wrong.
It makes reference to specific software but all the concepts are universal.
I listened to this as an audio book last year before ACM’s partnership with O’Reilly expired. It was tough to digest via audio, so what I got out of it was that distributes consensus is hard and also the last chapter about data ethics really hit home.
My current list is:
Books I would love to read if they existed:
2. A collection of stories of famous or interesting debugging sessions. The book equivalent of having a round with your ops or security team.
There are such books, e.g.
Thank you, these both look excellent
Another book that I enjoyed reading is “ENIAC - The triumphs and tragedies of the world’s first computer, Walker Publishing, 1999”, but it is more about the early beginnings of the computer hardware industry than about software. I assume you know the history of programming languages (HOPL) books, but these are more personal recollections of the language authors than what you would conceive as a history book.
Bold of you to presume I know anything. Thank you, the ENIAC book looks great!
I am interested in personal accounts. I don’t think HOPL quite makes my budget this year, but I’ve acquired an ACM membership (w library access) so I can read the papers from the conference upon which it is based.
Since writing this comment, I am also looking at A Science of Operations by Mark Priestly and Software: A Technical History by Kim W. Tracy. I haven’t actually read either of them yet, so don’t take these as recommendations. Actually, I’d be curious if anyone else has.
I’ve read Software: A Technical History and I wrote a review on Amazon. The short version is that it is a broad history of software systems and programming languages and summarizes many disparate historical narratives into a single book. I consider it a reasonable introduction, but you’ll probably want more.
Technical history, which is what I think you mean by “both the software and history sides”, is unfortunately a niche area of a niche area. I recommend looking at the “Historical reflections” column in Communications of the ACM as it often looks at subjects from a technical perspective.
If I may be allowed to go off-topic for a second and plug a coupe of books that couldn’t be reasonably expensed:
https://www.amazon.com.au/Unix-Primer-Plus-Waite-Group/dp/0672220288
I found this book in the local small-town library as a child, when I was around ten years old. Up until then I’d only ever used home 8-bit microcomputers like Amstrad CPCs and Apple 2s. It blew my tiny mind :)
I bought a copy around 30 years later and found that it had aged surprisingly well. I was particularly surprised by the fact that several of the Unix users and programmers in the book were female; I honestly hadn’t expected that for a book of this vintage.
You could actually take this book and use it to find your way around a modern FreeBSD or Linux system with surprisingly little friction. I don’t know whether that says good or bad things about our profession ;)
https://www.amazon.com.au/Programming-Z80-Rodnay-Zaks/dp/0895880695
This was my Bible as a ten year old hobbyist. I borrowed it from the library so often I was asked to leave it on the shelves for a bit in case anyone else wanted it. The funny thing is that as an adult I remembered it being this huge weighty tome; when I actually bought a copy though it’s a fairly slim technical book.
It’s still a very useful reference if you’re into Z80-based retrocomputing. And Zaks himself is still around; I was able to send him a thank-you note on LinkedIn before I abandoned that site.
Amazon says that it’s 620 pages. Maybe it reads like a slim book even if it’s not?
The surprise was mostly physical - even at 600 odd pages it’s still fairly physically slim.
Also only the first 186 pages are instructional; the rest is a reference.
Software Tools in Pascal by Kernighan and Plauger (1981) is a practical introduction to designing and coding tools and filters according to the Unix philosophy, with a lot of sound software engineering advice.
There’s also the sled reading list which is really good.
Hamming’s book on style is my favorite, The Art of Science and Engineering : Learning to Learn .
It’s an expanded version of his freely available speech You and Your Research , if you want a preview.
In summary it says he worked with Dirac, Fermi, Oppenheimer, Einstein, etc at the Manhattan Project but he worked with twice as many people you’ve never heard of. He figured out how to be someone you have heard of, and that’s what this book is about.
Programming Pearls by Jon Bentley is a canonical example. I love it because the style is so much more pleasant to read than most technical books. It’s more than an algorithms book while being relatively short. The principles are timeless even if the examples may not be current. It’s interesting from the historical perspective if you don’t approach it like a 2022 algorithms book.
Types and Programming Languages (TAPL)
+1 for APUE, a classic indeed. I liked Advanced UNIX Programming more. Jan Schaumann’s CS631 course is an excellent update. Hanson’s “C Interfaces and Implementations” is a fantastic “How to C book”. “Objective-C Phrasebook” by @david_chisnall was a great read, wish more books are written in that style. Some of my other favourites in no particular order:
Stepanov’s Elements of Programming, Valloud’s A Mentoring Course on Smalltalk, Dybvig’s The Scheme Programming Language, Norvig’s Paradigms of AI Programming, Harper’s Programming in Standard ML Mitchell’s Machine Learning
Operating Systems: Three Easy Pieces, the book that made me get reading glasses, Gillam’s “Unicode Demystified”, The O’Reilly vi book and “BSD Hacks” are worth revisiting every now and then to pick up a forgotten trick or two.
Varghese’s Network Algorithmics, easily one of the best technical books I’ve read. Wish there’s an updated edition.
Alex Petrov’s Database Internals, Kleppman’s Designing Data-Intensive Applications
Crafting Interpreters, I made the mistake of watching the author draw the book’s diagrams, and now I’m filled with shame every time I draw. I hate you @munificent :)
Thanks. I really like the Phasebook model but I definitely wouldn’t consider that book timeless. The first edition predated ARC, the second edition was a minor update for ARC. Objective-C changed quite a bit around that time.
I re-read it a few weeks back when I was checking out GNUstep after a very long time and it seemed like it is still relevant given that GNUstep hasn’t caught up with all the Apple ObjC advancements.
I believe the only thing that we don’t support is direct methods. I haven’t worked out a very good way of implementing these because they have an annoying interaction with +initialise. On Apple platforms, they call +class before each call, which hits a special fast path in their runtime. We don’t have an equivalent, but possibly should. We actually shipped some things, like blocks, before Apple because they were submitting the code to LLVM at WWDC and we were cutting releases before them.
Unfortunately, AppKit lagged a long way and we never got a UIKit implementation. Part of this was a desire from certain people to reinvent the wheel rather than adding dependencies. I really wanted to take a hard dependency on Cairo, Pango and ICU, but they were too slow on some ancient systems and so we ended up with three different back ends where any given thing worked better in one than the other two, but not consistently. Being a GNU project meant that there was a lot of pressure to keep supporting GCC and it’s runtime, which meant that we couldn’t use modern Objective-C features in the GNUstep codebase and so everything was more work to implement. This was particularly apparent with the lack of Objetive-C++ support, where wrapping a C++ collection let you implement various Objective-C things more efficiently and in less code, but couldn’t be committed to replace the painful GSIMap code, which implemented something like C++ templates with C macros.
Given your definition of ‘technical’, I’d put Peopleware on the list. If you only ever read one book about management, it should be that one. It should be required reading for anyone moving into management (I had a strange childhood, so first read it when I a was 12, but reread it a few times since). A couple of years back, I had to do a load of mandatory new manager training at work and one of the courses started with the presenter trying to show how modern and up to date he was by telling us how he’d have answered a question 20 years ago and how that had changed. His new answer was exactly what the 1987 edition of Peopleware said, which, unfortunately, correctly framed my expectations for the rest of the course.
I haven’t read the 2013 edition. Apparently it has some new material, I probably should get a copy at some point, but since the 1987 edition is still one that I’d recommend then I think it meets the ‘timeless’ part of the requirement. I’ve read quite a few books on management theory and several of them were also good, but in terms of good advice to word count ratio, I don’t think any are better than Peopleware.
The Little MLer is very fun to read.
Hacker’s Delight
Software Development and Reality Construction looks at meaning-making through software and cybernetics. Particular favorites include-but-are-not-limited-to Klein and Lyytinen’s Toward a New Understanding of Data Modelling (“the appropriate metaphors for data modelling are not fact gathering and modelling, but negotiation and law-making” remains an all-timer quote); Bjerknes’ Shared Responsibility: A Field of Tension (usefully applying Mao’s theories of contradiction to project management); Raeithel’s Activity Theory as a Foundation for Design (computers as another tool for mental, social, and historical self-regulation). Some parts may exceed your appetite for Heidegger but there’s always more variety if you flip around a bit.
I turn to de Haan and Koppelaars’ Applied Mathematics for Database Professionals regularly in lieu of actually remembering my discrete math.
Moore’s Crossing the Chasm won’t fall out of date until the software industry itself is unrecognizable, and in the mean time it’s a very useful thing to have read.
It hasn’t been around long enough to guarantee timelessness but I think Bellotti’s Kill it with Fire will get there. Like many books answering the definition it presents ways of thinking (here, about social and methodological tools to manage, support, revise, and replace legacy systems, which as the verse goes you have always with you) rather than technical and technologically-bound solutions.
Unix Power Tools.
A Philosophy of Software Design
This book was an eye-opener. Understanding where to break up code is much more than “no functions longer than X lines”.