These recommends hit different depending on where you're at in your career, but all contain some genuine teaching happening for any level professional programmer building commercial software. An unsorted, incomplete carrier bag.
Gathered by internetross. Last updated on 3/7/24.
| Title | Author(s) | Comment | What others have said | Quotes |
|---|---|---|---|---|
| Dreaming In Code | Scott Rosenberg | Analgesic schadenfreude. Or maybe mitfreude. Or mitgefühl. In any case, a backwards-compassionate "how the sausage
is made" tale seasoned with insightful study and surmisings of why it's so hard. Probably a more useful
intro to commercial software construction than any technical manual. There's a discussion of the word "defect" and it's origin in factory management. And whereas "bugs" is suggestive of a kind of unavoidable, natural phenomena; like a primordial human lack. Bugs are *always* a part of code. They are an attendant property. On the other hand, importantly, "defects" suggests human error, or a failing of the system-of-software-developers to produce outcomes according to plans. Both are "bad." But *defect* may carry a stronger sense of urgency. Or perhaps is better at whipping up enthusiasm to address maintenance burden more systematically? Either way we might be attendant to the use of these varying terms in our day-to-day. |
Quoting Weinberg: "Informal mechanisms always exist and it is dangerous to change things without understanding them, lest you derange some smoothly operating system which you will not be able to replace at similar cost." "In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project." |
|
| Elements of Clojure | Zachary Tellman | A compact (dense, not concise) metaphysical wander through software design. | "Indirection provides separation between what and how. It exists wherever "how does this work?" is best answered, "it depends." This separation is useful when the underlying implementation is complicated or subject to change. It gives us the freedom to change incidental details in our software while maintaining its essential qualities. It also defines the layers of our software; indirection invites the reader to stop and explore no further. It tells us when we're allowed to be incurious." "Conditionals solve conflicts by making an explicit, fixed decision. Where conflicts are possible, we use conditionals because they are closed." |
|
| Ruby Garbage Collection in Under Two Hours | Jemma | GREAT for beginners to the ideas of dynamic, automatic garbage collection. Get swept up by the temporal notions of the "Weak Generational Hypothesis" introduced in Ruby 2.1. And mourn: "Most objects die young" in our modern language system. Not sure a comparably concise and joyful book on the subject matter exists. | ||
| Software Theory | Federica Frabetti | Software folds in on itself. Slips definition. This is why I love it so much. | "Computer technology, data banks, artificial intelligences, translating machines, and so forth, all these are constructed on the basis of that instrumental determination of a calculable language. Information does not inform merely by delivering an information content, it gives form, 'in-formiert', 'formiert zugleich'. It installs man in a form that permits him to ensure his mastery on earth and beyond." "There is no general approach to software than can establish once and forever how software works and what place it occupies in relation to 'writing' and 'language'." "Closure is always temporary, for the design hypothesis is tested again and again in use." "This point of opacity suggests that Software Engineering establishes itself as a theory of technology by expelling fallibility from technology – but such a fallibility (the unexpected consequences of technology) is intrinsic to technology itself, and is exactly what allows Software Engineering to exist (that is, the reason why Software Engineering is called for). In other words, Software Engineering performs an impossible expulsion of constitutive failure from technology, while simultaneously establishing itself as a discipline with this move." |
|
| Shanzai | Byung-Chul Han | Helps shrug off the Western myth of the genius programmer; how the cultures of east asia gave us refactoring; assuages concerns about copy & paste code | ||
| A City is Not a Tree | Christopher Alexander | Composition vs inheritance drama, refutes Konmari, embracing the microbial perhaps, helps you shake off Aristotle's Great Chain of Being with a bit of overlap and powerset cladistics. Makes sure to get the 50th anniversary edition with companion essays! | ||
| The Programmer's Brain | Felienne Hermans | # TODO | ||
| Software Development and Reality Construction | Christiane Floyd (Editor), Heinz Züellighoven (Editor), Reinhard Budde (Editor), Reinhard Keil-Slawik (Editor) | Helps orient an understanding of the software discipline. Probably useful to read after you've been undone by Frabetti (above). | ||
| A compilation of poetry written in code (3rd Ed) | Ishac Bertran | It's open mic night. Take a breather from sweating over commercial software that enriches the ruling class. | ||
| If Hemingway Wrote Javascript | Angus Croll | Computer instructions would be so lush without the tyranny of arid consistency | ||
| Constructing the User Interface with Statecharts | Ian Horrocks | This dusty scroll is an absolute must for UI devs. The frontend is hard (sigh for your backend and system bros who gripe). Ian proves it, and we can (re)discover his solve for complex state management from '99. | ||
| Grokking Simplicity | Eric Normand | The best "first book" on functional programming I've found. | ||
| Thinking Forth | Leo Brodie | # TODO | ||
| Why's (Poignant) Guide to Ruby | why the lucky stiff (Jonathan Gillette) | The font is too small. But this book is beastly futurist dada | ||
| Practical Object-Oriented Design in Ruby | Sandi Metz | Not just for cycling fans! | ||
| Land of Lisp | Conrad Barski | # TODO | ||
| Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People | Aditya Bhargava | A refreshing book for programmers who were never explained the when and why of algorithms. | ||
| Macintosh Human Interface Guidelines | Apple Computer Inc | Some things change, some things stay the same. Like Horrocks (above), helps you relax into the consistencies of computer historicity. |
The popular kids. In my observation, most experienced programmers will have either glanced at them or know them well and their influence. Unfortunately these titles can be voluminous, borish academic tomes. What's more, there's scant counsel (if any) for how to read them successfully. However, if you can get situated, their lessons are readily applicable to everyday practice you'll find yourself nodding along or exclaiming excitedly, "ohhhh, that's why [old so and so] suggested that in my PR"; or "ohhhh, that's why my manager talks about [xyz] all the time."
The best I can advise is to start browsing from the TOC or index by topic or keyword, pick a point of entry, then go. Or try the Benjamin Franklin method (as explained by James Koppel). In fact, today this type of reconstruction exercise is generally understood by cognitive scientists as an important strategy for memory retention, called elaboration: "thinking about what you want to remember, relating it to existing memories, and making the new memories fit into schemata already stored in your LTM." (p44, The Programmer's Brain)
| Title | Author | Comment | What Others Have Said | Quotes |
|---|---|---|---|---|
| Working Effectively with Legacy Code | Michael Feathers | |||
| Refactoring | Martin Fowler | |||
| Patterns of Enterprise Application Architecture | Martin Fowler | |||
| Object Design: Roles, Responsibilities, and Collaborations | Rebecca Wirfs-Brock and Alan McKean |
| Title | Author | Comment | What Others Have Said | Quotes |
|---|---|---|---|---|
| Programming as Theory Building | Peter Naur | A famous rebuke of the idea that programming activity reduces to code blather | ||
| FAQ Sheet on Feature Interaction | Pamela Zave | An elegant, concise primer on the intrinsic problem of complexity that runs through any complicated software | ||
| Code is a Palimpsest | Alvaro Videla | # TODO | ||
| On rebooting: the unreasonable effectiveness of turning computers off and on again | Keunwoo Lee | A most reasonable platitude laid bare | ||
| The Seven Turrets of Babel: A Taxonomy of LangSec Errors and How to Expunge Them | Falcon Darkstar Momot, Sergey Bratus, Sven M. Hallberg, Meredith L. Patterson | Empirical analysis of my fave coding anti-pattern: shotgun parsing. A rigorous of flank Michael Feather's "Edge-free Programming" | ||
| The Ironies of Automation | Lisanne Bainbridge | The 1983 paper that laughed at the idea we could code ourselves out of a job | ||
| Metaphor and Metonymy in Object-Oriented Design Patterns | James Noble, Robert Biddle, Ewan Tempero | Considering the terrain of our objetive simulations as metaphor and metonym to (urgently) avoid arrogantly and foolheartedly writing code with rigor en la ciencia |