More than 50 years after its writing, probably still the single best management book. The main takeaway is what the author proposes as some sort of central question of management: what can I contribute?
Note: “executive” does not mean “senior manager”, but “knowledge worker”.
The book is a collection of rather independent essays, several of which are good in their own right, the most famous ones:
The mythical man-month: a classic, and at this point probably not that interesting any more; the example with the nine pregnant women is here.
The surgical team: old-fashioned and non-so-scalable software development process, but occasionally useful (to some extend, how the Linux kernel is developed).
The second system effect: It is notable how this keeps happening…
No silver bullet: This should have been the title of the book. A bold thesis that keeps holding for more than 40 years, despite interminably promises that just keep coming…
Very well written and sourced, and not indulgent at all, this book is worth reading already as a life story. On top of that, such a high quality treatment of a significant part of the history of personal computing and the software industry makes it a must. The book goes into details and contains countless technical, management and business lessons—to imitate, and to avoid.
Writing an encyclopedic technical book (à la Donald Knuth) is an extremely hard project that usually fails. However, when done well, the result can be extremely rewarding. Martin Kleppmann found the exact balance between theoretical rigor, technical details and the big picture. The ultimate “back-end developer” manual.
Probably the mother or all programming books. The first occurrence of the “hello, world” program is here (please note the comma, the lowercase, and lack of exclamation signs). Learning C is in my opinion mandatory for a complete programming education, and this book is just the best way of doing it.
A rather unknown book about the Linux kernel, from the perspective of a kernel developer, not a user or administrator. Very didactic walk through some kernel code. The main takeaways:
The idea (which is obvious, but that most developers tend to forget) that kernel source code is just source code, not essentially different to what most people write in higher levels.
How surprisingly simple some kernel code is, and how efficiency can be achieved not thorugh complications (as it is sometimes) but thorugh simplicity, actually “making the computer do less things”, so to say.
The author interviewed, in the same book, at length:
Among others. Two quotes as teaser:
Joshua Bloch:
When you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about. And that’s the way you choose computer languages.
Simon Peyton Jones:
One thing that is hard, even for professional software engineers and developers, is to viscerally grok the size of the artifacts on which we work. You’re looking at the Empire State Building through a 1-foot-square porthole, so it’s difficult to have a real feel for how gigantic the structure you’re looking at is. And how it’s interconnected.
This book probably contains what the whole “agile” industry wanted to say, but could not. This short and unknown book actually hits the nail.
A CEO book from Netflix. Very provocative, fresh and concrete approach to process design. My main takeaway is the emphasis in context as opposed to control in leadership.
A CEO book from Andy Groove, who led Intel for more than a decade. One of the problem with this kind of books is the lack of actual details, being too abstract and generic. And also sometimes skipping the less attractive aspects of management. Neither of those happens here: this is a true “how to be a CEO” manual. Rare and useful.
Best known for its advocacy of private offices for developers, this book has much more to offer. It’s a somewhat disconnected list of essays about how to manage people doing software, that is still refreshing to read and relevant more than 40 years after publication.
A classic of the business literature that needs no presentation. Some people complain that the examples are old, but in my opinion this reinforces the point: enough time passed to see how the then-disruptive examples got disrupted themselves, exemplifying the disruptive nature of technology evolution.
Probably not for cover-to-cover reading, but reads surprisingly well considering how intricate the topic is. Update here: How much of ‘What Every Programmer Should Know About Memory’ is still valid?
Recommending books of entrepreneurs is very dangerous due to survivorship bias; that’s why there are not so many in this list. However, the extremely candid and perhaps politically-incorrect account overcame its biases. A much necessary non-romantic view of start-up companies.
Memory models are hard to understand. Other hard-to-understand things usually can be encapsulated, or are only necessary when programmers care too much about performance. But this is unfortunately not the case with memory models, as their complexity is quite pervasive: almost every developer is in contact with them and supposed to understand very complex formulations in order to write correct code. This lack of encapsulation is probably one of the biggest unsolved problems of software engineering. In any case, Aleksey Shipilëv put online a transcript of what is, I believe, an excellent explanation of the concept. It's centered on Java, but all multi-threaded languages build models more or less in the same way.
A CEO book from Twilio. A collection of mostly good software management advice, some rather known, tough. I think the most significant contribution is the idea that business people should share problems, not solutions, setting a very clear starting point for the relationship between product managers and engineers, so commonly problematic.
A classic about software rewrites.
A tad cynic but nevertheless insightful piece about managing stakeholders in software.
A untentially simplistic guide to good software engineering practices that ages surprisingly well in the more than 20 years that passed since it was written.
This is a post to a email distribution list (lacking a proper title or subject, I am using the incipit to name it). While the arguments given against debuggers are a bit moralistic, I think the conclusion stands on its own. I personally almost never step though the code; not because it’s “bad”, but because it is in my experience extremely slow and most times just ineffective. Being a bit along in this, I found this post refreshing.
A fun and graphical explanation of one of the fundamental trade-off of software engineering.
Gil Tene manages to give a talk that starts at the basics of latency measurement and slowly gets into more details than most people want to know. All very digestible and actionable.
A down-to-earth, and —in my opinion— correct approach to managing the inevitable status race that any organization with humans will contain. Sometimes people vaguely dismiss “big company culture” without being specific about what that is. This article addresses is one specific point about that culture and how to avoid it.
The inventor of the expression “site reliability engineering” explains what it actually means. Spoiler: it’s a practice more than a career path or job description. Perhaps a bit overfit to Google, but still useful.
Very short article that explain this simple, important, perhaps popular, but almost always ignored principle.
While the article starts talking about software stakeholder education, it’s in the end a collection of fallacies and wrong practices in which software practitioners incur sometimes themselves.
For some reason, organization design is usually not openly talked about in the management literature, a fact that many times leads to guessing and cargo-culting. This article is by two organizational academics that have links to Apple (and some inside information) and points at a lesser-known aspect of Apple success.
One of the best Java Virtual Machines internals post. Accessible and concrete.
Some interesting points made here, with most of which I agree, by the way. Plus points for the good prose—not common among technical people.