Okay, here's some I haven't seen mentioned yet, although these may be pretty far afield for you:
Drift into Failure, by Sidney Dekker. Studies failure analysis in complex systems, and basically argues that our classic reductionist/scientific method approach is the wrong way to study complex engineering failures.
How Buildings Learn, by Stewart Brand. This isn't about programming. It's about architecture, in the build-a-building sense. It studies what happens to buildings over the course of their lives, as opposed to just when they're first built.
Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf. Learn how to use message queues and service busses correctly. Honestly, just read the first couple of chapters (65 pages or so), and the rest is reference, to look up as needed, so it's not as imposing as it sounds.
Advanced Programming in the UNIX Environment, by W. Richard Stevens. This book was my bible back in the olden days before http and ssh and stuff (I'm olde). Knowing how sockets really work can be an absolute lifesaver, even in this modern world of giant protocol stacks. Especially in this modern world.
The Art of Computer Programming, vols 1-3, by Donald Knuth. Only a madman would actually read them all, but they're good to have to remind you that there are mountains you can't even begin to climb.
A Deepness in the Sky, by Vernor Vinge. A science fiction novel that is really about hacking, set thousands of years in the future, when Moore's Law is long defeated and programmers are basically archeologists.
Design Patterns (aka Gang of Four), by Gamma/Helm/Johnson/Vlissides. There are lots of good books on design patterns, but you should really read the one that started it all. (For extra credit, read A Pattern Language, by Christopher Alexander - a book about urban architecture that inspired it.)
Continuous Delivery, by Jez Humble and David Farley. Stop thinking about your program in isolation, and learn how to deploy effectively!
Influence: The Psychology of Persuasion, by Robert Cialdini. This is DHH's favorite book. Learn how people think, and how to use that to design better products.
How to Win Friends and Influence People, by Dale Carnegie. Not creepy at all, despite how the title sounds in today's language. This book is the bible of how to get along with others. It's been in continuous print since before WWII, for good reason.
The Lean Startup, by Eric Ries. The best work you do is the work you find you don't need to do. Learn how to fail fast and save time on projects and product development, by building what customers want rather than what you think they need.
I recommend looking into anything around processes or process-building/management, project management, how incentives work, and how the brain works. The natural world and the corporate world are great examples of systems in action.
I've not read the book version but "How Buildings Learn" is one of my favorite things ever (a great case-study for looking outside of software for lessons that can apply to well...software).
Stewart Brand (of Longnow fame) produced a really lovely 6 part series for BBC in the late 90's and they are on YouTube: https://www.youtube.com/user/brandst/videos -- highly recommended (Warning: there is a very loud and obnoxious beeping during the first 10 seconds or so)
A look at "the evolution of buildings and how buildings adapt to changing requirements over long periods" -- replace buildings with software and you’ve probably got a best-seller from Pragmatic Programmers!
This is fascinating. For anyone interested in a slightly odd but unique and in-depth view of Systems design and failure, would like to recommend "The Systems Bible: The Beginner's Guide to Systems Large and Small" by John Gall.
The one that made the biggest impact on my approach to architecture is "Designing Solutions for Your Business Problems: A Structured Process for Managers and Consultants" by Betty Vandenbosch.
The one that made the biggest impact on me in ever is "Wicked Problems, Righteous Solutions" by Peter DeGrace and Leslie Hulet Stahl. Lots of forehead slapping and kicking myself ensued. Even more applicable today than it was in 1990 when written.
"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister comes as a very close second.
Not directly architecture or technology-related is "The Story Factor by Anette Simmons". It... changes you. Really useful for technical writing.
I appreciate the answer, and I may add some of those to my reading list, but that's not quite what I'm looking for. I am looking for online communities. Also, I am interested in build systems themselves. Design, implementation and usage of build systems. Build engineering. I have read the SRE book, for example, and it only discusses build systems at a surface level.
Seconded, Normal Accidents is one of the best books I've ever read. In addition to the maritime accidents, there are chapters on nuclear plants, chemical plants, and dams. It is a great discussion of how modern industrial accidents rarely have a single cause but instead are cascade failures of systems whose complexity has evolved beyond what we can handle, and presaged many of the messes we've got into with hyper-scale software projects before those ever existed.
Is there a "sequel" to Normal Accidents about software? Because I'd buy that in a heartbeat.
For a good analysis of risks and failures associated with complex systems, I recommend "Normal Accidents: Living with High-Risk Technologies" by Charles Perrow (1999).
I always recommend to read the classics (in addition to other excellent advice given here). Brooks, for sure, but also Vitruvius is _very_ relevant to designing large software systems. Then jump into the MIT System* ocean: system architecture (Crawley) gives you a framework for thinking about large and complex things, system safety (Leveson) a good framework for making things safe. Add some MIT product design and a ton of failing on your arse and you should be understanding you don’t still a thing in no time at all
More than any other title on my bookshelf, it has affected the way I think about any product design process.
Things WILL go wrong, sometimes in ways you did not expect. Hence, you had better plan for systems to fail gracefully rather than by going kaboom.
(I design handling systems in the low megawatt range - so design failures tend to make themselves painfully and spectacularly evident if given half a chance.)
Edit: Oh, and Horowitz & Hill's 'The Art of Electronics.' I've a MSc in electronics, but AoE was the book which bridged the gap between all the theory we were fed in lectures and the nitty-gritty of actually making something which would work.
If nothing else, AoE drove home the validity of the old truism 'In theory there's no difference between theory and practice, in practice there is.'
“The effective engineer” by Edmond Lau is a good book for the IC software engineer working in an engineering organization.
The most influential content on engineering in my life is not in a book but a YouTube talk entitled How Complex Systems Fail by Richard Cook, which is about designing resilient systems. I’ve applied these ideas to many aspects of life, not just engineering.
Drift into Failure, by Sidney Dekker. Studies failure analysis in complex systems, and basically argues that our classic reductionist/scientific method approach is the wrong way to study complex engineering failures.
How Buildings Learn, by Stewart Brand. This isn't about programming. It's about architecture, in the build-a-building sense. It studies what happens to buildings over the course of their lives, as opposed to just when they're first built.
Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf. Learn how to use message queues and service busses correctly. Honestly, just read the first couple of chapters (65 pages or so), and the rest is reference, to look up as needed, so it's not as imposing as it sounds.
Advanced Programming in the UNIX Environment, by W. Richard Stevens. This book was my bible back in the olden days before http and ssh and stuff (I'm olde). Knowing how sockets really work can be an absolute lifesaver, even in this modern world of giant protocol stacks. Especially in this modern world.
The Art of Computer Programming, vols 1-3, by Donald Knuth. Only a madman would actually read them all, but they're good to have to remind you that there are mountains you can't even begin to climb.
A Deepness in the Sky, by Vernor Vinge. A science fiction novel that is really about hacking, set thousands of years in the future, when Moore's Law is long defeated and programmers are basically archeologists.
Design Patterns (aka Gang of Four), by Gamma/Helm/Johnson/Vlissides. There are lots of good books on design patterns, but you should really read the one that started it all. (For extra credit, read A Pattern Language, by Christopher Alexander - a book about urban architecture that inspired it.)
Continuous Delivery, by Jez Humble and David Farley. Stop thinking about your program in isolation, and learn how to deploy effectively!
Influence: The Psychology of Persuasion, by Robert Cialdini. This is DHH's favorite book. Learn how people think, and how to use that to design better products.
How to Win Friends and Influence People, by Dale Carnegie. Not creepy at all, despite how the title sounds in today's language. This book is the bible of how to get along with others. It's been in continuous print since before WWII, for good reason.
The Lean Startup, by Eric Ries. The best work you do is the work you find you don't need to do. Learn how to fail fast and save time on projects and product development, by building what customers want rather than what you think they need.
reply